PM Skills: How to Actually Prioritise Your Roadmap

Photo by Lubo Minar on Unsplash

Prioritisation is perhaps the single biggest determiner of whether your product is successful. PMs ensure the team has a clearly prioritised roadmap.

Yet it’s not a predefined formula — else every competitor would build exactly the same thing at the same time. Prioritisation may not use a formula at all. And, despite its strategic importance, companies often don’t even have clear methods of prioritisation.

But your team must master this skill to be successful in the long run. As you ship, your prioritisation choices will determine if and by how much you impacted things that are important to your users and the business.

Prioritisation happens whether you intend it or not.

Time is the only resource you can’t get more of. You can raise more money and hire more people, but any engineer will tell you there’s only so much you can parallelise before you simply can’t build the feature any faster.

Prioritisation means choosing to do things in a certain order, i.e. trading off time. If you don’t make the choice explicitly, it will be made for you by a chaotic blend of choices made across the org and by individuals.

Prioritisation means choosing to do only a few things at once, i.e. focus. Headspace costs time. Building products requires many dozens of choices, which requires a lot of context. So the fewer things the team is doing at once, the less context each person needs to hold, which means we’re building faster.

Good teams invest the time to prioritise together.

While PMs are usually responsible for ensuring prioritisation happens, who makes those decisions can vary by company and team. It can be done solely by the PM, by the cross-functional leads (PM, EM, designer), or by the entire team. In my experience, the latter is the most expensive, but also the most effective in the long term.

Prioritising as a team is hard. It requires getting everyone to share context on all the possible problems we could tackle and everything we know about what impact we think each will have. An explicit planning period every 3–6 months can help, as everyone can set aside time together. Prioritising as a team requires getting a lot of people aligned on what are effectively educated guesses. The PM can make this easier by 1) ensuring the team has first agreed on clear goals for the period and 2) including not just the expected impact, but also our confidence level, when evaluating each potential project, so the team can discuss the risks we want to take.

But prioritising as a team brings great benefits. More points of view means we’re more thorough in our decisions. Everyone understands deeply why we made the choices we did, and so can make consistent decisions when others aren’t in the room. Every member of the team can take ownership of the items on the list because they helped put it there.

Teams operate more effectively when we’ve prioritised everything that can take up time or headspace.

Feature work is not the only thing to consider. We also explicitly prioritise technical improvements, research projects, technical investigations, work we’re doing to unblock other teams, learning time (e.g. if we’re tackling a new part of the codebase), and even strategic discussions.

Our general rule is, if it takes more than a day, it goes on the list to prioritise. This means the entire team is clear on what we’re working towards, knows what to do next, and spending maximum time steering in the same direction.

It’s always a judgment call.

When prioritising, there are quantifiable benefits and costs, including:

• Number of users impacted, impact to each user’s satisfaction or behaviour
• Cost of the work for engineers and XFN, time to impact
• Impact on competitive positioning, risks to the business

But there are also intangible benefits and costs, which cannot be measured:

• Impact to strategic progress, momentum, the team’s reputation
• Learning which can be leveraged on other projects
• Opportunity costs, likelihood of failure, project urgency and maturity
• Impact to key relationships, brand, user mental model

Some teams ignore these and simply create a formula to give semblance of scientific method. In my experience, this leads teams to miss key opportunities and orient to the short term. Prioritisation is hard — there’s no way around it — and finding nuanced signals from the noise is an art.

Some hard-earned prioritisation lessons:

• You will always have incomplete information. Balance gathering information with making progress, because the more time you spend deciding, the less time you spend executing. Have a default opinion and look for evidence that supports it and evidence that contradicts it; then, make a call. Strong opinions, loosely held.
• Aim to solve a few problems fully, rather than half of a bunch of problems. You’ve not created a worthwhile solution if you’ve only addressed half of the need. A good quick test of this: write a fake press announcement for the project. Can you clearly and concisely explain what has changed and what benefit it brings?
• Prioritise to create minimum valuable products: bring value to users as soon as you can, but don’t create more problems than you solve. For example, if the user sees a new icon but can’t figure out how to use it, you’ve just distracted them from everything else good about your product.
• If you find your team repeatedly faced with similar tough choices, set prioritisation principles to ensure you’re consistent. For example, we always prioritise audience A over B when the projects are close in impact, or we always consider X as the most important input.
• In the long run, prioritising consistently is more important than always going after the biggest objective impact. This is because a) it greatly speeds up the time you spend deciding, b) it ensures you’re working towards the same big thing, after which you could always go chase some other big thing (as opposed to inching towards many different things and never reaching any of them).
• Balance quick wins with long-term investments. This builds trust, morale, and team execution muscles, while also making progress on the high-impact stuff. Create clear milestones to divide up lengthy projects into shareable chunks so the team feels the momentum.
• You’re never going to make everyone happy. On my teams, the needs of the user come first; then, our partners; then, the company. PMs are responsible for ensuring everyone understands why the thing they cared about ended up in the place that it did on the roadmap.