Prioritization begins in strategy

Prioritization is an ever-present activity during product development: there’s constant decision-making about which features should be inserted in the roadmap and backlog, and in which order.

More often than not though, these decisions are based mostly on the opinion or gut feeling of the team or stakeholders:

“This feature is important because (I think) users will want this.”

“This will take too much time. Not worth it.”

“We will not fix this issue in the next weeks because we don’t have time for bugs now.”

“I think feature A is more important than B.”

To be constantly prioritizing is great. And there’s nothing wrong with having opinions and weighting them in for prioritization. The problem is that we’re constantly doing ad-hoc prioritization decisions, and which are based on different foundations.

For proper prioritization we need shared foundations, and that is strategy.

Of course, understanding the customer and the use of proper prioritization techniques are fundamental. But that’s not where it starts (and that’s not the focus for today’s post).

I believe this lack of foundations happens because we, as product teams, tend to focus mostly on the roadmap layer when prioritizing: we have a pool of features that are being thrown at us, and we try to prioritize them solely based on their complexity and importance, defined by us or some stakeholder. We’re solely prioritizing inside the roadmap.

But prioritization should start above that. It should start with strategy.

In practice that means:

• We should start by defining what are our product’s vision and value proposition.
• Then, we should define what specific problems are we trying to solve, or what opportunities are we trying to explore (or other sorts of goals), usually in the form of objectives for the next couple of months.
  Ex 1: Signup is cumbersome and with a high drop out rate. We want to decrease the drop rate by 10% this quarter.
  Ex 2: Many users are unhappy with functionality X from the competition. Let’s replicate it but better, and acquire 10 users from them.
• If exploring various opportunities in parallel, we should define their relative level of importance, by specifying the effort we want to allocate to each of them.
  Ex: Improving release velocity is part of our strategy, so we want to dedicate 20% our time to code refactoring.

By specifying strategy first, we’ll know that if a feature isn’t in line with our proposition value, or doesn’t have an impact on a current problem or opportunity, then isn’t relevant for our product roadmap — we have logical and important reasons to say no, which are easily understood by the team and stakeholders.

By doing this, we’ll know how much effort we should dedicate to each goal (bugs, refactoring, opportunity X, etc) during each week/sprint based on their level of importance. This will avoid us from, on every sprint, discuss how many bugs we will fix or how much time should be spent in the feature Y vs feature Z.

We still need to debate various aspects of course, and our strategy may change over time but: with strategy explicit we will, from the start, filter discussions which are irrelevant for our outcomes, and make decision making much more efficient.

Prioritization is a fundamental task of every PM, and there’s much much more to this topic than what I wrote today.

If you want to go deeper on it, I recommend you to read this and other posts from Daniel Zacarias, which describes his recommended methodology in practical detail.

If you just want a quick start to change how you and your team work, I recommend experimenting with Opportunity Solution Tree or Impact Map frameworks, which will give you already a good foundation.

If you enjoyed the read, please click the clap button to recommend it to other interested readers!

I’m Daniel, Product Manager at Whitesmith. Paper Planes is a place where I reflect on my experiences and learnings on the craft of Product Management, and share them with my team and community under the form of short blog posts.