This is a reference guide that visualizes the product management process. It is an archetypal iterative process based on agile methodology that is an aggregate of 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 and iterating on your own process. At the end there are some concrete examples and implications across different aspects of PM work. For further reading, here is a guide to the best books on product management, following some influential product leaders to keep abreast of the areas you want to develop further, and the product management competence matrix to review which of your skills to improve next. Let's get into it.
The phases and activities of the product management process
Whatever degree you as PM influence the strategy you need to make sure that your work aligns with both the product strategy and the overall direction of the company.
Most PMs work in a context where the higher-level thinking about the direction the company is heading is already set by top management. They then need to understanding that thinking and own how that translates into their product domain, and not least, make sure that translation is agreed upon.
More than just knowing the direction, PMs need to know the market landscape and how their product fits into it. They need to know who their customers and the reasons they choose their product over the competition. This knowledge gives them an important lens with which to evaluate all potential product changes. PMs that work with a Product Marketing Manager collaborate with them closely on this.
Another key aspect where PMs need to align with overall direction of the company is goal setting. Goals are a way to concretize the overall direction, and enables the team to know what is working and whether they are successful or not. Ideally, near-term product goals/OKRs should be formulated as a back-and-forth between the PM and their manager.
Having clarity on who to target, overall direction, and goals, is a prerequisite for doing discovery work, which is all about understanding the users' problems and what solutions might solve them in a way takes you closer to your goals.
One of the most talked about mistakes PMs can make is becoming a "feature factory". The first step to avoid this is for PMs to embed themselves in research about their users and the problems they have. When they are evaluating potential solutions, that allows them to take a step back and intuitively know whether it really solves an important user problem.
The second step in avoiding becoming a "feature factory" is to work deliberately around specific problems that users have, to prioritize the right problems, and to think about several different potential solutions for problems. Working with Opportunity Solution Trees is a great method for this that can also help PMs achieve more autonomy in their work.
The third step, if done right, minimizes the risk of you becoming a "feature factory". It is to hold back a little bit more before developing a solution, to think in advance of what could go wrong, and if anything poses a real risk, to investigate more or do an experiment to make sure.
As a PM, you will need to be good at both capturing as many good ideas as possible from your users and team, as well as being good at figuring out when which of those ideas are worthwhile considering as solutions to take further.
PMs should strive to get both quantity and quality of user feedback. To capture as much as possible, lower the hurdle to give feedback across customer support, app, portal, interviews, etc. To get good quality, leverage contextual data and nudge customers to elaborate - learn who, what context, what steps that led up to the problem and how it was perceived.
For internal feedback from team or stakeholders the PM can often require reporters to elaborate more. The practice of "dogfooding" (using your own product) can drive lots of insights. However, internal users often have better knowledge than new users, and so that needs to be taken into account. Also, handling reporter expectations is key, to both show gratitude and be clear that no promises can be made.
To handle the abundance of input and make sure they can find relevant feedback later, PMs need an innovation funnel based on triage and categorization. Triage means making a judgement call early on. In the interest of time, some feedback can be dismissed early on, whereas some warrants a further look. Feedback should then be categorized based on a system you have set up, by e.g. who reported it, what part of the app is addressed.
Regardless of where solution ideas came from, you need to have a good way to pick the right ones to pursue further, and you need to be able to communicate and align on those choices.
Or rather "development project prioritization", as it can also be improvements, experiments, or bug-fixing, and one should avoid becoming a feature factory. One hard part of prioritizing such projects is that they come in in different activities, with incommensurable ways of evaluating - e.g. projects via strategy go by OKR, discovery by opportunity-solution-tree, and ideation by RICE. The answer is to use judgement, to find features that score well regardless of paradigm and to prioritize in several steps, e.g. define properly, do more discovery, and then refine and develop, if the project still looks promising.
PMs rarely make the prioritization by themselves, but rather in discussions together with other parts of the company. The best way to do this is to make the thinking of the PM transparent, and a common way to do this is with a roadmap. The format of the roadmap will by necessity be negotiated, where PMs often rightly strive away from a timeline of features towards for something like a now-next-later roadmap with a mix of features, opportunities, and goals. Being able to explain the thinking to stakeholders helps this negotiation.
When you identify that you potentially want to pursue a solution further, you want to collect and structure your thinking, to figure out whether and if so roughly how to do so, so that you get to a have a good starting point for discussing it further.
Wherever PMs fall between simple (like following the "One Page / One Hour" pledge) and extensive (like the "Amazon 6-Pager"), a critical activity is spending time thinking upfront to define what it would be like to pursue a solution further.
This involves:
1) pulling together the input and thinking done thus far across strategy, discovery, and ideation,
2) crisply defining the problem, the goal, and initial thinking on the solution,
3) thinking ahead on what discovery and refinement work needs to happen before it can go into development.
Done well, this enables the PM to be much more effective going forward. Read more in this guide about writing PRDs.
We have an Opportunity Solution Tree in beta!
Join our betaPRD, 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
As you start to collaborate with team and stakeholders on a potential solution, you want to effectively create a shared perspective, so that you can figure out the details of how to best make it as a feature, or find a reason not to.
Embrace user stories as a shared language. Business stakeholders, designers, developers come in with different mindsets and it is hard to even get them on the same page, let alone working together to shape the solution. However, everyone can relate to functionality in the form of a story from the perspective of a user. By doing user story mapping where you map the user stories across the steps in a journey, it is possible to work together to slice things out to find the minimum viable functionality.
A balance between structured and visual thinking is helpful in figuring out and agreeing on solutions. It is easier to provide feedback to things you can see and react to. PMs do best by working closely with their designer to iterate with increasing level of detail, progressively going from user flows, wireframes, to high-fidelity designs.
Taking full responsibility for impact means also thinking about what comes after the feature is deployed. PMs need to ensure the feature actually comes to benefit customers. This means collaborating with anything from legal to marketing and support to figure out issues and coordinate plans.
Across this collaboration, a lot of decisions will be made. A critical part of the success of a feature is getting those decisions right and getting alignment around them. Here, PMs do best to keep track of these decisions by turning them into explicit questions, and then use the questions to facilitate structured decision-making.
When you have figured out what to build, you want to hand it over to the development team, while still having an ongoing dialogue, so that you reach the outcome while empowering the team.
Handover to development should be gradual, with involvement already during refinement. However, as feature gets added as a number of tickets in the issue tracker, a new level of detail is required. Specifically, it is important to have agreement on acceptance criteria, i.e. what is required for the ticket to be considered done. This can be done as a combination of given-when-then test cases, reference designs, and, depending on how closely PM-tech works, ongoing calibration.
User stories for features/epics is one type of issue, but PMs also need to provide the development team with ongoing help to flesh out the details of minor improvements and bugs. Same as for user stories, the goal should be that it is clear what is required for the ticket to be considered done.
Given a backlog of issues (be it user stories, improvements, or bugs), the PM needs to prioritize and plan the work of the development team. Depending on context, this is best done as scrum, kanban, or something in between. The team also needs help removing roadblocks, during ongoing work and in retrospectives - typically done by the PM and/or a scrum master/agile coach.
No matter how rigorous the process for setting up and testing of acceptance criteria is, the PM should always be involved in making sure that what is developed ensures the intended user experience. This is best done in close collaboration and engagement with the development team and quality assurance.
As your users interact with your product, you want to leverage the data that generates, so that you can make better decisions all the way from strategic to feature level.
PMs need to establish a quantitative perspective on how their product is doing. This means working by themselves or with business intelligence to set up at least a few dashboards that cover their main goals/OKRs, metrics across the customer lifecycle, and user analytics across key features of the app.
One good defense against becoming a feature factory, is making sure to have a process to diagnose deployed features based on clear rollout plan and measure of success. With proper such diagnosis, and investigation of the underlying reasons, the answer is often that a next iteration of the feature is needed to reach the goal. This makes it more awkward to just move on to next feature.
Throughout your interactions with other product people and your development team, you want to contribute to developing a great team, as that is a main determinant for delivering great results.
Management is important already for junior PMs, e.g. in working towards a relationship that empowers the development team. As PMs becomes more senior, they move to also take responsibility for how PMs work together, e.g. striving towards a structure where each product team can work with autonomy while being aligned towards common goals.
It is the responsibility of all PMs to continually develop team member skills and capabilities. Calling this 'coaching' is a misnomer, as done well this covers a creative set of tactics, and goes well beyond just coaching, covering also e.g. ongoing mentoring, effective feedback, hand-picked courses, and evaluation against a competence matrix.
As companies with successful products tend to grow fast, recruiting becomes an important activity for PMs. This covers both being able to articulate company benefits to attract talent and conducting interviews and tests to select the best talent.
