4. Planning Outcome-Oriented Roadmaps

In this final part of the roadmap lesson, we will discuss how to develop an outcome-oriented roadmap. Instead of focusing on features or outputs, the focus shifts to results—what you want to achieve with your product. This is a crucial shift in mindset for building a roadmap that drives real value rather than simply delivering functionality.

Outcome-Driven vs. Output-Driven

The first thing to understand is the difference between being outcome-driven and output-driven. A simple metaphor can illustrate this well:

Imagine a coffee machine pouring coffee into a cup. The input is the process of making the coffee, and the output is the brewed coffee. But the outcome is the pleasure and satisfaction a person feels while drinking the coffee—the experience it creates.

In product development, we aim to deliver outcomes—solving users' problems or delivering value to them in a meaningful way. The goal is to create an experience or feeling of achievement, rather than just delivering a set of features.

A great way to keep an outcome-focused mindset is by using the Opportunity Solution Tree, which you may have encountered in previous lessons. We’ll discuss how you can use this tool to structure your roadmap around outcomes, not just features.

Example: Opportunity Solution Tree in a Roadmap

Consider an example where you are the captain of a ship, and your goal is to keep the crew healthy. This is your initial objective. Based on this, you have different themes or hypotheses you can explore:

Let’s say you decide to focus on healthy food as your hypothesis. From here, you can create possible solutions to test, such as offering different types of food: fruit, rice, or vegetables. After testing, you may choose fruit as the best solution. But which fruit? Should you provide apples or oranges? You test further and decide on oranges.

At this point, it may turn out that a combination of fruit and regular exercise is the most effective way to keep the crew healthy. The roadmap communicates the overarching hypothesis (e.g., healthy eating), and your team tests different solutions to achieve the desired outcome.

Communicating the Hypotheses and Solutions

The important thing here is how you communicate the roadmap. In this case, the hypothesis might be “we’re focusing on healthy eating,” and you would share this with stakeholders. The specific solutions, such as “providing oranges,” are related to the release plan, which focuses more on features and delivery timelines.

However, you can still include solutions in your roadmap depending on your audience’s needs. There’s no need to feel constrained by rules about whether or not to include solutions or dates. The important thing is that the roadmap conveys the right message to the right audience.

Transitioning from an Output-Driven to Outcome-Driven Roadmap

You might be in a situation where your roadmap or backlog is primarily output-driven—focused on features and delivery. How do you shift to an outcome-driven approach?

Let’s take an example of a feature on your roadmap that says, “HTML 5 redesign.” This is very output-focused. Instead, you could reframe it as an outcome: “By improving the mobile experience with the new design, session time will increase, and users will be more engaged.” Notice that we’re no longer tied to the specific technology (HTML 5); the focus is on the result.

Another example might be an integration feature: “Integration with Twitter and Facebook.” Instead of just listing this as an output, consider the why behind it. What is the desired result? A better way to frame this would be: “If we make it easier for users to share our product on social media, it will increase visibility and engagement.”

By focusing on the outcome, you shift the conversation from the specific feature to the impact that feature is expected to have.

Roadmaps are Constantly Evolving

Your roadmap is like a product—it needs to evolve over time. I like to use the metaphor of a growing tree to illustrate how roadmaps change as you learn more about your users, market, and needs. If something isn’t working, you remove it, adjust the path, and communicate the changes clearly.

A roadmap that doesn’t change is likely misaligned with the realities of product development. It’s normal for roadmaps to shift as new insights are gathered and market conditions change. The key is to communicate these changes transparently to keep everyone aligned.

Key Takeaways for Outcome-Oriented Roadmaps

  1. Focus on Outcomes, Not Outputs: Always aim to solve user problems and deliver meaningful experiences. Outputs, such as specific features or technologies, are secondary to the value they create for the user.

  2. Use Hypotheses and Experimentation: Structure your roadmap around hypotheses (e.g., “improve user health”) and then experiment with different solutions. The roadmap should focus on the broader themes, while solutions and releases may appear in more detailed release plans.

  3. Reframe Output-Driven Roadmaps: If your roadmap is feature-heavy, consider reframing it by asking why each feature exists. Focus on the outcome it delivers, not the feature itself.

  4. Adapt and Evolve: Your roadmap will change over time. As you gather more information about your market, users, and product, be prepared to adjust your roadmap. Communicate these changes clearly and frequently to keep stakeholders aligned.

  5. Tailor the Roadmap to Your Audience: Depending on who is reading the roadmap (developers, executives, sales teams, etc.), you may need to adjust the level of detail, whether or not you include solutions, and how specific the timeline is. Always focus on clarity and communication.

Conclusion

In this final lesson, we’ve explored how to create a roadmap that’s oriented toward results, not just features or outputs. Remember, a roadmap is a living document. It should adapt as your understanding of the market and user needs evolves. Your goal is to keep everyone on the same page, ensuring that the focus remains on delivering meaningful outcomes for your users.

To further your knowledge, I highly recommend reading “Product Roadmaps Relaunched”, one of my favorite books that greatly influenced this lesson. It's available in most bookstores, and it’s an excellent resource for learning how to structure effective roadmaps.