Why Most Outcome-Based Roadmaps Fail (and How to Keep Yours From Doing the Same)

An outcome-based roadmap sounds like a good idea. Instead of a long list of context-free features and enhancements, the roadmap is constructed to accomplish specific goals critical to the success of the business. Each major release or theme has an intended impact that can even be measured and validated.

The problem with outcome-based roadmaps comes when the desired outcomes don’t actually accomplish what companies hoped they would achieve. Mapping the plan to KPIs and strategic milestones have good intentions. But it is greatly diminished when folks are betting on unrealistic results. In reality, they end up with outcomes that fall short of expectations.

The Problem With Outcome-Based Roadmaps

Despite our best intentions, humans are fallible creatures. Predicting which actions will lead to desirable outcomes is not our strong suit. We know what we want to happen, we do lots of research and planning, put in the work, and then wait to see if the results match our expectations.

Unfortunately, reality often falls far short of our predictions, and outcome-based roadmaps are no exception. While this can occasionally be blamed on poor execution, it is often simply a result of poor goal setting.

“The problem with innovation is clear,” says Tony Ulwick of Strategyn. “Without knowing precisely what target you are trying to hit, your chances of actually hitting it are slim.”


But why do product teams have such a hard time creating the right goals to achieve our objectives? Let’s look at some of the more common causes.

  • Assumptions—Every idea needs to be validated with actual paying customers. No matter how smart you are, how much experience you have, and how much subject matter expertise your team possesses. Too often, product teams use previous experience, hunches, and instincts to make plans that don’t pan out in reality.
  • Orders from the top—Not every idea comes out of the product team; sometimes the executive team provides their own set of marching orders based on the outcomes they desire. What comes out of a board meeting or management team huddle might sound good in a conference room, but it might not fly with real-life customers and fall short of expectations.
  • Lack of data—Sometimes, the team simply doesn’t have access to the data they need to make fully quantified plans. Making leaps in the absence of facts can lead to problematic expectations.
  • Sacrificing for speed—In an agile world, there isn’t always tolerance for deliberative research and decision making. Hasty judgment calls and cutting down on time for experiments and analyzing results deny teams from setting achievable and desirable goals.
  • Ignoring unintended consequences—While the focus is on what new things can be accomplished if the goal is met, teams are often negligent when it comes to considering the knock-on effects of some decisions. Although a customer may now be able to do something new, if it breaks something that used to function or creates additional work or cost for them, then the outcome isn’t ideal.
  • Focusing on technology—Technology and its implementation are the means to an end. If you don’t have the correct “end” in mind, then it doesn’t matter how great the technology may be. Focusing on what’s possible instead of what’s desirable can be a fatal flaw.

Any company can create new technologies. Many companies can solve customer problems. But the truly successful ones are achieving desirable outcomes. In short, this means that not only have they come up with a new or better way to do things, but customers are using it, satisfied with the experience, getting a great return on investment, all while being profitable for the company. If that’s not the type of outcome being targeted in the product roadmap, then companies will inevitably fall short of their goals.

How to Prepare Your OBR for Success

Creating a winning outcome-based roadmap is all about setting achievable and desirable goals, so teams must work carefully to define those intended results and ground them in reality.

Read the Product Roadmaps Guide ➜

Defining the right outcomes

Begin by working backwards from the ultimate objective. This isn’t as easy as it sounds, since interim achievements and implementation details are much easier to nail down. Which outcomes really matter to your company and your customers? Why are these things important?

It’s also important to get on the same page as your customers. Are you defining success the same way they are? For example, your team may think the goal is being able to complete a particular task, but if the experience is arduous for the customers even though it is now technically possible you haven’t truly achieved the goal.

“For long-term success – yours and the customers’ – you need to not just help your customers achieve their Required Outcome, but you need to help them do that in a way that is appropriate for them,” says Lincoln Murphy, author of Customer Success. “If it doesn’t help your customer achieve that Required Outcome in the right way – the way THEY want or need to achieve it – then you failed to deliver the appropriate experience and the customer won’t see the experience as one that was successful. Even if they achieved their Required Outcome!”

Despite our best intentions, features still have a sneaky way of finding their way onto roadmaps, even if they’re disguised as a goal or an outcome. Give each item a proper sniff test to be sure you’re not disguising a particular implementation preference or specific enhancement. Allow as much creativity as possible to emerge when trying to reach a legitimate desirable outcome.

No time to fly solo

Another critical factor is making outcome definition a collaborative group effort. The more isolated the decision making, the more likely it is that certain factors will be ignored or not given appropriate weight. Additional perspectives provide helpful challenges to assumptions and new avenues to explore.

In fact, the roadmapping process itself may prove to be more valuable than the finished product. “The process requires engagement and involvement with product partners,” says Ellen Gottesdiener of EBG Consulting. “That means customers (real users and choosers), technology partners (e.g. engineers, developers, testers, architects), and business partners (colleagues from sales, marketing, customer service, all departments involves from launch to support) are engaged in collaborative conversations, workshops, reviews, and feedback on the roadmap.”

An ongoing process

Of course, roadmaps shouldn’t be set in stone and neither should the priority of the desired outcomes. Things will change. Acknowledging that inevitability by frequently revisiting and refreshing the roadmap based on the latest learnings and updated organization-wide goals gives the outcomes that are pursued a better chance of reaching fruition.

Equally important is being unafraid to remove things from the roadmap. With new information, it may be best to park something indefinitely rather than continuing to work on it just because it’s on the roadmap.

Keep peeling back the onion

Customer interviews uncover problems they want to solve and the things they want to accomplish. But these are typically residing at the transactional level; they want their marketing campaign to drive more leads, they want to ship things more quickly, they want to reduce headcount, etc.

Taken at face value, companies can then take a whack-a-mole approach to tackle these customer desires. But while they may solve these well-articulated challenges, the more fundamental desirable outcomes often lie deeper beneath the surface.

Read Feature-less Roadmaps: Unlock Your Product's Strategic Potential➜

Measuring success

This extends to identifying the outcomes that will really have a significant impact and not just appease a complaining customer or satisfy the random demand of a stakeholder. By tying everything back to a measurable outcome, product teams move beyond checking boxes and crossing things off lists to moving the needle in a big way.

“Ensure that every goal is measurable,” says Roman Pichler of Pichler Consulting. “This allows you to tell if you have met the goal or not. If your goal is to acquire customers, for example, then ask yourself how many new customers should be acquired; or if your goal is to reduce technical debt, determine how much of the bad code should be removed or rewritten. If you don’t state a target, it will be hard to tell if you have met the goal or not.”

Remembering the big picture

Outcome-based roadmaps are ultimately all about crystallizing what the company is trying to achieve, communicating those objectives and building consensus and momentum. Although folks may think they care more about when Feature X will ship, what they’re truly interested in is how Feature X will help customers save time, save money or grow the company’s bottom line.

Being agile doesn’t mean winging it or chasing after the latest idea that fluttered through the feedback loop. Fully vetted, socialized and measurable outcomes keep everyone’s eyes on the prize as the sprints and epics run their course.