Product Management Workflow

Product management doesn't have to be chaotic. There are 6 core phases which every product management should be familiar with in order to suceed. Each stage requires a different skillset which can be obtained through experience and courses.

Once in a while you reflect on the work you've done and everything you learned along the way. This article here is my personal reflection on the role of a product manager and how initially a role filled with chaos started to take shape and make sense.

I hope to maybe provide some guidance and structure to those who are already on the journey to becoming a product manager or are contemplating taking a leap into the role.

Defining what a product manager is

Before we go on I want to share my own personal definition of a product manager:

"A product manager is a strong communicator who can through effective cross-functional collaboration achieve significant business impact and often change the trajectory of a product or a company."

Several years ago I would not have paid so much emphasis on the communication and collaboration aspect of product management, however over the years I've learned that they are actually at the heart of what makes a great product manager.

We will later look into why why communication and collaboration are the main product manager's skills . First I encourage you to keep reading on to get an accurate representation of a product manager's workflow.

What product managers should avoid doing

Many, many years ago, when I first saw a product manager, to me their role resembled something along the lines of:

This seemed logical:

1. Come up with ideas
2. Ask someone to build them
3. Show what has been built and how it can be used

I didn't see any flaws in that. And to my surprise, as I've learned product management skills, I also realised that so many product managers are still attuned to the above mental model. If you think that's what product management is, then please stop. You are creating a feature factory and that's something you should avoid at all costs.

So what's wrong with it?

• The process rarely starts with "ideas". Instead it begins with understanding the business, the users (or potential users), the problems, and often opporunities.
• You can't just "build" ideas. Ideas are volatile thoughts which need to be curated and molded into a form which has logic and structure. Only after that can ideas be built. There is therefore a large discovery process before anything of high value is built.
• The cycle doesn't end with showing what you've built. You need to measure it and collect feedback. Whatever you build needs to move business metrics. Otherwise, why build it?

Product management workflow

As I dove deeper into product management, my mental model quickly started to resemble the following:

Let's look at what happens at each stage.

1. Identify problems or opportunities

At this stage you are trying to figure out what problems customers or potential customers are having. There are many methods for doing that, however they are out of scope for this article. Problems generally lead to opportunities.

The more problems you identify the better. As you work more and more with a particular product, your understanding of it will grow, and so will your view of how each problem connects to each other. This is what I call the problem network effect. Also, the larger your understanding, the better you become at judging what is the "right" thing to build.

Generally at this stage you are:

• Analysing how an existing product or feature is being used
• Analysing competition
• Talking / interviewing users or potential users of a product / feature
• Talking to your engineering team to understanding the technical implications / constraints of problems
• Noting and recording all the learnings
• Starting to formulate a product strategy / roadmap

2. Prioritise

With a bucket full of problems you now need to make choices. I've seen teams try to use complex formulas for prioritising the problems they'll solve first (I tried this myself too). However, I've never seen that work well. Also, the many other product managers I've spoken with across many companies are also sceptical of this approach.

Prioritisation is a business bet. And I am not referring to bugs and very small improvement requests. Instead I am referring to large business and customer problems that may take many months if not over a year for a team to address and iterate on. These types of larger bets are difficult to quantify. So how do you prioritise in that case? From my experience everything boils down to 1) the ability of a product manager to justify priorities through quantitative and qualitative research, 2) good storytelling, 3) and a well developed sense of product intuition.

All of the above generally translates into the following tasks:

• Finalising your strategy / roadmap which you should have started in Phase 1
• Getting your story right with crystal clear reasoning for your recommendation
• Preparing alternative scenarios as backup
• Presenting and discussing your proposed strategy / roadmap with the right stakeholders

This phase is likely to be very different depending on the size of the company, how many stakeholders are involved, how often the business expects you to prioritise, etc.

3. Identify solutions

This stage can be complex and depending on the problem you are trying to solve, it might take as long as the build phase.

This is also the creative phase. You are likely to get things wrong at first, and that's ok. Your tasks here are:

• Ensure your designers and engineers (your core team) understand the product vision and the problems
• Analysing competitor solutions or solutions from similar products
• Organise the necessary meetings and workshops (e.g. design sprints) where designers, engineers and business people come together in a guided and structured way to come up with ideas
• Work closely with your designers to iterate on ideas
• Get feedback internally and externally on prototypes
• Define and document technical specifications
• Get internal buy-in from the business that the proposed solution is the right direction

4. Build

Once you have good confidence that the proposed solution will address the problem, then it's time to build. This is when the team begins to work through the requirements discussed and documented in the solution phase.

At this stage the product manager can leverage their project management skills to guide the build process. Your primary tasks here are:

• Keep track of tasks and their execution
• Make sure the team always keeps the larger picture on top of their mind
• Make sure the team has full clarity on the next few tasks which lead toward the end goal
• Constantly update all the necessary stakeholders about the build progress and inform of any delays

5. Launch and promote

Hooray! Your product, feature, MVP, or whatever it is are done. Or maybe it's only the first milestone of a large project. But you are ready to launch it, even if it's to a small group of users.

Here you are focussed on:

• Preparing the launch plan
• Often working closely with marketing on the rollout plan strategy & execution
• Updating internal stakeholders about the luanch
• Communication with users about the rollout

6. Measure and collect feedback

As soon as a few users begin to experience your new product, it's time to get feedback and measure the business impact. During a new product or feature launch you'll first be looking to:

• Check that it is used as expected and everything works
• Check the technical health (i.e. the servers and databases where your product is hosted)
• Collect initial feedback from users
• Update the business about the launch

As your product or feature adoption grows, you'll start to:

• Measure performance metrics
• Generate a backlog of improvements, or maybe you'll decide to kill the product or feature if it hasn't succeeded (this can happen too!)
• Monitor for feedback across various channels

A few closing notes

So far so good. We've covered the basics of product management. As you begin to prioritise your days across the cycle I've listed above, you'll realise (as I have) over time that during each phase you need a certain specialist skillset, e.g. when you are trying to identify problems then knowing how to do user research helps, or when you are building then good project management skills help a lot.

However, what I've observed is that there are two soft skills which help during every phase and I consider them the cornerstone of great product management: communication and collaboration .

Continue reading and find out why communication and collaboration are the main product manager's skills.