In a previous article, we introduced you to Product expertise in Consultancy. Today, we invite you to explore the details of a Product Owner/ Product Manager’s daily life in Consultancy. Join Palina Haidukevich, our expert at Godel, as she shares insights into the Consultant’s journey, highlighting both the day-to-day experiences and challenges faced in person.

Can you share a bit about what drew you to the Consultancy function?

I joined the Consultancy function around 2 years ago. Before that, I spent some time working at Godel on ‘classic’ engagements, where the focus was on discovering known opportunities or features and guiding them through the development cycle. After about 8 years of varied BA experiences—different domains, methodologies, handling end-to-end features or being more backend-focused it felt like I had explored a lot. Still, my core responsibilities remained the same as in any software development process: eliciting, gathering, analysing, documenting, and managing changes to requirements.

Being used to the routine of engagements, I was seeking a challenge. I didn’t want to dive deep into project management or become overly technical, so I had a question in mind: Where to go next?
That’s when I started thinking about what happens before. How do clients or companies decide where to invest their resources, how they allocate them between products, and how do they shape their strategic plans and transformations? These aspects seemed closely connected to Consultancy, so I decided to try it. Fast forward to today, and I’m now in my 3rd year, finding new challenges and satisfaction. 

It was the right decision to give it a try!

What does your typical working day look like?

It all depends on the consultancy case I’m working on. In the early stages, I spend more time reading and analysing existing documents, current processes, products, and business models to understand the domain and the client’s problem better. It involves a lot of listening and absorbing information from subject matter experts and stakeholders rather than doing a lot of talking. Some might find it boring or standard, but I find it quite interesting. There are many instances when we discover that the client’s problem has changed within a week from our kick-off session due to market shifts, leading us to investigate different products or focus on other processes.

Moving on to the main part of the case involves generating ways and approaches to problem-solving. This is where I become more engaged in discussions and fill my diary with meetings. We once calculated that we have around 100 meetings in three months, more than 30 per month. It was a challenge! However, it’s not about feeling busy — it’s about the necessity of having many meetings to generate a list of approaches, discuss them with various functions/departments, constantly be aligned with key stakeholders, select the best approach, and present it to all the stakeholders involved.

After this phase, we gradually move to case closure, where we document and prepare strategies, roadmaps, high-level descriptions of future backlogs, or work with our tech architects to help them build diagrams and high-level architecture based on business outcomes. It feels busy and involves a lot of discussions as well. I often associate this phase with the song ‘Highway to Hell’ because all the processes and documents from the case need to be finished in a one-time spot, aka case close, which is challenging!

In between cases, I take some time to restore myself, reflect on lessons learned from the latest case, share the output with other experts, and upskill myself. In the Consultancy unit, we call this time “recharging,” or I call it a short retirement.

Can you share an example of a successful Case? What made it successful?

Yes, sure! A Client sells insurance services through various products in this domain. However, some of these products have become less profitable, leading to declining business metrics. The client’s simple and complex question is: How should I transform my products? I’ll describe the answer for one product to keep it concise.

To answer this question, we follow the usual system approach and analyse each aspect of the system:

Client’s Strategic Goals: What are the Client’s strategic goals, and how do this specific Product and its metrics impact the Company’s overall objectives?

Customer Perspective: How do customer journeys look? What are the value, pain points, and main areas for improvement from the Customer’s point of view?

Backoffice and Internal Processes: Does the Client have enough internal resources, and are the internal processes sufficient to support the product?

Technology: Does the technology align with the business? Are there any technical debts or legacy code preventing them from achieving goals? For example, do we have tools for A/B testing and the ability to run multiple tests concurrently to validate hypotheses faster?

Once we’ve analysed each aspect, we created a vision for the future state of the Product and an approach to fill the gaps: targeted business metrics and features working to achieve them, new Customer journeys, streamlined back-office processes, and a high-level tech architecture to support the changes.

This case was successful for several reasons:

Having a partner from the Client side who was an SME expedited our understanding of the domain and its current state. This is crucial where time frames are typically short, averaging around 2 months for any Consultancy case. Relying on the Client’s expertise helps navigate the domain swiftly.

Sharing plans and draft versions of documents beforehand is crucial in preventing misunderstandings and optimising time.

Effective communication involves not only updating on task progress and deadlines but also informing about potential risks and changes. Managing expectations is crucial. If a planned task faces unexpected challenges, propose solutions, like presenting an MVP version of any artefact on time and refining it to an extended post-MVP version later.

Being agile in resource allocation is key. In this case, we needed a UX/UI designer to create an appealing future journey. Seeking help from the team and being open to collaboration ensured we had the necessary expertise and saved valuable time. 

Preparedness for meetings with C-level executives goes beyond politeness and sending agendas. It involves speaking at a high-level skipping details even if they are important to you, focusing on their interests, and being ready to handle unexpected questions outside your direct responsibility.

Are there any failures? How have you learned to go through it?

Yes, definitely. I have a lot of examples of days where my work was deprecated or commented on as not the right option for various reasons. My main tip is to allow yourself to give up and make mistakes.

Usually, I give myself time and opportunity to go the full cycle ‘being angry→ being desperate → accepting the feedback → learning lessons → trying one more time’.

During this cycle’s ‘non-productive’ phases, I usually post memes, like TikTok videos about being dumb at work and complaining to everyone about my hard life. It helps a lot to live through failure!