Moving from a feature-driven to an outcome-driven roadmap

Let’s start with a bit of contrast.

Company A meticulously lays out an annual plan, outlining projects and features on a precise timeline. Their product roadmap answers questions like, “Who gets resources from whom?” and “Who made their deadlines and who didn’t?”

It looks an awful lot like a Gantt chart. Employees at company A know exactly what’s going to happen and when. They get rewarded when they deliver the promised output on time.

Company B hasn’t got a clue what’s going to be built this year. But there’s alignment on which company goal they’ll be pursuing: 2024 will be all about, drumroll please, increasing revenue. They’ve set team-level outcomes, so each team has a broad understanding of how they can contribute to the company goal. Employees are rewarded for making a difference for the customer, and eventually, the business. The way there is unclear. This is understood and embraced.

So, which of these two companies do you want to work at? Most PMs will raise their hands at company B, but harbor a secret preference for company A. Let’s be honest, working at company A can feel great — you get a pat on the back for delivering features on time, your sales team loves you for jumping when they say jump, and you sleep soundly at night. Delivering output is a lot easier than delivering outcomes. It’s no surprise that most product organizations work in a feature-driven manner. But working in an outcome-driven

In this article, we’ll talk about feature-driven vs. outcome-driven roadmaps and why outcome-driven roadmaps can actually be more efficient and productive. We’ll talk about the do’s and don’ts of moving to an outcome-driven roadmap, and its dangers, and give a few examples.

The dangers of feature-driven roadmaps

It’s hard to build products that customers want, need, or love, and it’s hard to create features that drive business results. And even the best product managers are wrong most of the time about what will move the needle.

Some harrowing figures for you:

• 80 percent of features are rarely or never used.
• At AirBnB (famous for its experimentation culture), 92 percent of A/B tests are failures
• At Microsoft, about two-thirds of ideas fail

The worst feature-driven roadmaps are full of fully-formed solution ideas that are copy-pasted directly from the highest-paid or loudest person in the room, with little to no scrutiny. They include concrete timelines to make stakeholders happy and are paired with a gigantic product backlog.

Features are built because they’re requested, not because they’re assumed to have a positive impact on a specific metric. It’s safe to assume that the vast majority of these solution ideas will add no value.

The best feature-driven roadmaps outline only a few items into the future. The importance of each item is based on an understanding of the target customer and based on concrete proof points, e.g., patterns detected from customer interviews or customer service tickets, multiple sales requests, shadowing, or prototyping.

The product manager has a strong, evidence-backed assumption that this feature will move a specific metric. Around half of the items on this roadmap will still add no value. That’s OK, if they have product analytics in place to monitor feature retention and adoption, and can easily reverse their decision:

Feature-driven roadmaps provide a false sense of security that delivering a specific feature will deliver results. They feed straight into the four villains of decision-making as outlined by Chip and Dan Heath in their book Decisive:

• Looking too narrowly at a problem — Caused by diving immediately into solution modus without testing whether the problem is worth solving, or whether there might be a better alternative solution)
• Confirmation bias — Looking for evidence to support your hypothesis, disregarding everything else
• Letting short-term emotions have an impact on decisions — Such as falling in love with your solution idea
• Overconfidence

Introducing the outcome-driven roadmap

I can’t say “outcome” without thinking about Teresa Torres (if you haven’t read her book Continuous Discovery Habits, do it now), and I lean heavily on her thinking when working with outcome-driven roadmaps:

Rather than dictating which product changes will be made at which time, an outcome-driven roadmap looks like a prioritized list of product outcomes, or in some cases, traction metrics, that the team will be aiming to achieve.

Ideally, these outcomes tie back to company-level goals or OKRs. Instead of saying, “This is exactly what we’ll be doing in the future,” an outcome-driven roadmap provides a frame for how we will make decisions and shows what success looks like.

Product outcomes measure the value a product brings to the customer or business. Examples are increases in engagement, conversion, average order value, upsell, free-to-paid rate, activation, etc.

Good product metrics are a leading indicator for business metrics. For example, an increase in the free-to-paid rate is a strong leading indicator for an increase in revenue. Giving your team the task to “increase revenue” is so broad that it doesn’t give enough foothold or clarity to know what to do next.

Business metrics aren’t actionable. However, when assigned the product metric “increase the free-to-paid ratio, teams can ask themselves, “What is blocking our free users from upgrading to paid today?” They can then identify potential friction points, problems, or needs (which Teresa calls opportunities), and generate fitting solution ideas.

Your outcome-driven roadmap should be short, and continuously adapted. 3–5 outcomes ordered by priority is enough. Focus is the name of the game.

The top one or two outcomes can be fleshed out with high-level solution ideas and experiments to validate these ideas.

The do’s and don’ts of an outcome-driven roadmap

Do’s	Don’ts
Tie back ideas to company-level goals/OKRs	Commit to specific solutions (but you can present “potential solutions”)
Assign outcomes that the team can move autonomously (it’s not an issue if other teams or external factors also have an impact on that outcome)	Commit to timelines on when an outcome will be achieved. This goes directly against the principle of accepting uncertainty. If you accept that most of your assumptions will be falsified, you can’t reasonably provide a timeline for when something turns out to be true. You can still include a time component by categorizing outcomes as now, next, and later
Specify why this outcome matters	Overengineer to present a perfectly defined roadmap on day 1
Iterate and make your roadmap more concrete as things come into focus

How to move to an outcome-driven roadmap

When you’re just moving from feature-based to outcome-based ways of working, you’ll likely struggle to fill up the roadmap with feasible performance goals.

Sticking with the example above, you’re essentially telling your team to bin their old trusted roadmap, which told them to build features A, B, and C in the next three months, and replace it with the outcome “increase the free-to-paid rate.”

Please resist the temptation to reverse-engineer your old feature-based roadmap by simply assigning the ideas that were already there to an outcome. It’s far better to work top-down. Start with your desired outcome and ask: What is blocking customers from bringing the business there? In our case, what is blocking free users from upgrading to paid?

You might not know at this point, and that’s OK. Your first outcome-driven roadmap can be very high-level and include only learning goals, rather than performance goals.

Example outcome-driven roadmap v1 (lots of uncertainty)

In this scenario, the onboarding team is tasked with increasing the free-to-paid ratio. They can’t confidently say yet whether they can move this number by 1 percent or 50 percent because they’re unfamiliar with it. Their work will revolve around learning (extracting insights from five interviews/surveys with churned users) and finding something that increases the conversion rate (finding one strategy with a positive impact on the activation rate).

The acquisition team is in a similar boat. To ultimately improve the website visitor-to-sign-up rate, they’ll look for the top three reasons why visitors aren’t signing up today, and they’ll be implementing a heatmap on the website.

In a later iteration, the teams can use their learnings to make the outcome-driven roadmap more concrete and populate it with performance goals.

Example outcome-driven roadmap v2 (strong hypotheses)

Based on customer interviews, shadowing, a competitive analysis, and eating their own dog food, the onboarding team has formulated a strong assumption that by implementing an onboarding survey and offering new users a personalized product walk-through, they can drive new users to value more quickly and thereby improve the free-to-paid ratio. They commit to the aspirational goal of improving the free-to-paid rate by 5 percent MoM.

The acquisition team has learned through analyzing their heat map and five-second landing page tests that users can’t grasp quickly enough why the product is for them, and what it does. They’re confident that a landing page overhaul and a short product video above the fold will allow them to increase the visit-to-sign-up conversion rate by 7 percent MoM.

Don’t forget, these are solution ideas that still need to be validated in the real world! The teams will look for the most lightweight way to learn whether or not this solution moves the needle.

Why outcome-driven roadmaps are hard

Product leaders struggle to work with outcome-driven roadmaps for any of three reasons: they have a hard time delivering the right level of strategic direction while embracing uncertainty, the team doesn’t know how to work with outcomes, and/or the broader organization still works on a project basis. Let’s elaborate.

They struggle to deliver the right level of strategic direction whilst embracing uncertainty

Moving to an outcome-driven way of working can make things feel shaky. The reality is that they’ve always been shaky, the team just hasn’t felt it. It takes a huge mindset shift to understand and accept this. It’s up to you as a leader to provide your team with enough business, market, and product context to understand why we’re doing what we’re doing.

The product/tech team doesn’t know how to work with outcomes

You might need to slow down your pace to make sure your team can adapt to an outcome-driven way of working. Provide ample opportunity to get familiar with the metric they’re trying to move — for example, by ensuring that data is readily accessible and having weekly metrics meetings. You can start with a short high-level roadmap, focusing on learning goals, and then move to something more specific later on.

The organization at large still works on a waterfall/project basis

This setup makes it difficult to adopt an outcome-driven approach. You’ll be tempted to reverse-engineer the process and assign preconceived solution ideas (which you’ll be forced to implement by date x, regardless of whether they’ll help your user) to opportunities.

But you might have some gaps on your pre-determined feature roadmap which you can fill with experiments to drive outcomes.

Communicate openly and frequently with your leadership team about feature adoption and retention metrics and show your outcome-driven process. Perhaps you can serve as a lighthouse in your organization by demonstrating the value of your way of working.

Featured image source: IconScout