This is a reference guide to the product management process, an attempt to visualize and explain it with a set of interlinked cartoons and some text. It is based on insights from across the best books on product management and from interviews with hundreds of product managers (PMs).
Most PMs do many but not all of these activities as part of their workflow, but together they encompass the totality pretty well. The guide is meant for you as a PM to use as a reference point when thinking about how to take your own process to the next level, achieve autonomy, and create more product value.
I also want to give extra credit to Matt LeMay, Kevin Albrecht, and Lis Kamor for invaluable feedback along the way, to Teresa Torres for her approach to centering work around Opportunity Solution Trees, and to Delibr's own wonderful Fredrika Andersson for doing all the great illustrations. Let's get to it!
The phases and activities of the product management process
We think about Strategy as clarifying the strategic context and then articulating and agreeing on direction and goals to work towards.
The first thing you need to do is to understand what the general situation looks like, establish a worldview and get a reasonable understanding of what is actually going on, and then agree with other people on that.
This can be done in many different ways, and what the best approach is varies widely based on context, so we are hesitant to prescribe a specific method for this. But if we were to stick our necks out and suggest a few good pieces that could constitute a starting point, it would be to fill out a Business Model Canvas, articulate the Value Proposition, specify and formulate your Ideal Customer Profile, and survey the Competitor landscape.
It should also be noted, that for all of these, once a first top-down formulation is done, there is immense value in doing a ton of Discovery to anchor it with research on users.
When you have an agreed map you work progressively towards being more concrete. You can have the map as a backdrop for a high-level discussion of possible directions, general themes, or focus areas to go for. Such a high-level discussion, as well as a structured approach to goal break-down is often relevant before you go to the details of specifically articulating concrete goals, e.g. in the form of OKRs.
One of the most important aspects of strategy is to prioritize one or a few focus areas and goals (and to down-prioritize others). This means that any good strategic work has an intimate link with Prioritization.
At the end of strategic work, you should have a goal to work towards that you can hand over to the rest of the process. Specifically, going in with a clear goal to put at the top of your Opportunity Solution Tree makes Discovery much more pointed and effective.
We think about Feedback as handling requests that's pushed towards you in different channels from users and stakeholders, and extracting key insights so that you can access them later.
All PMs that have some area that they are responsible for with at least a couple of customers get more or less bombarded with requests via email, slack, channel, customer support, etc, as well as from different stakeholders. They need a process to handle all of these feedback items somehow.
To remain sane, PMs need to do hard triage upfront, to quickly review, handle and move past most feedback items. Otherwise, if they get pulled into deeply analyzing all incoming feedback, that is all they will ever do. For relevant requests, it is a good practice to note who asked for it, to make it easier to come back and follow-up later once the issue has been solved.
The main thing to extract out are any implied problems or implied solutions from the feedback. And then for such problems or solutions, if they are deemed relevant, to understand and categorize or tag them either as new ones or linked to already recognized ones.
These will go into something like a pool of such problems and solutions with some tags and categories. This can be ok to begin with, but to avoid the feature factory trap, it is important to not just go into Prioritization of solutions, but to first do Discovery using Opportunity Solution Trees to figure out the real underlying problems and what the best solutions to those could be.
Like Henry Ford famously put it before developing the car: "If I had asked people what they wanted, they would have said faster horses."
We think about Discovery as interviewing your users and structuring your insights to find the most relevant opportunities.
As a starting point, it is crucial to have input from Strategy, ideally a goal to work towards, or at least a specific type of persona, job-to-be-done, or value proposition to investigate. This is the very top of an Opportunity Solution Tree.
The next thing to do is to make a first stab at structuring your thinking top-down based on what you already know, which typically means breaking down the goal or job into known parts or steps, and adding in the problems you already know about. Using a tree for this helps keeping a MECE structure.
Looking at this tree, prioritize the areas where you are most interested to learn more. Here you figure out kind the parameters of what your are trying to figure out, often detailed as a kind of research project.
Then you switch to a bottom-up approach, and do generative research by interviewing, testing and having real discussions with your with users. Here you actively pull insights out of users, which is opposed to the push of requests that happen in the Feedback step. This will deepen your understanding of what the users really need and want and how they think about things.
You will learn more both about the structure of the problem space and about specific problem areas. This can then feed back into the Opportunity Solution Tree.
Then at some point, as your understanding deepens, you go over to Prioritization to decide and then come back to the Opportunity Solution Tree and say, this is the problem or opportunity that we want to work with. Then you start to populate that branch of the Opportunity Solution Tree with a lot of different potential solutions, including both the ones suggested by users and ones created in discussions with the team, making a proper divergence before you converge on one or a couple of solutions to pursue further.
Pursuing a solution further means going into Refinement, but before significant efforts are put in, you go over to Prioritization to decide it is a solution to invest more time into.
Build your Opportunity Solution Tree in Delibr!
Let us help you!
Book intro meetingPRD, story map, decisions & Jira issues in 1 epic doc
Manage your user stories in Delibr, integrate directly with Jira
Put your user stories on a story map
Check out Delibr's best practice epic template
Epic kanban board: a powerful overview of your epics
Level up your PM skills
We think about Prioritization as maximizing product value by prioritization at the three levels of goals, opportunities and solutions, as well as communicating around that with trees and roadmaps.
PMs often have something akin to a lake of solution ideas, often ones that came in via Feedback with user and stakeholder requests. They then face tremendous pressure to focus their prioritization efforts across all these solutions. The pressure is to do a proper RICE scoring across all solutions, but if they do they drown in that activity and get no time to get Discovery or Validation done. To avoid this they need instead to lift their gaze and do prioritization on several levels.
Linked to Strategy work, they need to have a proper discussion on prioritizing what focus area and what goal to go for. When doing this it is relevant to bring in several potential goals or focus areas, so there can be an actual decision on what to prioritize. By bringing together the relevant decision-making group to look at different options to discuss and evaluate with pros and cons, it is possible to reach a decision and an agreement for a period of time on what to focus on as well as what not to focus on.
Linked to Discovery work, PMs need to gather in the most relevant opportunities, what is known about them, and have a discussion around which one to focus on. This can typically be done within the product team, but it can be relevant to bring in stakeholders as well to create buy-in and shared understanding on how the prioritized opportunities supports pursued goals. Before pursuing any singular solution you should be able to roll that up into a problem or opportunity and before you start to generate lots of solutions to a problem, you need to have made the work of already prioritizing that opportunity. Working with Opportunity Solution Trees helps in prioritizing opportunities.
With the foundation laid by these higher-level prioritization efforts, PMs should pick up to 5-10 solutions at a time as relevant to think about. For these, it makes sense to go quite deep, doing the amount of Refinement, Discovery and Validation needed to have a good enough idea of what the feature would be like to do something akin to a RICE prioritization (looking at reach, impact, confidence, and effort).
Most of these solutions should steer towards prioritized goals and opportunities, but realistically there will also be some solution pushed as an emergency request or by executive fiat. For those odd ones, it often makes sense to put the work on the one that requested it to tell you why it is so important, and to do a hard slice if the solution is to be built.
Once the list of potential solutions is prepared you can put them next to each other and bring in the relevant people in a room to have a discussion, weighing the pros and cons and making a decision.
Done well and communicated clearly these types of prioritization can be at the heart of the product management process. By working with a combination of Opportunity Solution Trees and a Now-Next-Later roadmap it is possible to differentiate between goals, opportunities, and solutions clearly and bring team and stakeholders along the journey.
There is a push to do prioritization mainly on solutions, and next, there is pressure to do prioritization on each of these levels in isolation, but to make things even more complicated, prioritization in reality often means moving across levels and doing goal, problem and solution prioritization all mashed up. Don't only look at prioritizing the features, but rather look at all three levels, how they interact with each other and how to work around that.
We think about Refinement as detailing potential solutions, involving team and stakeholders, and collaborating using structured collaborative documents.
A solution can come into play via Discovery as a solution to a user problem by the team in collaboration with users, via Feedback as a user or internal request, or via Strategy as an executive imperative or as an emergency. The first step into refinement is to crisply define what the problem is and articulate the general idea for the solution. This becomes the starting point and should be formulated in a stub solution document that you can come back to as you add more details.
For smaller solutions, such as user stories or even improvements or bugs, this can often be enough, but for solutions of epic size or bigger it often makes sense to add a bit of rigor upfront. It gives both team and stakeholders confidence, and prevents unnecessary questions and confusion, saving time down the line, and also makes sense to make sure the right solution is actually pursued.
The refinement of solutions is done progressively, with checks back via Prioritization to decide to invest in detailing the solution further. As the solution is further refined, you start with pulling together the thinking done thus far across Strategy, Feedback, and Discovery by adding relevant stuff for this solution from different sources, including request emails, quotes from interviews, data that substantiate the problem, a reference to the relevant OKR, already done design sketches, and more.
If you are using an outliner, it is easy to just dump all this into the document and collapse, so you have a clear overview and won't have to scroll more and more as you add things. Keep any references on where insights came from. Try to refrain from overthinking in this step, it is a bottom-up exercise to prepare for the next step.
Next, you need to evaluate, for this particular feature, what the relevant topics to cover are, top-down, and to add those as headings to the document, so that you can structure the input you already added into the relevant headings. What topics should be covered varies across different sizes and types of solutions, but could include e.g. measure of success, target audience, customer feedback, design sketches, use cases, validation, etc. It is valuable to have a set of agreed potential topics to pick from across product teams, as that helps save time, give guidance, and also ensure consistency and ease of communication.
As the topics to cover and existing input are gathered, it is time to take a step back and do a bit of structured thinking, writing one or a few paragraphs in full sentences for the key topics. By spending a little time upfront to lay out the premise for the solution more clearly, a lot of time can be saved down the line. Asking yourself what the most critical issues for this solution will be. It could be risky assumptions to validate, a choice of approach for the solution, a first stab at articulating the solution as a set of user stories, what user flow to choose from, and more. Make sure to type explicit questions to be decided where relevant.
As you go progressively deeper in refining the feature it makes sense to pull in the team, to figure out more details e.g. story mapping out what user stories to include, and the details around those as well as figuring out what questions need to be resolved and deciding on those.
Problem solving and communication go hand in hand, and so if you have done the structured thinking in previous steps you are now in a position where you are able to communicate your thinking around this solution in an effective top-down manner, which is appreciated by both team and stakeholders. If you have articulated explicit questions, it will be easier to facilitate the myriad of micro-decisions that need to be made during refinement.
Beyond how to develop the feature itself, it is also important to think about what the rollout plan is in terms of what it means for e.g. marketing, support, and compliance. When figuring this out, it is often most effective to bring in the relevant and affected teams.
At the end of this process, the feature is ready to go into Delivery.
We think about Validation as identifying your most risky assumptions and testing them with experiments before building your features, as well as following up on sought outcome with analyses afterwards.
For all solutions, big and small, it makes sense to have a think about what could go really wrong and mitigate that. For sizeable solutions, epics or bigger, it makes sense to do more validation.
Before you go ahead with any sizeable solution, take a step back from just doing Refinement to try to figure out the risks, what could go wrong. Try to uncover assumptions relating to four aspects: value (whether it actually would be valuable to users), viability (whether it fits with out business model), usability (whether users could use it), and feasibility (whether we could build it without too much effort). To some extent this should be done already during Discovery for goals and opportunities, but many assumptions crystalize only at the solution level.
Then, across assumptions, assess potential impact (how bad would it be if they go wrong) and certainty (how sure we are of them). For the risks with high potential impact, and high uncertainty, set up an experiment to learn more, as that is cheaper than investing to build the feature only to find out later there was a big problem.
Then there is the art of figuring out what experiment can be run to learn more about the assumption, short of building the feature, and then running that experiment, following up on it, then feeding the results back and interpreting what they say about the solution.
Identifying and assessing assumptions is also valuable for finding pure problems, assumptions where you upon further reflection realize that it is virtually certain that they would cause problems. Those problems don't generally require an experiment, but need to be handled right away. Problems with a big enough impact that can't be mitigated, can be seen as blockers to even doing the feature.
However, no matter how you try to figure out the risks in advance and do experiments to validate them, you can never fully know whether a solution will achieve the desired results before you actually build it.
You can't be entirely sure it will work, because there is always the risk that you missed something, and so you need to follow up to validate the result. That is why, already upfront during Refinement, you need to think about how to measure success, how to track that, as well as what analysis should be done some time after delivery. Implementing a solution is more than just coding, and so setting all of this up should be made as part of the rollout plan for the solution.
We think about Delivery as the combination of development and rollout, both building the actual feature and doing all the other things required to make sure it lands in the hands of happy customers.
During Refinement, you collaborated with the team and stakeholders to figure out the details for how to best build the solution, and captured that thinking in an epic document. The initial high-level solution (epic) was broken down into smaller increments (user stories, tasks, and subtasks).
Sometimes the move from refinement into development is described as a "handover". That is a mistake, as that silos the product and tech teams with a brief touchpoint in the middle. A better way to think about it is as a gradual transition, where the developers are part of the refinement, adding details such as decisions, designs and acceptance criteria to user stories over time, and where there is room for some details to be added or changed rather late into development, based on the technical reality that the developers encounter.
By using a bullet outliner for this you can outline the increments and add details to them as sub-bullets without the document growing unruly. As you move into development you then create tickets in e.g. Jira, and as you do it is valuable to keep the connection to the relevant parts of the document, creating links back and forth between the issue tracker and the relevant parts of the document.
The PM should also be involved in quality assurance, making sure that what is developed ensures the intended user experience. This is best done in close collaboration with the development team.
Delivering a solution does not end with shipping it. You also need to make sure it is rolled out in a way that gets it into the hands of the users, that all practical issues are handled, and that it is followed up upon. This can include coordinating marketing activities, making sure there's proper support documentation, recording a product demo with the sales team, ensuring all compliance demands are met, and so on.
Already during Refinement, before moving into Delivery, these issues need to be thought of and captured in the epic document, which should have a section for rollout. This means collaborating with anything from marketing and support to legal figuring out issues, coordinating plans, and then coming back to execute during delivery.
A critical part of the rollout is communicating with users about the release. How this is done varies depending on the size and type of solution and the type of company. Sometimes it is done with release notes, communicated individually to users that requested the feature and/or more widely in something like a newsletter. For releases of bigger solutions, it can make sense to go all the way and do a proper product launch.
Linked to Validation, rollout should also include a follow up analysis to be conducted to check whether the measure of success was met.
