Product and Prioritisation

A few days ago a colleague asked me “how do tech teams prioritise the order in which they’ll do things?”.

It’s a simple question that has far-reaching ramifications. It dictates when bugs will get fixed. It dictates which improvements will never get done. It dictates how you can sell B2B. It dictates how operational teams should staff for various manual tasks. It dictates how colleagues can collaborate with tech on getting their own ideas built.

Most importantly, it’s the strongest indicator of how well a product team will perform. A product team’s success can broadly be distilled down to:

• vision (where are you going?)
• prioritisation (how do you get there?)
• execution (how good is it going to be?)

Looking forward in time, quality of both vision and execution are largely — if not entirely — subjective. How a team prioritises is a lot more tangible, which makes it an incredibly important building block for any tech team.

Yet it remains something of a mystery.

It’s mysterious to those outside tech, as there’s rarely an emphasis placed on how the roadmap was prioritised. In the team itself, Product Managers often won’t communicate the ‘why’ on a regular basis, especially as the team starts to gain trust. Even between PMs, everyone will prioritise in a slightly different way (and sometimes not so slightly).

Below, I’ve written how prioritisation should work on a macro level. The following should broadly apply whether a PM places a high value on quality (i.e. zero bugs) or driving the product forward, or narrowing the product scope, or taking on new ideas.

How should PMs think about prioritisation?

The main thing objective for a tech team is to hit their long-term vision, and for the company to survive long enough to get there. The long-term vision requires being acutely aware of what they want to be great at, what they want to be good at, and what they’re ok with being bad at.

Example: Your company sells guitar tuners. Your vision is to make a guitar tuner that doesn’t need batteries, and has perfect pitch, as this is what your customers tell you is important. Your price is going to be mid-range. You’re ok that your tuners don’t have a bunch of extra features that your competitors have, as you don’t think they’re important to your customers.

From there, prioritisation can simply become a matter of ‘what gets us most efficiently towards our long-term vision?’.

Example: Your work on guitar tuners first focuses on making them as accurate as possible, and without batteries.

The ‘survival’ part means putting out business-critical fires as you go, or taking on a strategic project that gives you leverage to hit your long-term goal more effectively afterwards. It’s hard to have people use your product, if your company doesn’t exist.

Example: Every now and then, all your tuners go out of tune at once (this is a bug). You can fix this with a software update to the tuners, and you think this is important to do, otherwise your customers will leave your company.
You also might choose to invest time in improving your internal tools that you use to make tuners. This won’t improve your accuracy or ability to run without batteries, but it does make your iteration flow faster, which makes future work have greater leverage.

Broadly speaking, the most efficient way to get to your long-term vision means building high-leverage pieces of work (i.e. what is the most bang for your buck), and building first the things that require the most learning. For example, if our long-term vision at Deliveroo is to give riders complete transparency over everything that happens in our system, then the first thing we’d want to build is something that tests that riders actually want this. If they do, you test the next thing. If not, you revisit your vision.

Example: You know that your customers want battery-free tuners, because it will make it useable anywhere, any time (and they’ve told you this). It will also take a long time for the team to build this feature, it’s a long slog. But you don’t know that they value complete accuracy, or how accurate it needs to be. Therefore, you should build and test this first. You can start to learn about what your customers want early on with this, and adapt as you learn about them. Whether your belief is right or wrong, you’ll be able to delight customers quicker by focussing on this.

Everything in-between your end-goal and now (the days, weeks, months, quarters, years) are simply steps along the road towards this grander vision.

How do PMs prioritise bugs?

Teams should deal with bugs the same way as bigger pieces of work. Solve business-critical and high-leverage first . If it’s a bug about something you want to be great at, do that first. If it’s something we want to be good at, do that next. If it’s about something we’re ok with being bad at, do that last (or don’t do it if you truly don’t care).

How can non-tech teams influence prioritisation?

The question then becomes — how can others influence prioritisation? How can ops teams guide a bug-obsessed PM towards urgent operational improvements? How can a commercial team move guide a team to plug a revenue-gap, when they are focussed on shipping new features?

The best question to ask a PM is:

What data would you need to see to change your mind?

You should encourage your colleagues to talk your language, and this question should be the first one they ask.

The rest of the company shouldn’t try to change how the team prioritises. Assuming that the tech team is aligned with the rest of the business in terms of what it cares about, then they should be broadly aligned in terms of when things get done. If a tech team is being hammered for not prioritising a certain improvement, odds are that either:

• the tech team hasn’t understood the problem the improvement solves
• the tech team is underestimating the impact of the improvement
• the non-tech person is overestimating the impact of the improvement

These situations can often be solved as simply as walking through the scale of the problem at hand, and talking through how the improvement might help.

That is how we should think about prioritisation.

Deliveroo is hiring! If you’re a designer, engineer, EM, PM, researcher or data scientist and you’d love to work with the best people and best food, hit me up!