The number one challenge a product manager faces is prioritization. You make choices every day. How many times have you heard PMs say “data-driven” when asked about making roadmap decisions? This data-driven approach is easier said than done. More often than usual, the problem is not a dearth of great ideas.
Prioritization is all about how to choose ‘what’ to build ‘when’ and ‘why’.
Shouldn’t it be as simple as sifting through customer feedback, picking the most innovative and ‘seemingly cool’ ideas and start implementing? What makes this process so difficult?
Every product has a feedback loop, some more mature than others. Your customers provide you their ‘wish-list’ of features, your sales team has a set of requirements, they wished the product fulfilled in order to make better sales, you engineering team comes up with a list of tasks that are needed to make the product more resilient and your designers have these great ideas for a better, more intuitive UX/UI.
It is these branches of feedback loop and the emerging competing opportunities that make it extremely difficult to decide what to build next. You wish you could build anything and everything from the above list, however, capacity in terms of resources (people, time, budget) to deliver is always limited. In addition, once you release a product, you inherently promise incremental predictable value, release after release and being able live up to that promise is extremely important in order to sustain customer trust.
Prioritization happens at different levels.
At all these levels, prioritization is performed using a combination of data, instinct and a consensus amongst stakeholders, which makes it even harder to define that standard magic formula that can be applied to all prioritization exercises.
Before we dive into the best model to approach prioritization, there are a few non-prescriptive the techniques that I personally incorporate into my product planning.
Product Vision
As clichéd as it may sound, everything begins with the product vision. Once you have your product strategy defined, you plan a series of events that need to happen in order to achieve it. This plan is basically a detailed description of what has to happen within the product and what capabilities you hope to build. All prioritization decisions should then reflect that plan and be in constant check with your product vision. Every roadmap review and planning session should track progress toward achieving this vision and what would be the next steps or milestones to get you closer to the vision. In Marie Kondo’s words, When the ultimate goal is “Joy”, constantly ask yourself “Does it spark joy?”. Similarly, everything on the backlog should drive your product strategy forward and hence we need to ask, “Does this support the product strategy?”
Customer Mindset
Everyone is aware of Amazon’s 14 leadership Principles, the first of which is ‘customer obsession’.
“The number one thing that has made us successful by far is obsessive compulsive focus on the customer as opposed to obsession over the competitor” — Bezos
Now, I am not saying, what worked for Amazon, will or should work for your product. But keeping the customer at the center of every planning and prioritization exercise is key to ensure you are building things in the right direction. Also, beware as you do this, because customers will always want more, always ask for a new shiny feature the competitive product may have launched, however, it is your job to go beyond this ask into uncovering the actual need to solve a problem. You really need to go deep into revealing the real vs perceived value. What is a required vs a good to have capability? Does developing this new feature or set of features benefit a significant addressable customer segment?
Impact
What are the drivers for your business objectives and what impact does this feature have on moving the needle on those. Your eventual goal is to be profitable, however, for any company the typical business objectives are one of the following, depending on the stage of the product:
In each roadmap planning session (however often you may perform it — quarterly or bi-annually), evaluate how you are doing on each of the above business objectives.
Risk
As a PM, you are responsible for every aspect of the product, not just shipping features out the door.
There are several frameworks that can be applied to prioritization:
The MoSCoW (must, should, could, won’t) method allows you to categorize your list of requirements or ideas into the sets of critical, high-priority, desirable and future.
The KANO model, helps to understand the customer’s perspective on product features by assessing their satisfaction by identifying the basic, expected and attractive attributes of the product.
The RICE scoring model combines factors of Reach, Impact, Confidence and Efforts.
I am a very visual person and what I personally use for prioritizing roadmap initiative is the ‘Story Mapping’ method. This allows me to map features and user stories against ‘time’ and ‘necessity’ and cutting off the list to plan the MVP and subsequent releases.
First you lay out the activity buckets (which are major attributes) for your product along the horizontal axis. The vertical axis represents the criticality in terms of how important the user stories are. Groups of user stories qualify as one activity.
In order to define releases, you then mark a cut-off horizontal line, selecting stories that have fall into the same criticality level.
This visualization technique provides a clear picture of incremental product iterations and provides stakeholders a visual map of an end-to-end product version in each release. Below is an example from Jeff Patton’s User Story Mapping.
Of course there are many more frameworks out there, depending on the maturity stage and complexity of the product. No framework is perfect and the best way to create your own secret sauce for prioritization is to adopt, modify, test and test again to ultimately get to what works for you.
And lastly, always remember to keep the key principles of product vision, customer mindset, impact and risk measurement as you plan your product roadmap.