Driving strategic product prioritization: best metrics and processes

---

Product prioritization is hard.  It is one of the hardest things we do as product managers and product leaders.  Sure, there are innumerable product prioritization frameworks to choose from – but how do we tie them all together into a broader process that makes sense for the business and drives productive stakeholder conversations?

But wait!  Stop right here! I hear you astute product people yelling from the back. What are we trying to achieve with all this prioritization?  Great question.  And the right place to start.

Goals: the starting point to great product prioritization

As a product leader I have multiple goals I am trying to drive in parallel:

1. Aligning resources with business goals

I want to make sure that I am resourcing my teams in a way that aligns with the core drivers of my business. I want to track the key things that are critical to driving and retaining customers and make sure I am allocating and re-allocating resources to keep those metrics moving in the right direction.

2. Ensuring productive and strategic conversations with Customer Success, Sales and Marketing

I want stakeholders to have clear visibility into how my teams make decisions around whether or not to act on a specific customer request.  And I want to shift the perspective from “We have a long list of customer demands and the product team is not delivering” to “We can think strategically about what kinds of customer requests are going to be the most valuable”.

3. Ensuring each team is building the most impactful things first

This is the classic view of product prioritization – product managers need to figure out what to build when. And, of course, prioritization is the way each team does exactly that.

Let’s start at the top.

Aligning resources with business goals

As the leader of the product organization for my company, I have multiple products in my portfolio.  For each product, I keep a mini dashboard of sorts of key metrics that I see as critical for the business.  These may be different for each company or based on the unique aspects of your product.  For me, the guiding metrics are:

1. Revenue –  a lagging indicator, but business-critical nonetheless  
2. NPS (Net Promoter Score) – controversial but a somewhat ok leading indicator for retention, and
3. SUS (System Usability Score) – because usability is hard, needs to be tracked, and, for my products, is also a leading indicator for both retention and growth

When I am thinking about how to align resources and guide my teams, I think about how we are doing on each of these metrics – our product outcomes – relative to our business goals.  Sometimes, sales are great and NPS and SUS are low so we need to prioritize iterative improvements to the core products.  At other times, NPS is fine but Revenue is lagging so we focus on driving new capabilities or offerings.  

Another way to do this would be to align each team to a core value. For example, if you have a product that is a 2-sided marketplace, you might have one metric (or set of metrics) for the demand side and another for the supply side. As you watch these metrics move from yellow to green or green to red, you can reallocate resources and prioritize efforts accordingly.

You can also take this further and have targets per segment, and then reallocate resources in favor of one segment or another as metrics and business objectives shift.

In short – you need to understand what dimensions are core for your company, define some key metrics that are easy to track and that everyone can understand and then use those as your guide rails to move resources and prioritize accordingly.

My friends at DragonBoat have taken this concept to a whole new level and even have a certification program around this type of portfolio level product prioritization.

Ensuring productive and strategic conversations with Customer Success, Sales, and Marketing

No one wants to be an order-taker.  As a product leader, the absolute last thing I want is for my team to be taking in an endless stream of customer feedback tickets from our various market facing stakeholders and just executing them one by one.  I want them to think strategically and holistically.    

At the same time, I want my teams to have productive, in-depth conversations with these stakeholders and be responsive to customer requests.

How do we square these two seemingly competing objectives?  With a product prioritization framework, of course.

When I joined my current company a couple of years ago I had a Customer Success organization that basically had the impression that Product was not listening to them or delivering on customer needs.  They pointed to a long, long, long list of customer requests and complained that no one was touching them.  And I had Product teams that were, in fact, basically ignoring most of what was coming in from Customer Success. They resolved the issues that they thought were most urgent, which often meant whichever was attached to the largest customer or the most persistent Customer Success rep. They had their own ideas about how to prioritize but this was not applied or communicated consistently.

So we built a product prioritization framework for tactical requests. We liked the RICE framework but made some adjustments to suit our products and particular circumstances. We communicated this framework broadly and repeatedly to our customer-facing stakeholders. We walked them through it and made sure they agreed with this way of prioritizing resource allocation.  Everyone understands that there are limited resources.  Once we all agree on a framework that enables decision-making on how to allocate those resources, we can all start thinking more strategically about what gets done and what sits on the back burner.

Now, when Customer Success, Sales, or anyone else has an idea or a request from a customer, they write a Jira ticket. Product reviews these tickets at a regular cadence (once per week for us) and applies points based on the framework. Tickets with higher points (we defined a cut-off) are placed into the roadmap.  Those with lower points go into the backlog.  We communicate these decisions via Confluence. Sometimes Customer Success might disagree with the pointing – that is a great opportunity for conversation to see what the Product manager may have missed or to explain how incredibly difficult this would be to build.

In the end, having a commonly agreed product prioritization framework for decision-making allows all of us to be clear and specific about the decisions we are making and enables everyone to think more strategically and holistically about everything we do.  

Ensuring each team is building the most impactful things first: the why of product prioritization

Now we get to the core of how a product manager can drive the most value.  And this is really the hardest part of the job. The team has been given a metric to optimize (let’s say, it’s to improve the SUS score in one part of the platform) and they know they have a long list of customer requests that they also need to address.  

For most people, the natural thing to do is to start sorting the feedback tickets to see which might pertain to improving usability and then start working on building those. This sorting might help to start developing some hypotheses but it really is not the best way to move the needle.  Too often we take users at their word, but most of the time, users are making suggestions that are in line with their particular view or workflow.  It is up to us to figure out the root cause of the problem and come up with ever more elegant ways of resolving these.  

Here the team needs to start digging into the data (What is the user actually trying to achieve? Where are users getting stuck in the workflow? Where do they drop off?  What features are being used a lot?  What is not being used at all?).  Data can inform hypotheses.  And then – most critically – the team needs to start actually doing user interviews and user research to figure out what is going on.

Generative user research that starts with a clean slate approach to trying to understand the problem (in this case, low usability) is the best way to find large, meaningful pain points and to unearth core problems that might not be clear from data and tickets alone. Then, combining research findings back again with data and individual feedback requests enables the team to come to a plan of action.

From there, product prioritization becomes about identifying table stakes vs nice to haves and ordering by impact and effort.  When we have a lot of potential features and need to order them by priority, a Kano survey works well to narrow down the list.  Then we need to find the path that enables the fastest route to iterative, incremental value.  Here we start thinking about minimum viable product (or rather, minimal lovable product) as a means of prioritization. Which is a whole other blog post.

So there you have it – three goals and three different means of approaching prioritization.  In the end, product prioritization is less about the frameworks and more about finding a structured process for identifying problems and making decisions.  The more clear you can make your process, the more likely you are to drive alignment across the organization and move toward more and more strategic thinking at the team level.  Which, ultimately, is the most important thing.