Aren’t Outcome-Based Product Roadmaps Just Roadmaps Anyway?
Product roadmaps is one of the subjects I am probably the most passionate about in the product world.
They’re controversial and usually carry a love-hate relationship stigma for many product managers. It’s because of that, that I am passionate about educating others on their benefits.
While browsing one of the online communities I am part of, someone commented that outcome-based roadmaps were just ‘regular roadmaps’ anyway, and that:
“… Any product manager that knows what they’re doing doesn’t need outcome-based roadmaps. They know they shouldn’t just be building features, and they know inherently what they’re doing. An outcome-based roadmap just sounds like a c-suite failing to construct a functional product organisation.”
Let’s tackle this, because it’s not the first time I’ve heard that product outcome roadmaps are “useless.”
If you're in a rush, here's your TL;DR:
- There's been a transition between waterfall and Agile in the product development process – if methodologies have changed, we shouldn't be using the same tools for the job.
- Timelines are better suited as a release plan, not a roadmap.
- Feature roadmaps jump to solutions, have little focus on customers and their problems.
- Product management is about the alignment of teams – from product strategy to company outcomes and objectives.
- Measurable outcomes in product roadmaps help you understand progress and continuously learn.
- Creating space for discovery and experimentation is crucial for agile development.
- Your whole team will benefit from you being more outcome-focused! (Less focus on "features", more focus on achieving maximum impact of your desired outcomes.)
A brief history of roadmaps
When addressing this it’s important to understand where roadmaps came from, how they were used, and how they’ve evolved.
I have written about timeline roadmaps before – but tl;dr:
- Before software (and even when software came in CDs) – there was an end product that needed to be delivered, with specific features that needed to be included, therefore project coordination was crucial. (Think waterfall vs agile methodologies.)
- A start and an end date had to be established in order to deliver a physical product.
- When Agile came along, the idea of an ‘end date’ or ‘end product’ ceased to exist. We’re no longer rushing to deliver a complete product, but rather constantly learn and iterate in order to continuously improve and solve problems.
There has been a transition in the product development process – so why are we still trying to use the same tools for the job?
A timeline or feature roadmap does not fit an Agile way of working.
Timelines assume that there will be absolutely no changes, that you know everything that is to happen, and that you need no further feedback on improvements. They are great for understanding releases and shipping features, not understanding customer problems.
Feature roadmaps assume you already know exactly what it is you're meant to build, without consideration of customer feedback, external or internal stakeholders, or end-users.
If this approach no longer works, then we need a new document that helps a company understand what is happening and why.
Alignment (for the product team and beyond)
So with that in mind – we need to now shift the focus to alignment through outcomes. Unlike what the OP said, a roadmap with an outcome-driven approach is not showing failure, it’s actually the complete opposite.
Roadmaps are about alignment.
- They provide the ability to communicate direction and intention.
- They communicate what is being done – ie, potential solutions and features, with a focus on strategy and discovery.
- They communicate why things are being done – ie, understanding of the positive and negative impact of releases, product-market fit, and view of the bigger picture.
- They communicate outcomes and successes, measurable changes, and what you’re learning along the way.
It’s common that product teams grow they start having different directives and initiatives, with communication potentially becoming more silo’d. This means many teams are working against each other instead of with each other.
Roadmaps help prevent that by ensuring that everyone is able to see and understand where the company and product are heading. They provide structured flexibility, with objectives, key results, and desired outcomes leading to how discovery can help shape the future.
Recording success of desired outcomes
When talking about outcome-based roadmaps, we often put a lot of focus on how we will approach the problem, not what happened after the feature has been implemented.
One of the huge benefits of having an outcome-driven approach (or an experiment-driven approach, with a Now/Next/Later product roadmap) is that product managers have the ability to write down what the outcome was. This is usually done in the ‘Done’ column, and answer questions like:
- Did you reach your goals?
- How did your success measurements stack up?
- If you failed, what did you learn?
- If you reached success, how might you repeat that success in the future?
Now I’m sure the case might be made that these things can easily be recorded on a spreadsheet.
Sure, anything can be recorded on a spreadsheet. You can also try to screw a square peg into a round hole, but it’s not going to be pretty.
This is about communicating a measurable change to your organization, and how you're achieving success towards your shared vision.
The ability to see everything cascading from the top down into the specifics of how the execution helped you achieve the desired outcome helps you learn and understand from your own process. This is not something you would easily achieve using a timeline, a spreadsheet, or a separate document that doesn’t directly tie your strategy and development work together.
Innovation through an outcome-based roadmap
Above all, roadmaps help provide a space for learning.
And that is the really huge difference between a timeline-based roadmap (or a feature roadmap) and an outcome-based roadmap that focuses on aligning your strategy.
No – a roadmap is not just a roadmap, and not all product roadmaps are built alike.
Having a product roadmap that focuses on outcomes, experiments, and learnings does not imply that you have failed in any way, shape, or form.
Roadmaps show that you are focused on how to reach success while minimizing the risk of business failure. It shows that you have an idea of the path that will help you reach your product vision, are able to align your work with planned business outcomes, and are not willing to settle for being a feature factory.
It removes the need to have to tie yourself to a specific feature or solution and adds space for product leaders to rise, learn, and lead the company towards new and innovative ideas that solve real problems.
It’s important to take the time to reflect and ask as many questions as you can prior to committing to anything. OP argues that would be done anyway – but how are you communicating that to everyone else?
Feature-based roadmap fails to do that entirely – because they are simply not suited for the job. They focus on one thing: feature delivery.
Outcome roadmaps focus on understanding the problem and add space for dynamic thinking while allowing you to execute your strategy.
Not all tools are built alike, and assumptions should not be made prior to experimenting and learning from the process.
And guess what?
Outcome-focused roadmaps can also help you with that.
If you’re considering creating an outcome-focused roadmap of your own, get a demo with Userpilot and create the perfect roadmap for your SaaS.