By Heather J. McCloskey for ProductPlan — About our Guest Author


Leading product within an organization and captaining a ship have more in common than you might think.

As product people, we are tasked with captaining the product ship. We’re responsible for calling the shots; we have to not only steer the ship and ensure our team is on board with our planned course, but also react to rapidly changing conditions around us. All the while, we’re being thrown about by an unpredictable sea of ideas and opinions almost daily. Everyone (especially executive stakeholders) seems to think their version of the product roadmap is what’s best for the business.

But as the hypothetical captains of the ship in this metaphor, we’re well aware we can’t ride the strongest current and expect to reach our intended destination safely. We also can’t anchor ourselves and wait for calmer seas before we sail forward.

How can we effectively plot out the course of our ship’s journey without letting opinions and ideas lead us astray?

Business Objectives and Product Vision: The Product Manager’s North Star

Both types of captains in our metaphor need to make sound, strategic product decisions to ensure their respective ships stay on course. And with the constant flow of opinions and ideas, the best route forward isn’t always clear.

In times of uncertainty, sailors can look to the skies for guidance. The moon, the sun, and the stars all serve as valuable high-level navigational guides.

Similarly, seasoned captains of product know to look to their own metaphorical north star when feeling lost. High-level business objectives and a strategic product vision come together to form the perfect north star for product organizations.

Together, business objectives and strategic product vision form a product north star, a guiding light to follow through times of uncertainty.

They also serve to remind us of the importance of focus. We can always look to them to see if we’re heading the right direction, and as such they frequently remind us that the strongest current (or the opinion of loudest person in the room) isn’t always the best route to follow to get there.

Hunting Down the Elusive “How”

While celestial bodies, like business objectives and product vision statements, are excellent high-level navigational aids, they rarely give us all the answers we need. They tell us where to go in the mid to long term. But, they don’t tell us how to get there.

Despite having ever-present references of where to go, captains need to determine the best course to take based on ever-changing conditions. They also need to ensure they keep the crew happily working together (and not tempted to mutiny).

Similarly, product managers are left with questions about the illusive how:

  • How can I come up with an effective product strategy that doesn’t leave the rest of the crew feeling salty?
  • How to decide between two equally compelling features which gets built first?
  • How can I course correct to reflect changing conditions and learnings?

Fortunately, product managers don’t need to earn their sea legs to get answers to these questions. Usually the how is a matter of simply finding objective frameworks for product decisions, listening to input from your team, and being willing to correct course as needed.

Here’s some tried and true tactics for accomplishing all three of these things through thoughtful product roadmap prioritization.


Techniques for Prioritizing your Product Roadmap

1. User Feedback and Behavior

Your customers are a great source of information to help you prioritize product initiatives. This prioritization method entails looking at customer requests and feedback to identify trends. What features or improvements do customers request most often? Are the customers making those requests high-value? Are they coming from a group of customers who are likely to churn?

You can also go beyond simply listening to what customers say and actually see how they interact with your product. Session recordings can help you identify frustration points (E.g. thrashed cursor or Rage Clicks) or “sharp edges” within your product to find opportunities to improve. If a particular area of your product is a frequent source of frustration, it may be worth prioritizing.

When to use:

Looking at user feedback and behavior can help you better understand the value of an existing list of initiatives.

2. Value versus Complexity

The value versus complexity model for feature prioritization takes a rather popular business decision making quadrant and helps apply it specifically to product decisions. Through countless conversations with product managers, we’ve learned that this method is fairly common due to how easy it is to apply.

You start with a list of potential features and estimate their potential business value as well as the approximate amount of complexity and effort involved to build them. Then, you plot each initiative on a grid like the one above.

The features that land in the high value/low complexity section are your “low hanging fruits” features that are a good starting point. On the opposite end of the spectrum, the low value/high complexity features are probably not the highest priority to work on.

When to use:

The value versus complexity quadrant is a good prioritization technique if you need a quick way to compare a list of features based on quantitative estimates. It also is a good tool for explaining the why behind product decisions to stakeholders due to its visual nature.

3. Weighted Scoring

With ProductPlan, product teams can use a weighted scoring model for their prioritization decisions.

A screen capture of ProductPlan's weighted scoring in action.

The weighted scoring model is similar in nature to a value versus complexity prioritization model. You can use scores to assign different weights to different strategic benefits and then weigh them against costs.

In the example above, we’ve assigned weights across a series of benefit categories which tie directly into business objectives. Then we did the same for costs, looking at implementation costs, operational costs, and also considering risk in our example matrix.

From there, we assigned scores to these categories for every feature on our list to prioritize. Based on the weights we assigned to each benefit and cost, we were able to reach a quantitative score and rank for each initiative on our list.

When to use:

Weighted scoring models are useful for product teams who need to make objective decisions about feature prioritization and need to consider multiple factors in those decisions.

4. Buckets (Kano model)

Many people elect to use a “bucket” approach to feature prioritization, more formally known as the Kano Model. Most of the time, this model is used to understand the relationship between customer delight and product function and use that information to prioritize a balanced roadmap.

Using the Kano Model, features are categorized in the following buckets:

  • Threshold features: the functionalities that you simply need in order to sell the product.
  • Performance features: features that help ensure customer satisfaction increases.
  • Excitement features: Features that yield an extreme amount of customer delight. They may not be “necessary” features, and your customers might not even notice if they weren’t there but their mere existence creates “delight.”
When to use:

The Kano model is useful for teams with various differing objectives who need a way to keep a balance between all of them.

5. Buy a Feature

Playing a round of “buy a feature” can help you understand how important specific features and functionalities are to stakeholders and even customers. The process is simple but can be a fun activity for getting your team involved with the prioritization process. Start out by making a list of potential features and giving each one it’s own “price.” You can come up with the prices based on the estimated costs associated with developing each feature.

Once you’ve created a list of features and their prices, hand out Monopoly money or some other “currency” of your choice and have your participants purchase the features they want. Most likely you’ll see some people putting all of their “money” on a single feature while others spend their feature allowances on multiple items.

At the end, you’ll have a list of prioritized features.

When to use:

Buy a feature is a technique that’s best to use when you need a quick, interactive way to understand where a group of people see the most value across a list of features.

6. Opportunity Scoring

Opportunity scoring is a method often used to identify opportunities to better meet customer needs. This customer-centric prioritization approach takes into consideration two factors: feature importance and satisfaction with the existing solutions. You start by asking customers to rank or score the importance of a list of features. After that, you have them rank or score their level of satisfaction with the feature.

Based on these inputs, you can generate a list of opportunities: features with high importance scores and low satisfaction scores.

When to use:

Opportunity scoring works well when you need to determine where to make incremental improvements to a list of pre-existing features based on customer satisfaction.

7. Affinity Grouping

Affinity grouping works best when done as a team activity, and it can be a rather fun one at that. Start by having everyone write down their ideas on sticky notes and put them on a flat surface. After you’ve come up with a decent amount of ideas, you work with your team to group similar ideas together. At the end, the team gets together to rank or even vote on each group.

When to use:

Affinity grouping is best used by teams who are collaboratively trying to come up with a general direction. This sort of brainstorming helps teams figure out what they should build.

8. Story Mapping

Story mapping is commonly used to define tests and minimum viable products (MVPs). There are several resources available out there about story mapping best practices, so I’ll share just a high-level overview. It is basically a visual way to develop your product backlog and delineate sprints.

To conduct a story mapping session, you start by creating task-oriented user story cards. Then, you group them together into categories and work each category into a step by step workflow. Once you’ve created these workflows, you can prioritize each group. After this, you can break down the workflows into either releases or sprints.

When to use:

Story mapping is great when you need to take larger concepts and break them down into workable tasks. It’s useful for determining what your MVP will look like and identifying the releases that follow.

Smart Roadmap Prioritization Means Smooth Sailing

Captains may be the ones steering the ship while standing at the helm, but they can’t see everything from there. That’s why they listen to their crew, who can share what they see and know to give them better perspective.

Listen to your team, be open to hearing multiple opinions. But also be objective and mission-driven with your plan. Get the full story before you make decisions.

Remember: your product roadmap is no place for emotional decisions. But under pressure, it’s difficult to completely remove emotions from decisions. That’s where objective product roadmap prioritization frameworks come into play.



About our Guest Author: You can find Heather J. McCloskey at the intersection of product and marketing. She currently works at ProductPlan where she helps product managers find better ways to prioritize, build, and communicate their product roadmaps. When she is not writing about product management, she is an avid cave diver and houseplant collector.