The Product Manager’s Decision Making Dilemma

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?

Why is prioritization 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.

What does a PM need to prioritize?

Prioritization happens at different levels.

• On a goals level, one has to prioritize on the metrics, the OKRs (objectives-key-result) and the KPIs (key performance indicators to evaluate and track progress toward the objectives.
• At the strategy level, one has to prioritize on the high- level initiatives for the product.
• On an architectural level, one has to prioritize on the platform technologies, scalability considerations, interoperability challenges etc.
• At the release level, one has to prioritize on the sprints, features, user stories, epics and bugs.

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.

So how do you approach this?

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:

• New customer acquisition
• Increase product engagement
• Increase revenue from existing customers (up-sell)
• Expand product into other markets/regions/parts of the customer org.
• Customer retention

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.

• Awareness of competitors, legal adherences, compliance, technical feasibilities, security, privacy etc. are crucial considerations while prioritization. You need to ask the tough questions, once released, can it be supported and maintained? If it fails, can we handle the consequences?
• It is also important to have a common understanding amongst stakeholders of what is non-negotiable. For example, a social media product has to prioritize features that de-risk user privacy over say, working toward a new video chatting feature. A healthcare product has to prioritize efforts that make the product adhere to HIPAA guidelines vs building a new chatbot for customer service. Thus, it is important to incorporate a risk measurement exercise into your roadmap planning process.
• In addition, as you think more about the execution phase, identifying dependency risks and mechanism to unblock them should be considered in prioritization and estimation.

What techniques can I use to prioritize?

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.