The team looks to the Product Manager to establish the product vision, to set priorities, and to act as primary liaison to stakeholders. Setting priorities- and communicating the priorities effectively- aligns the team for value creation while eliminating waste. But managing priorities and expectations is a challenging task, and as a web development and design firm we've seen lots of different ways to do it. Here are a few tools in our prioritization toolkit that we’ve used in challenging situations.

Choosing A Prioritization Framework

There are dozens of prioritization frameworks, and we won’t discuss them all here. We work with each client to establish a method of prioritization that meets their needs. To understand why there are so many different ways to set priorities, let’s look at six desirable attributes for prioritization frameworks.

• Transparency. Everybody should be able to see how the priorities are set, including past projections of value. There is no ‘secret meeting’ or ‘magic spell’ that generates the priorities. The product manager can explain where the prioritization came from.

• Consistency. The process shouldn’t change drastically from period to period. If you use a value-effort trade method this quarter, then you shouldn’t switch to participatory budgeting next quarter.

• Fairness. The process should take into account that there are often competing desires in play, and the input of one stakeholder or group should not be systematically ignored. The product manager role is sometimes described as “apportioning disappointment equally among all parties”. Dealing with disappointed stakeholders is an interpersonal skill, but it’s much more easily exercised when stakeholders perceive that the process is fair.

• Outcome-orientation. Our goals for each period, if we meet them, should tell a story that includes real outcomes. This means we don’t just prioritize features or functions individually; we look at them and search for rational, coherent bundles of features whose value is more than the sum of their values individually.

• Speed. We shouldn’t be using two person-days to prioritize one person-day’s worth of work. It really happens: sometimes business stakeholders spend days competing for resources to do a small amount of work because they have high urgency around an outcome, and because they don’t know how complex a given task actually is.

• Engagement. Getting people to actually meet and make trade-offs and give things up is difficult. But if your process is engaging, then some of the pain is removed, and it can even be fun. The key is to get feedback from all the participants, so that people stay involved and don’t feel like the process is happening ‘somewhere else’.

Imagine that you use one methodology for several quarters in a row, and you think it’s transparent and consistent and fair; but it’s not fast. You may tweak your process to dial down the other attributes in order to make the process not take up so much time.

What Worked For Us With Many Busy Stakeholders

When your product decisions affect hundreds of divisions within a company, your process needs to involve (and get persistent buy-in) from a large group of stakeholders. And it needs to do it so that prioritization doesn’t become a huge time-suck for all those stakeholders. 

Games are a great option in this scenario: many prioritization games take the edge off of disagreement by focusing on process and outcomes rather than personality. Games also illustrate the way that any process can be gamed--and usually there is greater teamwork following a prioritization ‘simulation’.

For our work with a large consumer electronics firm we did a lot of game-like prioritization exercises that were designed to engage stakeholders, get rapid feedback from a large group, and increase buy-in. 

‘Move or Add’

In this game, stakeholders take turns either adding a feature to a feature list, or moving a feature in the list (presumably to the top of the list). Everyone must take part, and each person must explain why they placed the feature where they did. Keep going around the room until all the features are placed and consensus on the order is reached. Use a thumbs up/ down consensus to wrap up if features are still being moved after going around the room a few times. 

‘Buy a Feature’

In this game, each stakeholder gets a certain amount of currency, and can buy as many features as possible with the currency they have. This is a good way to solicit opinions and information while also establishing a ranked order of features / projects. Usually players realize they can be most successful if they play jointly, collaborating to buy features together. When this happens, people start pitching their projects to each other and thereby establish coalitions.

Inspired by Strategyzer. Avatars from Open Peeps.

Participatory Budgeting

The ‘Buy a feature’ game can be played at a much larger scale through Participatory Budgeting. A structured mechanism is used to engage a broad group of actual product end-users, whether employees, customers or citizens in the decision making process. Companies wouldn’t usually act on everything that comes out of the session, but it does enable them to use the ‘wisdom of the crowd’ as an input in their decision making.

What Worked For Us To Accelerate Product Releases

Every organization could use more practice in estimating the value of their investments and initiatives. A common pattern we find is one where organizations shift focus away from value as soon as a project is approved. This leads to prioritization optimizing for other factors, such as cost or utilization. We’ve used Cost Of Delay analysis at the portfolio and feature levels to highlight the economic opportunity and drive the organization's urgency to deliver value.

Cost Of Delay

Traditional value analysis calculations like ROI translate estimates of future value to present value. They calculate the equivalent value today of a set of future cashflows, then divide that number by the total estimated cost of implementation. Delaying the most valuable project three months simply means the expected value shifts to a later time period and the ROI is almost identical.

Cost of Delay is all about converting time to value. Any time period that we fail to generate value is a cashflow lost forever because time is the most limited resource. Delaying the most valuable project three months means losing three months of cashflows. As it turns out, it is approximately equal to giving up the top three months of cashflows!

With Cost Of Delay we helped a US-based global retailer with close to $3B in annual profits to quantify their software product development portfolio. The analysis revealed an initiative that could generate over $13MM per week which had been blocked for 18 months. This had effectively cost the company $1Bn.

In this simulation “A” “B” and “C” are features.

What Worked For Us To Make The User Top Priority

In high-pressured environments teams can end up building whatever the HiPPO (Highest Paid Person’s Opinion) says. We’ve used Story Mapping to focus everyone involved on what the user will actually experience.

Story Mapping

During a ‘story mapping’ exercise the whole team aligns on a customer journey (the horizontal axis) then comes up with user stories for each stage of the customer journey (the vertical axis). The user stories for each stage in the journey are prioritized, with the most critical placed at the top of the vertical axis. User stories can then be visually grouped into releases by drawing lines on the wall.

Inspired by Kateřina Mňuková.

What Worked For Us When Speed Was Critical

Startups don’t always face the same impediments to prioritization that affect large organizations. Their process is often already transparent, because their team is relatively small and non-hierarchical. There are typically fewer stakeholders, and they’re all passionately engaged. 

The challenges startups do face with prioritization are uncertainty, time and budget. The questions go beyond features to the heart of the business model — what problem you’re trying to solve, for which customers, how you’re acquiring them, and how you’re building a sustainable business. 

In a startup the emphasis in prioritization shifts to outcome-orientation and speed. Every feature produces learning that helps refine the business model. So each priority should clearly identify and measure expected outcomes, and further develop a rationale to strengthen the business’s vision. Because startups can’t afford to make expensive bets, the priorities need to emphasize shorter feedback loops and quick decision making. 

‘Design Sprint’ toolkit

We’ve used techniques and games from Google’s Design Sprint to engage subject matter experts in collaborative design and learn quickly from the group’s ideas.

For example, during a workshop with experts in childrens’ school transitions we used a timed activity called “Crazy 8s” to brainstorm ideas, vote on them, then develop the ones that had the highest potential.

Source: Jake Knapp.

What Worked For Us When Fear Stopped Innovation

Banks are risk-averse institutions, and stakeholders don’t like to make mistakes. Consistency and transparency turned out to be the two most important factors there. 

“Value-Effort Trades”

We began by spending some time making high-level estimates of work so that we had t-shirt sizes (Small, Medium, Large) for ‘Effort’. And we solicited business stakeholders to make the same approximations for ‘Value’ (based on what they agree to be “value”- for example, revenue, growth, or usability).

And because we needed to preserve our flexibility to solve problems in design sprints and engineering sprints, we described features as problem statements rather than already-built solutions. We often do this with a speclet.

Every six weeks we introduced new epic-level initiatives and compared the value-to-effort ratio of these new initiatives with the existing initiatives that were slated for implementation in the near term. If we found something of higher value and / or lower effort, we could trade that for something already in the pipeline.

We see this prioritization technique as foundational, and we’ll often pair it with others described here- using it as a follow-on activity when there’s enough information to estimate value and effort.

------

Giving Your Prioritization Approach a Fighting Chance

No matter what prioritization approach you choose, the following techniques will give it a greater chance of being successful.

1. Establish a Time Horizon

Even though your Agile team doesn’t have a specific deadline, it’s good to have a time horizon for prioritization. A time horizon is a hypothetical evaluation point that you can time-travel to, and ask yourself, am I better off having done A, or should I have done B? With a time horizon, you level the playing field for measurements and observations. No benefits are allowed to accrue beyond the time horizon, because that would prevent you comparing all the options.

Project outcomes often have a window of time during which they bring the greatest value. Features can be delivered either too early or too late. For the startup, a time horizon might be a month or six weeks, while for the bank it might be 18 months.

2. Remove the Heat

When you’re going for engagement and widespread participation, you want to make sure that the participants are in a zone of relative comfort. If participants are hesitant about playing this game for high stakes, you could do a warm-up round with a fun topic: for example, prioritizing breakfast foods.

3. Make Bundles

No matter what mechanism you use to estimate and value prospective features or projects, the only thing that can really be evaluated is a *bundle* of features that you think you can do on a particular time horizon.

Projects and features are never really independent of each other. There are usually synergies to be gained from building things that leverage dependencies in common. And the value of completed projects / features is rarely simply additive. A revenue-generating feature, together with a usability-enhancing feature may be a killer combination.

4. Validate Your Top Priorities

If you’re prioritizing small features for a couple of sprints, the game’s results may be enough to make a decision. However, more complex changes probably won’t yet be understood well enough to persuade decision makers that one major feature change should be invested in over another. 

Take your top 5 prioritized features and have the product team spend a week developing an evidence-based speclet for each, then regroup, dissect and discuss each mini business case. With the speclets in hand the team will be able to make an informed decision about the future direction.

This approach works particularly well if it’s used to rally the team and decision makers on a cadence- for example, quarterly.

How Do You Set Priorities?

Is your team stalled while you scramble to adjust priorities? How often do you finish a sprint and wonder what you actually accomplished? How can we help you fix that?