Outcome-based Product Roadmaps: a missing link in Agile Product Development
I believe there is a missing link in Agile Product Development — one which causes lots of symptoms to look like problems further down the line, and something which is frequently skipped or glossed over in a one-page Powerpoint slide: the Product Roadmap.
A common misconception I hear a lot is that in an Agile environment, there is no need for roadmaps and no need for planning. This couldn’t be further from the truth — its just that these things work differently.
A Product Roadmap is a key communication tool for Product Owners and Product Managers, as to how we will strategically plan and progress towards our Product Vision.
A lot of the time, in the wild, roadmaps turn into a work of unvalidated fiction.
“Either I’m going to disappoint you by giving you exactly what we thought six months ahead of time was the best solution when it’s not, or by changing course and having lied to you.” — David Cancel, CEO, Drift
The Agile Planning Onion
As you can see, below, we are planning at multiple different levels, and as multiple different types of granularity. This “onion” should start from a Product Vision (informed by organisation strategy), and everything your day-to-day Agile team should be discussing in their Daily Standup meeting should be able to be tied back to that vision.
A problem I see with many Agile teams working in complex product environments is is they jump down a level too quickly from the Product Vision. They will begin to do Release Planning (or some equivalent big picture planning), and straight away, they are focused on features, dependencies, estimation, etc. They’re entering a feature factory. There’s a missing piece — a outcome-based Product Roadmap.
The problem with traditional Product Roadmaps
Traditional Product Roadmaps focus on dates and features, and usually sets a scope and time expectation — knowingly or unknowingly.
The structure of a more traditional Product Roadmap typically resembles a Gantt Chart — dates (in months) and features.
This is where the problem begins — as a communication tool, we are setting low-level expectations to stakeholders too far up front at a time when we know the least, when we haven’t yet gathered feedback or even left room for divergence on solutions. This list of features, are really outputs. Instead, we need to think about the outcomes we wish to achieve, and how we will know if we’ve successfully solved them.
Is there a place for feature-based Product Roadmaps?
Everything happens in context. If you are working with a highly mature product in a stable market, then yes, a feature-based product roadmap will work.
I believe that three quarters of the time, feature-based Roadmaps are used for the wrong context and assuming we are in a more simplistic environment— most of us have products in dynamic markets, with lots of competitive threats and lots of change and complexity, or perhaps we are not working with mature products. Roman Pichler’s illustration, below, outlines this.
When to use Outcome/Goal-Oriented vs Feature-Based Product Roadmaps
So, what’s the difference between a Product Roadmap and a Release Plan?
A Product Roadmap should focus on measureable outcomes. A Release Plan will focus more on outputs. Why do so many teams feel they’re working in a feature factory? Because they are not connected to, nor have skin in the game in, the outcomes. The Release Plan makes more sense when it maps back to outcome-based Product Roadmaps. The slices within it make more sense. You are iterating towards an outcome.
This also causes your “user stories” to not be user stories
Have you ever come across this scenario? You’d like to bring in user stories as placeholders for conversation — instead they seem like they’re just low level, prescriptive requirements? This is a symptom of the problem — the feature has already been pre-defined 2 levels up. User stories are meant to be about solving a problem for a user. User stories and story-map-type release plans will start working as intended when they map back to outcome-based Product Roadmaps.
Outcome-based Product Roadmaps
In an Agile environment, our Product Roadmaps should focus on the problem space (missions, themes, problems to solve, outcomes), rather than the solution space (features). Specifically, what outcomes do we wish to achieve, and how will we know we have achieved them? Of course, timelines are still important. However, focusing on timespans such as Q4 or “Now, Next, Later.”
C. Todd Lombardo suggests a simple flow to create a outcome-based Product Roadmap:
He suggests taking your Inputs (research, customer support, sales), organising them into strategic Themes, using Now, Next, Later as your Roadmap timelines, and attaching an OKR (Objective & Key Result) to each Theme. Each theme is measureable. This then gets mapped into your Release Plan.
In my context, my preference is to use quarters and timespans because this resonates more than “Now, Next, Later”, and I just call it a more vanilla goals and success metrics, rather than OKRs, but I believe the principles are the exact same.
Measuring success
Using metrics is a key part of outcome-based Product Roadmaps. For example, if we have an objective of “Increasing bookings of flights to Spain on our flights booking engine”, we should set an accompanying key results of “Bookings to Spain increase by 8% by the end of Q4.” We are leaving the solution space purposely open for our teams to innovate on how to achieve this.
If we had placed “February flights promotion email campaign to our Spain customers” into our Product Roadmap, which we’ve created 6 months in advance, we are converging on a solution too soon. Maybe GDPR will come along and our email marketing list gets decimated. Perhaps an A/B test on a landing page would be a better solution. Our stakeholders want the “hole” (bookings increase by 8%), not the “drill” (email campaign).
Sounds simple, right?
This is by no means simple. The Product Managers and teams I work with like this concept, however, it is challenging to measure success in this way. We need to partner with other teams to help us define sound metrics — they challenge us, and that’s good.
Its no longer, “did we ship on time?” (easy to measure), its “what outcomes are we achieving?” (harder to measure). Suddenly, you have to think a lot harder about what success is, beyond outputs, and how to quantify. One way to measure shifting user experience outcomes in the right direction that I currently favour is Google’s HEART Framework. There are many others — it depends on your outcomes.
Challenge your teams to innovate to focus on the objectives, and not churn out features. An outcome-based Product Roadmap is a good way to begin that conversation.
How about you? What is your experience with Product Roadmaps?