What Is an Outcome-Based Roadmap?

There is  an increasingly common notion in Agile that a product roadmap is more of a hindrance than a help. Some teams would be glad to do without one while arguing there is no real need for one in this environment. But how do you ensure the teams’ efforts are aligned with the product visions without one?

There is a bigger question here about the role of the product team and what they are accountable to – are they responsible for delivering on a strategy that is handed down from leadership? Or, are they empowered product teams that are accountable to achieving an outcome?  Often when teams push back on a transition roadmap, this is really what they’re pushing back on – and they’re expressing the desire to own an outcome rather than output/delivery. 

This is where the outcome-based roadmap (also know as the Theme-based roadmap) becomes key – it is an expression of the whether the Product Manager and the product team, have a strategic role or a tactical one.  There is an element of time that is expressed in the form of a Kanban chart with Now/Next/Later columns but it is kept simple and high-level, without hard dates, allowing flexibility for discovery and pivoting by the team, as they go.

Timeline-Based Roadmap (by comparison)

The real problem with the traditional timeline-based product roadmaps is that its prescriptive in telling the team what features to build and when to deliver them, without giving the team a chance to respond in terms of the best way to solve a problem, nor how much time is required to deliver.  That’s true, these are sometimes challenges with traditional  timeline-based roadmaps in top-down organizations.

Stakeholders and leadership often prefer a timeline-based traditional roadmap, since it provides ultimate clarity and predictability. This lets them know what we are going to build and when and they can in turn plan their budgets and other cross-functional resource allocations accordingly.  

There is, therefore, a tendency for some product managers to address this expectation from leadership  with roadmaps that are filled with features and delivery dates. The documents focus greatly on outputs rather than outcomes, putting affected teams at risk of becoming dreaded “feature factories” , which  in turning makes it difficult to retain top-notch creative and engineering talent. It is important to realize that Product Managers, designers, and Engineers are creative artisans at some level, and strongly desire the creative agency and ownership over the product they’re crafting.  

Feature-based roadmaps fail to communicate why features are being built. What outcomes are we looking to achieve by building features? The answer to this question is not readily obvious. But if we don’t identify what outcomes we hope to attain, how do we tell that we’re successful?

An Alternative to Feature-Based Roadmaps

The alternative which can provide a better balance between the internal needs of the team and the external needs of leadership and stakeholders, is an outcome-based product roadmap.  Rather than listing out features on a timeline, we can instead indicate rough time frames – and when we intend to address certain outcomes that leadership has tasked us with.

With a roadmap focused on outcomes, we are more likely to solve real problems and deliver more value. Context is very important in everything and that’s what you get here. With an outcome-focused roadmap, there is a context for every item and everyone can easily see why higher priority is given to one over another.

Importantly these roadmaps aren’t entirely void of time – there’s only less rigidity. Rather than indicating specific dates, time spans (such as quarters) are preferable. Some documents use Now, Next, Later for timelines, without being specific about dates. Outcome-based roadmaps can make the lives of product team members a lot more bearable and less stressful. They remove the need for shipping features frequently, even when it’s not clear how they connect to objectives.

In Agile or any form of product development, the it is important to define a plan once there is a  product vision. It is a critical tool for resource planning and to communicate how you intend to go about achieving the goals. It lays the groundwork for effective planning. But finding the right balance of providing the clarity of the plan without constraining the teams’ ability to understand and define a solution as part of the process, is key.

Connection of Outcomes to Goals & Metrics

If you’ve made it this far in the article, then hopefully you can see  why a an outcome-based approach is beneficial. And if we’re consistent I our ethos to empower Product teams to achieve outcomes rather than just output a prescriptive roadmap, then the other side of that coin is having clearly articulated goals/objectives and the corresponding metrics to measure impact on those goals.

Product teams need metrics that we can measure the effectiveness of work against. These help us to know how well features or products deliver on specific outcomes. For example, Let’s say we have an objective of increasing the number of paying users. A key result, in this case, could be, “Increase the number of paying customers by 10% by Q2.” This doesn’t imply that the team should ship specific features by a set date. We are free to work on what we think would best help to reach the set outcome.

Apart from giving room to innovation, this approach helps to avoid wasting resources. We don’t have to ship anything unless we establish a link to the achievement of the desired outcome. It keeps us from inundating users with features that they do not need as well. The focus shifts to value and empowers teams to step back and think innovatively about how to solve problems – this is something Teresa Torres speaks to with her opportunity solution tree.

And that is the benefit to the business of this outcome-based approach, is that teams have been empowered to make quick, iterative decisions as they understand the problem, opportunity and customer needs. Being more responsive to customers and the market means finding product-market fit faster, and resonating better in the market.  And as a bonus, the teams are happier and attrition drops as a result – win/win!

When to Use Outcome-Based Roadmaps

To be fair, there are times when the outcome approach is more possible and benefitcial than others.  You are likely to find this type of roadmap more suitable when you have a new or young product, especially one in a dynamic market – that’s where product-market fit is most impactful as well as when the internal complexities and need for cross-functional coordination are lightest.  There are of course times where it wouldn’t be appropriate to provide team autonomy such as a large team building a physical rocket that requires lockstep-team precision.  More often than not however, modern product teams working in software and consumer products will benefit greatly from empowering the teams to focus on outcomes rather than output – and the outcome-based roadmap is a perfect tool for taking a step toward empowered, outcome driven teams.