Most aspects of our lives are about achieving specific goals. We want to eat, so we make a meal. We want to look nice, so we assemble a flattering outfit, brush our hair, maybe apply some makeup.
All our goals require a certain number of steps and milestones to achieve them, but those individual items on the checklist aren’t the objective themselves, nor do they really capture our overall intent. Buying kale is not the outcome, it’s a step required to eventually satisfy our hunger with a delicious salad.
But when it comes to product development and the roadmaps that guide that process, you’re often hard-pressed to see the desired outcomes represented. Instead, we often see product roadmaps that are chock-full of features and enhancements that don’t mean much in isolation.
But shouldn’t the guiding document for the product strategy be more than just a set of ingredients?
Download The Product Roadmap Strategy Playbook ➜
The problem with feature-driven roadmaps
A roadmap merely consisting of individual features and enhancements placed along a timeline is quite useful when it comes to informing stakeholders about what is going to be built when. However, it really doesn’t communicate why things are being built, why that order was selected and what the end result is intended to accomplish.
Since a product roadmap is often the defining document for encapsulating the execution of product strategy, it would be awfully nice if it also communicated the objectives of that strategy, but this is rarely the case.
Roadmaps that don’t display objectives front and center can make the product development organization look like a feature factory.
This focus on delivering “stuff” versus delivering outcomes with new functionality can be exacerbated by the “success theater around ‘shipping’ with little discussion about impact,” says John Cutler on Hacker Noon, “You can tell a great deal about an organization by what it celebrates” he explains, adding that another sign of a feature factory environment is “infrequent discussions about desired customer and business outcomes. Team cannot connect work to key business and customer satisfaction metrics. Impossible to connect iterations to ‘what matters most.'”
A feature-driven roadmap can often be a side effect of a product strategy more focused on closing deals than creating positive outcomes. While revenue and new customers are certainly important to a business, sales-driven roadmaps aren’t sustainable or great in the long term.
“Features become a sales strategy. Success is measured in winning contracts from those features. Your product becomes a bloated mess,” says Dave Chalmers of Ansarada. “And for you, it can create a very non-intentional mindset to product management. You might start saying things like, ‘Some things you just can’t measure.'”
Why outcome-driven roadmaps are the way to go
An outcome-driven roadmap provides context for specific items on the roadmap and their prioritization while simultaneously ensuring that the product strategy is both communicated and consistently pursued. Everything is there for a reason, the reason is well understood, and the goal is measurable.
Let’s circle back to that dinner analogy. If you map out everything required to prepare that delicious meal, you have both an interim set of outcomes and a final outcome. Selecting the recipes and dishes you want to create has an interim outcome of a plan. Acquiring the ingredients for each item gives you the outcome that you can now start cooking. Completing the steps of each recipe gets you closer to having that dish available. Setting the table means you won’t have to eat soup with your fingers or use the tablecloth as a napkin. And this all leads up to the final outcome of a tasty supper.
Applying this logic, every required step is captured, each scheduled in an appropriate order (such as knowing which ingredients you need before you go to the grocery store and not scheduling the vegetable chopping until after you put the pan in the oven), and extraneous items aren’t added to the schedule (such as going to the gym while the cake is in the oven).
Anyone could review your plan, see that the goal is a five-course dinner, understand why things are on it and probably take over or change it if you were suddenly unavailable. When your belly is full at the end of the night you can clearly assess whether each dish was properly prepared and the meal accomplished its goal of providing nourishment and enjoyment to you and your dinner guests.
Now compare that to a typical product roadmap. There’s a date (Q1, June, etc.) with some features listed beneath it, then some more dates to the right with some more features beneath those. The features seem arbitrarily placed and disconnected. And then a year or two out the end of the date, and so does the roadmap.
Assuming that roadmap is fully executed there will be a bunch more things that the product can do, but there’s no mention of what the point of it all was. Individual features can be assessed based on whether or not they work and how many people are using them, but that still doesn’t speak to any actual meaningful outcomes. No one can look at that roadmap and understand what the intention of it all was without a whole lot of background knowledge.
Roadmapping in outcomes vs. roadmapping in themes
At ProductPlan, we’re no stranger to thematic roadmap concepts… we talk about them all the time! They bring order to the chaos of your backlog and can be a good storytelling mechanism and a rallying cry for a given release (or series of releases), plus there’s often good technical reasons to build out one area at a time.
“Theme-based roadmaps have been around for more than 20 years. The idea is that rather than have a somewhat random collection of features on your conventional roadmap each quarter, why not introduce a focus to the work and have a theme for the quarter,” says Marty Cagan of the Silicon Valley Product Group. “An example would be to have a big focus on ease of use in Q1, and then a big focus on on-boarding in Q2, etc.”
Themes are certainly a step in the right direction, but clumping features together is still listing out what things you want and not what you want those things to achieve. But if your theme is aligned with a particular desired outcome, then there’s no harm in using themes for scheduling and communication purposes.
“Theme roadmap approaches help make customers and their problems the core of everything you do as a product person,” says Marc Abraham of Settled. “When I use a goal-oriented roadmap, I always take out the “feature” layer purely because I don’t want us to be pinned down to one solution.”
Metrics and outcome-driven roadmaps
In our current, data-driven universe, metrics and measurability are driving just about everything in business. If a roadmap isn’t specific and focused on those metrics, how can the product team contribute to moving the needle?
When a roadmap is focused on outcomes, it’s not ignoring the KPIs that management cares about, it’s simply not obsessing about them. Since the metrics in the spotlight should be measuring things that will lead to desired outcomes, a roadmap concentrating on those outcomes should produce products that improve those metrics while also delivering value to both end-users and stakeholders.
“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 increased 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,” says David Denham of Workday. “Our stakeholders want the “hole” (bookings increase by 8%), not the “drill” (email campaign).”
This open implementation approach also prevents wasting resources building a specific “thing” versus devising a solution to achieve a particular outcome, which is all anyone really cares about in the end. How far you take this—i.e. do you never include a specific feature on a roadmap and only list desired outcomes—is up to you. But the more specific your roadmap gets, the more likely you are to drift into “build this” mode instead of outcome achievement.
Stop building stuff and start solving problems
An outcome-based approach to roadmapping doesn’t fundamentally change product strategy, it just impacts how your team reaches its goals. By fixating on end results instead of specific deliverables, life no longer becomes all about how much gets shipped and how fast a widget reaches the market, but whether or not objectives are being achieved.
“Another benefit of thinking this way is that you stop loading up your product with features that users may not want,” says Alex Newton Rex of WorldRemit. “An outcome-driven approach will likely lead the team to work more on improving existing features, to get the maximum impact from them, rather than just adding new things on top of them.”
Breaking out of the feature-driven mindset isn’t easy, but beginning with the roadmap is a good starting point. Your stakeholders care about results and so do your customers. Creating positive outcomes for both is the whole point, so why focus on anything else?
