This is a reference guide visualizes the typical product management process, so that you can use it as a reference point when iterating on your own process. It provides some concrete guidance in the form of templates across the process. Let's get into it.
Strategy is about the general direction to achieve a desired future state. A good analogy is that a strategy is a map with a charted course and a destination.
Building an understanding of the market is a critical first step. Clarify what market you are in. Deepen your understanding of who your customers are. Stay on top of what your competitors are up to. Get a first version of this up, and then come back to and improve your market understanding over time.
Working from your market understanding, you need to clarify where you will fit in that market. Clarify what value proposition you will offer your customers and what your business model will deliver that. This is not about creating a detailed plan, but about setting the boundaries - roughly drawing the direction with a dotted line towards the destination.
When you have the map and a rough direction, it is worthwhile spending some time on thinking about the destination. What should your goal be, how will you know if you are getting there, and how can you follow up on that. Objectives and Key Results (OKRs) is a good method that allows setting clear goals but leaving the details on how to get there to be figured out along the way.
Prioritization is about what to do next to to meet business and customer needs, and about justifying and communicating that with the rest of the company.
The PM should prioritize to maximize the sought business impact specified by the strategy (e.g. in the form of OKRs). But to do this, the PM needs to do a lot of discovery to figure out what customer outcomes are likely to actually lead to that business outcome, and to be able to balance that with how technically feasible different feature output is (often stated as maximizing outcome / output).
Prioritizing is hard and requires taking multiple perspectives into account (e.g. benefit to different users, effort to implement, fit with value proposition, strategic fit). No single framework can cover all perspectives, and so intuition will always be the final arbiter. To add some rigor and credibility to the process, PMs should triangulate using several methods - when several perspectives indicate the same, it is probably a sure thing.
There is also an crucial back-and-forth between Prioritization and Discovery, that allows for first prioritizing some investigation, and then prioritizing actual development when uncertainty is removed.
When communicating priorities, there is a tension between clarity and flexibility. The business basically wants a feature release schedule. The product team won't know, and it would be detrimental to their work to tie themselves down. The best way is to keep as few things as possible locked down but to communicate a current rough hypothesis, with an understanding that things may change. It is often a good compromise to communicate this with a light-weight board roadmap.
Discovery is about working with your customers to understand the problems they have, figure out potential solutions, and to remove uncertainty around those.
The importance of talking to customers cannot be overstated. Metrics and surveys are a great, but nothing beats the deep understanding that comes from talking with a real human being. After all, "the market" consists of of individual customers. Setting up a schedule for the team to interview customers every week is a great cornerstone habit.
A critical mindset in the shift from being a feature factory is making sure to think about the problem space before diving into the solution space. This means working both top-down to create a map out the most important opportunities (your customers' needs and desires), and bottom-up to link all incoming ideas and requests to this map before moving ahead. It is much easier to dismiss features with no such link.
The real value of discovery is reducing uncertainty, and the best way to do this, is to map out and test assumptions. There are five types of assumptions to test, pertaining to:
value (will our customers buy it/users choose to use it?)
usability (can they figure out how to use it?)
feasibility (can we build it with reasonable effort?)
business viability (does it fit with our business model?)
ethics (can we do it ethically?)
To address these assumptions, there are a number of discovery techniques. By mapping and assessing assumptions across several solutions for an opportunity in one go, teams can assess tens of assumptions per sprint.
Refinement is about making sure that the most important details are agreed so that development work can be effective, and so that roll-out can be successful.
Use user stories to ensure customer focus and create a frame that all stakeholders and team members can relate to. Instead of handing over a stale set of requirements, you should have a conversation based on user stories. Anchor the user story frame by doing a user story mapping session early on, and then later by adding details to each user story.
Write documents at the epic-level based on a common template. Avoid copy-pasting by making it the single source of truth. Put the user stories into the document and let it evolve across the steps of the product management process. Use an outliner to be able to add more details while keeping the structure and avoiding cognitive overload.
Make sure that the documents meet an agreed "definition of ready" before handing over to Development, something like that
the most critical assumptions have been validated in Discovery,
there is a detailed "definition of done" across both the development team (e.g. acceptance criteria or reference designs) and other teams (see Roll-out), and
the "measure of success" is clear (i.e. how to evaluate the success of the epic).
Write non-obvious decisions on the form of explicit questions, either right within the relevant sections of the epic document or as a stand-alone decision log. Add decisions as answers, as well as e.g. potential alternatives, pros and cons. Then involve the team and relevant stakeholders and facilitate structured decision-making.
Development is about the tech team effectively delivering working software that is in line with what has been agreed, and with high quality.
Ideally, the developers have been part of discovery and refinement. If that is the case, then the role of the PM is to take a step back and support the team does their work. To make sure that the development team feels empowered, it can be helpful to have both an upfront discussion about the division of labor and an ongoing work to improve over time.
It is great if the team that handles development has access to a scrum master or an agile coach, but the team will still have a large interface with the PM. Therefore, it is important that the PM does not step away to far from the retrospectives. There is a lot the PM can do to remove roadblocks and help the team be more engaged and effective.
Even with the team involved thoughtout discovery and refinement, the PM will have a valuable and unique perspective on what is being built. Therefore, PMs should engage during the QA process to ensure what has been built will drive the desired customer outcomes.
Iteration is about following up on what has been built, both quantitatively and qualitatively, and about making use of that in further development.
Setting up and following up on metrics is a key part of iterating yourself towards a better product. Having both good metrics and a cadance of following up on them is build into the OKR method, but it is also relevant for general health metrics and for following up on the "measure of success" for built epics.
Another key part of iterating yourself towards a better product is to pay a attention to what your customers say. Gather feedback across different channels, such as interviews, support tickets, and direct customer requests. Then work to combine that into a knowledge base, so that you can find the answers you seek later.
With on all that data and feedback, you and your team will have lots of ideas. Make sure to capture these ideas. It is important to harness the creativity of the team. However, all good teams have many more ideas than they can implement. Therefore, it is important to set up something akin to an "innovation funnel", whereby you process all these incoming ideas.
Most ideas will go into "archive" or "icebox", but some should be fed back into the earlier steps. Some ideas from the team, customer requests, and bug reports go back to Prioritization step, and a few groundbreaking ideas may affect the Strategy step.
We collaborate with our customers to improve and add more templates all the time.
You can create own custom templates, either adapting an existing one, or starting from scratch.Book a demo