Product prioritization: Doing the important things

Published in

Product Coalition

8 min readSep 25, 2018

After thinking about product discovery, in this second post going through the product build-measure-learn loop, we’ll focus on OKRs, roadmaps, and prioritization techniques.

Start with WHY

As Simon Sinek says in his book “Start with Why” (here’s his TED talk), the cornerstone of every company is to know crystal-clear the vision and purpose of its existence (Jim Collings would refer to the focus on a single defining idea as the ‘the hedgehog concept’). Sinek provides a useful framework for his approach: the Golden Circle. At the center of the Golden Circle is WHY. The next concentric circle is HOW. And finally, the outermost circle is WHAT.

Why — Vision
How — OKRs
What — Roadmap

Once you know the WHY, you can move forward into determining how you’ll achieve your mission and what you’ll build to fulfill it.

Objectives and Key Results (OKRs) are useful to translate the vision into short-term stepping stones. Andrew Grove explained the methodology of “management by objectives” (MBO) in his book High Output Management:

The idea behind MBO is extremely simple: If you don’t know where you’re going, you’ll not get there. MBO is largely designed to provide feedback relevant to the specific task at hand; it should tell us how we are doing so we can make adjustment in whatever we are doing if need be.
The one thing an MBO system should provide par excellence is focus. A few extremely well-chosen objectives impart a clear message about what we say “yes” to and what we say “no” to.

There are two questions to be answered with OKRs:

Where do I want to go? (Objective)
How will I pace myself to see if I am getting there? (Key results)

Set the milestones

OKRs reduce the risk of moving in the wrong direction. Perfectly executing the product backlog but failing miserably at contributing to the success of the company. Like the Cheshire Cat told Alice: “If you don’t know where you’re going, any road will get you there”.

However, OKRs alone are not enough. Knowing the why without an execution plan is just a wish. To get sh*t done we’ll need a roadmap to show the way.

As with life, the benefits of building a roadmap lies not in the destination but in the journey. The exercise of backlog prioritization forces us to diverge and analyze all the ideas and stories to achieve our objectives. It also gives visibility to the team and internal stakeholders nurturing our view with theirs.

When prioritizing the backlog we should think about the near future. A roadmap for the next three to six months. Planning OKRs or roadmaps further prevents learning and being agile. Jason Fried and David Hansson wrote in their awesome and to-the-point book “Rework”:

Plans are inconsistent with improvisation. And you have to be able to improvise. You have to be able to pick up opportunities that come along. Sometimes you need to say, ‘We’re going in a new direction because that’s what makes sense today’

Roadmaps should be dynamic, fluid, not carved into stone. They should not be a release plan nor a listing of features. As Jared Spool wrote when companies talk about features they are saying, “Look at us. Look at what we can do.” When companies talk about customer's problems, about the why, about the vision, they are saying, “Look at what you’re dealing with. Look at how we want to help.”

The goal is to think about what ideas we’ll be pursuing. To communicate and align the path we’ll be taking in order to achieve our OKRs and the vision. To decide what opportunities to tackle and -most important- which ones not to.

Decide the HOW and the WHAT

Being a Product Manager involves listening to the multiple needs of many stakeholders. A different UX design, a new feature released by the competition, a new airline sales have to integrate asap, some landing page for marketing, small changes in the URL for SEO, code refactors… Since you want to help, you say yes to almost every request. It’s extremely easy to say yes.

As a consequence, you grow an infinite backlog of to do’s, your team gets demotivated and your stakeholders start asking why it’s taking you so long. In the end, we can’t even remember the need you were trying to solve. They say the road to hell is paved with good intentions. So does crappy products.

Start getting the habit of saying no. As Basecamp (Jason Fried, David Heinemeier Hansson, and Matthew Linderman) book “Getting Real” says:

Make each feature work hard to be implemented. Make each feature prove itself and show that it’s a survivor. It’s like “Fight Club”. You should only consider features if they’re willing to stand on the porch for three days waiting to be let in.
That’s why you start with no. Every new feature request that comes to us — or from us — meets a no. We listen but don’t act. The initial response is “not now.” If a request for a feature keeps coming back, that’s when we know it’s time to take a deeper look. Then, and only then, do we start considering the feature for real.”

After the discovery phase, deeply understanding your WHY and saying no a few times, you end up with a themes-based, reduced and easy-to-handle to-do list for the following months.

Now, where to start? We’ll look deeper into three of the most popular techniques: effort-impact matrix, the Kano Model and opportunity scoring.

Effort-Impact Matrix and RICE method

My preferred method for prioritization is the effort-impact (or cost-benefit) matrix. The simple idea behind it is to evaluate opportunities based on its business value and its relative complexity for implementation.

Just get together with your team, draw two axes on a whiteboard and start discussing where each initiative should be placed. It’s important to notice that prioritization has to be approached as a team activity. Not only to get everybody on the same page but also to get different perspectives and improve your estimates (the “wisdom of the crowd”).

What to do with each quadrant? Low hanging fruit should be addressed first. It’s the famous quick win. Then, I would recommend moving into the high-impact high-effort square and evaluating which is the most strategic story to move forward although with considerable effort (is there a way to reduce the cost?).

You should focus on low-complexity low-impact stories only if you have idle resources and no high impact story to develop. Lastly, the high-complexity low-impact quadrant is a no-go and I recommend you to kill these requests.

Easy, right? For estimations, using “high”, “mid” and “low” will do. The idea is to prioritize one story relative to the others. I believe this method understands the problem of estimating exactly the cost, time of development (see the ‘planning fallacy’) and knowing upfront the value that it will deliver.

Tip to better use the effort-impact matrix: Try to break big stories into smaller things. The smaller it is, the easier to estimate. Learn fast. One step at a time.

The RICE (Reach, Impact Confidence, Effort) method is really similar but adds two new dimensions to the analysis: reach and confidence.

Regarding reach, I believe this is already included in the impact analysis. The added value is understanding if the impact of the story is due to a huge benefit for a few users (maybe a strategic segment) or a small gain for a lot of them. On the other hand, confidence is useful especially in the “investigate” quadrant to focus on stories with less uncertainty regarding its value and complexity.

Kano Model

The Kano model is focused on looking at potential features comparing the delight it will provide to users against the cost needed to get it done.

In summary, you need to map your features with:

Basic features: things your product needs to have in order to meet customer demands. Having these features won’t make a user pick you ahead of a competitor but not having them will drive users away
Performance features: these are not disruptive or highly innovative features but as you improve the customer satisfaction will increase. Performance attributes are those for which more is always better. Conversely, a weak performance attribute reduces customer satisfaction.
Excitement features: these developments will yield a disproportionate increase in customer delight. No user will switch to the competition if you don’t have them but if you do you’ll gain a huge competitive advantage.

As you succeed at meeting basic user expectations for your product, you should move into the satisfiers without forgetting about hitting a home-run (delighter) every now and then.

ODI

The outcome-driven innovation or opportunity scoring is a gap analysis that comes from the Jobs-to-be-done theory. Anthony Ulwick defined the main goal of ODI in his book “What customers want”:

Companies struggle to define, indentify and prioritize opportunities. In the outcome-driven paradigm, an opportunity for growth is defined as an outcome, job or constraint that is underserved. And underserved outcome, in turn, can be defined as something costomers want to achieve but are unable to achieve satisfactorily, given the tools available to them. These underserved outcomes point to where customers want to see improvements made and where they would recongnize the delivery of additional value.

We can see ODI as a quantitative approach to JTBD. To apply this method you’ll need to send a survey to a statistically valid representation of your target audience. Then, ask them to rate the importance of the outcomes/jobs you have defined and to which degree they are satisfied with the current solution (both using a 1 to 5 scale).

Once you have the results, you’ll need to calculate the percentage of people that rated 4 or 5 each feature and insert those numbers in the opportunity algorithm:

Opportunity = Importance + max(Importance — Satisfaction, 0)

Identifying the overserved and underserved areas of opportunity, we can focus on the features that truly add value to our product and avoid investing further resources on areas with little space for improvement.