Product Priority — How to Pick the Right Features for Success

The impossible deadlines, the unforeseen risks, and the utmost despair when it comes to prioritizing what should be done first are typical examples of mountains that Product Owners and their teams must overcome.

Prioritization is the issue that enchants me the most. It sits at the core of agility, and it’s paramount for the Product Owner to be at peace, knowing they fulfilled their role among the team members and stakeholders.

The most common scenario is that your stakeholders will be driven by all kinds of cognitive biases to assure you that everything is important. The problem is,

when everything is important, nothing really is.

During my 10 years working with in software, I have tested several ways to help the stakeholders and team come up with a prioritization that works for them. Some have failed, some have worked, but one stands out, so I'll share my experience with you guys.

GUT and the Beginning of All Things

In 2008, I was introduced to a prioritization methodology called GUT (Gravity x Urgency x Tendency), as a means to order bugfixes. It worked beautifully with defects, but as I tried to apply it to a product backlog later on, it failed miserably. After devoting some time to analyzing why it failed, it dawned on me:

gravity made no sense whatsoever when we were discussing new features.

I decided I needed to adapt and retest. So I started playing with what concepts could substitute gravity when we were discussing a new product. I finally landed upon relevance.

Consensus Makes the Difference

I realized I needed this technique to be based on consensus. The biggest problem with prioritization is that priority varies among stakeholders, they have a hard time understanding all they see as must-have are hypotheses, and what’s urgent for one of them isn’t even a nice to have for the other. This kind of gap is what keeps teams up at night and makes an MVP strategy simply impossible to achieve.

I started running tests with a hand voting system, consisting of a scale from 1–5 for each criteria. I needed to avoid anchoring and instead foster debate, so based on planning poker techniques, I got my testers (cofcof guinea pigs cofcof) to only reveal their votes simultaneously, and then discuss the broader disparities.

The result was astounding. We started thinking of alternate solutions, workarounds to minimize effort while increasing value, and really only prioritizing things that would represent our bets on what would result in the products success.

Testing IRL

I started testing with stakeholders and teams IRL. The outcome was even better, and by the time I got to the 5th backlog item, I had stakeholders using RUT terms to keep other stakeholders in check and ensuring the product’s health, strategy-wise

How it works

For each Product Backlog Item, you should read its definition (the story and acceptance criteria) to all participants. Ask them if there are any doubts and clarify if they do. Show the matrix and explain the 5 grades of relevance. Ask each of them to choose on of the grades, and, when you say go, show the chosen grade in one hand, all together.

Different numbers will come up. Have the ones who voted for the highest number defend their choice. Then, have the ones that voted for the lowest do the same. You’ll find new information will be revealed, and the goal is to reach consensus, not conformity, because conformity leads to conflict later on, as your stakeholders feel they didn't have their concerns considered properly. If a consensus is not clear, ask them to vote again. If a stalemate is set, ask if all would be comfortable with a number in-between.

Repeat the same for Urgency and Tendency. When you have a number for all 3 criteria, multiply them.

Example:

I, as a constant shopper, want to choose multiple products so I can make one single payment.

Relevance = 3

Urgency = 2

Tendency = 5

RUT = 3x2x5 = 30

There. That story is worth 30 points. With a score for each item set, you can order your backlog placing the items with most value on top.

Multiple uses of RUT

After some time applying this technique, I found there are 3 major uses to it.

1. Prioritization: the higher the score, the higher the priority.

2. Consensus: the amount of information that is revealed while stakeholders and team are defending their vote is amazing. They tell you things you’d never learn otherwise.

3. Value management: as you progress in your product delivery, RUT allows you to generate historical graphs on the perceived value per sprint your team is delivering. Later on, you must validate and check if that perception reflects reality through other product metrics, but RUT allows you to measure value delivery even if you still weren’t able to collect those metrics.

I am very happy to say that, as we speak, there are former and current clients of mine that are using RUT without my involvement, inside their companies, because of the joyful and productive experiences they had with it.

Want to use RUT? Have doubts or comments? I’m eager to listen. :D