I’ve made a lot of roadmaps in my time. In fact, in the first three years I was at WorldRemit, I counted that I represented our company roadmap in 10 different ways. This reformatting was always an attempt to make the roadmap work harder: to bring more focus, communicate more effectively with stakeholders, keep a growing team joined up.
Yet most roadmaps have a big problem in common. They’re just variants on lists of features, typically arranged on a timeline (albeit a vague one). And the problem with a list of features is that the rest of your company, and your clients, think it’s a commitment. That creates a lot of external pressure to build the things on the list, even if they don’t really solve a problem, or they solve a problem that’s no longer your most important one.
The default behaviour of a team with this kind of roadmap is to complete one feature and then start developing the next one, even if the context (strategy, user needs, competition) has changed.
The wrong conversation
As a product manager, these lists trap you into having the wrong conversation. In big companies, a top-down culture often ensures that senior managers and stakeholders hand down features to teams to deliver. Similarly, when you join a start-up, the founders often come up with what to do, and if you create a list of features, they’ll immediately start to fill it. That backs you into a corner of being an order-taker, whose role is just to deliver these features in the best way possible.
A feature roadmap also puts you in a position where you can win the battle, but lose the war. Picture this: it’s the end of the year and you’re standing in front of your management team, explaining that you delivered every feature within the estimate you’d given for it. Leaving aside how completely implausible that is, they might be shouting back at you that all the metrics they care about are going in the wrong direction. That’s completely possible when you’re working through a feature-list roadmap: perhaps your features didn’t deliver what you’d thought, but you carried on doggedly delivering them anyway.
So how do you escape the feature roadmap, and start having the right conversation?
Start talking about outcomes
You need to say no to features and start talking about problems. You need to start talking about outcomes. What will the world look like if your team succeeds in the next year? How will your customers feel, and what will they now be able to do?
Over a given time period, each team should commit to a particular outcome, rather than to a roadmap of features.
Like all good goals, the outcomes you set should be measurable, and also something that the user and the business would recognise as valuable. For example, an outcome like “the user sees more marketing messaging” is not valuable to the user, and it doesn’t directly move a business metric.
A good outcome might be something like: “users should be able to sign up in half the time”.
That way, instead of the product manager committing upfront to features they think will deliver the outcome, the whole team can own the problem. That’s one major benefit of this approach: it places more autonomy within teams, letting each member bring to bear their expert knowledge and creativity. The team will know it’s done when users can sign up in half the time, not when the features are shipped.
Being clear about your outcome opens up a wider range of possibilities than focusing on a particular feature.
Edward de Bono in his book Lateral Thinking gives a great example of this when he tells the story of a problem faced by executives of a large company. The company moved into a new skyscraper and discovered that the builder had failed to put in enough elevators. Employees were disgruntled because there were long waits for the elevators. Most of the executives argued that they should work to find a way to speed up the elevators, or drive a new elevator shaft through the building, but instead they came up with a totally different solution.
They installed mirrors around the entrances to the elevators. People were so interested in looking at themselves that they no longer noticed the wait for the elevator. The outcome they’d really needed to solve for was not the lack of elevators, but the frustration of the employees. They were able to find a much cheaper way to solve that than building new elevators.
Fewer features
Another benefit of thinking this way is that you stop loading up your product with features that users may not want. An outcome-driven approach will likely lead the team to work more on improving existing features, to get the maximum impact from them, rather than just adding new things on top of them. It might encourage solving problems in a non-technical way: sometimes the answer is better copy, or forming a partnership.
It might lead to them working more on things you don’t typically think of as features. I was speaking to a peer who works at a major e-commerce company, where their most important metric is conversion rate. When they conducted a retro at the end of the year, they discovered that the biggest improvements in conversion rate had come not from the new features they’d added, but from some of the technical improvements that they’d made, such as image optimisation that sped up the loading time of their site.
It might even lead to them retiring features that get in users’ way.
But like most ideas, it sounds good until you actually try it. I want to spend the rest of this post concentrating on what can go wrong, and how to avoid it.
What can go wrong?
1. You Don’t Have a Clear Company Strategy
Firstly, and most importantly, this approach will definitely fail if you don’t have a clear company strategy.
At WorldRemit, we start with our company goals for the year and use them to derive the mission of each team. From that mission we create our quarterly objectives and key results.
I have seen many teams come unstuck by jumping straight to the bottom parts without doing the hard work of making sure there’s a unified company strategy that everyone across the business believes in.
2. Your team doesn’t know how to validate ideas
The second issue that causes this approach to fail is if your team doesn’t know how to validate ideas. This is particularly likely to be a problem if you’re transitioning from a top-down culture, or a feature-focused approach.
It’s a whole blog post in itself, but I use the framework below to guide how and when we use user feedback in our process to validate our ideas.
3. You haven’t got business buy-in
This is often the biggest obstacle to transitioning to an outcome-focused approach. There are a few different ways to approach this problem.
- Explain yourself. Sometimes we don’t take the time to explain our methodology from first principles. There can be an assumption within the technology world that everyone should just “get it”, and if other good companies do things this way, why do we have to justify ourselves. But people are surprisingly receptive if you explain yourself properly. Use metaphors from worlds that people understand. If I were leading an expedition, and I told my group I wanted them to build a bridge, then they might end up spending a lot of time trying to find the right materials, or they might end up building a bridge that wasn’t strong enough to support the whole group. But if I tell them I want to get the whole group across the river, they could solve that problem in lots of different ways — building a raft, finding a narrower point of the river — and they’d know they weren’t done until they had all got across the river.
- Ask stakeholders for input on the causes of problems, not solutions. If you ask a question like, “We’re building our roadmap for next year. Are there any features you think we need to include?”, you will inevitably receive a response like, “We need to include a blue widget on the landing page with a video telling people how the service works”. Instead, you should orient your question around the problem, for example, “Next year our objective is improving the conversion rate on the landing pages. Do you have any ideas about what’s causing drop-off?”. Then you’ll receive constructive responses more like, “We think people don’t convert because they don’t know how the service works”.
- Give people the evidence that less is more. Sometimes it only feels like you’re doing your job if you keep adding more features. But there’s a lot of good evidence to say that less is more. When it started using an experimentation platform, Microsoft found that a third of the features it delivered actually had a negative impact on the product, and a further third had no impact at all.
- When they won’t budge on a solution, propose a test. Find a low-cost way to test a solution, formulating that test as a proposal relative to the objective.
4. What do you do when teams’ work overlaps?
If you’re creating a feature backlog, it’s very easy to make sure teams are working on discrete areas of the product. But when your teams have backlogs based on objectives, rather than features, you might encounter clashes. Sometimes a feature would advance the goals of more than one team — in which case the team for whom it’s the next most important thing to do to advance their objective should pick it up. More challenging is when the work of one team acts against the objective of another team: for example, a feature to reduce fraud may also have a negative impact on conversion. That’s where your product team has to negotiate together, and see the bigger picture.
So, back to that roadmap…
I’ve explained the benefits of an outcome-driven approach and how to overcome a few common pitfalls. But it’s time to admit that sometimes, you still might need a roadmap. Especially for things in the nearer term, there might be external groups who need to know when you’re delivering something. Aside from anything else, an indicative roadmap can help reassure people.
But you have to change the mindset that sees it as a list of commitments, and that allows shipping features to become more important than delivering outcomes.
So it’s also worth reminding people that our metaphors are broken. You can only make a roadmap for places with roads. And, from both a product and an engineering standpoint, that often isn’t what companies are working on these days.
You’re exploring new lands. You know where you want to get to — that’s your outcome — but there’s no established route to get there. So you’ll probably set out, and if you’re measuring yourself correctly and you’ve got good feedback loops in place, you’ll be able to course correct and quickly iterate towards your outcome. But you could only draw the complete roadmap with hindsight.
So it’s time to take a new approach: forget the features and focus on the outcomes.
