Introduction
Roadmaps help you envision a future direction for your product. The roadmap represents a snapshot of the current thinking at a point in time. It’s a sequence of possible next steps in the evolution of your product, implying order and completion. The roadmap can be a useful tool to consider different perspectives, discuss options, and make a decision that can be supported.
Roadmaps come in many different flavors. Some look more like schedules with overlapping features against a timeline. Others place features in groups that show a desire to deliver them together as part of a release or within a period of time, such as a quarter.
Several years ago, I first noticed the addition of measurable goals on Roman Pichler’s GO Product Roadmap. This represented the first shift I had seen towards evaluating product success based on goals rather than the delivery of features. Over the last few years, the idea of outcome roadmaps has been introduced and appears to be gaining interest, no doubt inspired by the popularity of OKRs and the emergence of new product discovery concepts (e.g. Opportunity Solution Tree, Mobius Loop, etc.).
The Case for Shifting Towards Outcomes
In the late 20th and early 21st century, the dot com bubble burst, leaving behind many failed startup companies because they built things that didn’t solve important customer problems. Put another way, just because you can build something doesn’t mean you should. Despite this lesson, many organizations focus a lot of energy on delivering more features faster and faster, to outpace their competition. These situations are often characterized as feature factories or a “build trap“, as coined by Melissa Perri. You might also hear the term output used to describe feature production.
In order to make sure the right things are being built and that they result in solving problems, we start by making sure we understand what our customers need and find problems to solve or opportunities to create a whole new experience that benefits them. Generically, these are often referred to as outcomes and preferred over output. You might also hear objectives, OKRs (objectives with measurable targets), and product goals used to describe these.
Features are still needed, but each is only one possible option to solve a problem. We do not assume that each feature idea needs to be built and we can discard any that are ineffective, in favor of another that might solve the problem.
Why It’s Hard to Make the Shift
Despite the case for an outcomes first approach, it’s challenging for people and organizations to shift towards thinking this way. First, it’s a new muscle that people have to build. Learning how to define outcomes takes time. Second, the business imperatives and culture may not currently allow for you to make this shift. It’s far easier to focus on people delivering faster and asking when things will be done than understanding complex customer needs and behavior. Please understand I am not advocating for slow delivery, but thoughtful outcome driven delivery.
How a Roadmap Path Can Help
I firmly believe those outcome roadmaps are a viable long-term option for those that can make the shift. While trying to discover a way to help people get there, I first had to understand some different options that people might be willing to try and what they might find in each option. What follows is a catalog of roadmap types along with a progression from schedule and feature-based to outcome-based roadmaps. The merits of each will be described, and it is my hope that you will find value in identifying where you are now and which you might be willing to try next to help you create successful outcomes.
The Roadmap Path
Without further adieu, here are the roadmaps I’ve discovered. The path is meant to represent a continuum from features to outcomes. It is not a step-by-step guide. You may choose to experiment with one or more of these and move along the path at your own pace. Similarly, you might decide to stop permanently along the path at a spot that best fits you, while others may go all the way towards outcome only roadmaps.
No Roadmap
Some products and organizations don’t have a roadmap. While you can be successful without a roadmap, it’s harder to align in the future direction without one. We often see product teams and organizations as reactive based on an influx of requests from stakeholders and customers. These groups are often struggling to keep up with the volume of requests and are missing opportunities to change how they serve their customers. One of my favorite examples is a team that creates custom reports. When given the time to think more strategically, think roadmapping, they often discover they can offload the customization to the people that want the reports, thus creating new opportunities for them to serve their customers with the additional free time while customers can work at their own pace to create the reports they need.
Schedule of Committed Features
More often than not, when people mention roadmaps, they are referring to a schedule of committed features. Because of their layout, these roadmaps draw comparisons with Gantt charts and discussions around parallel work and start to finish or start to start sequencing of feature delivery. There may be some discussion around the value of delivering features in a particular sequence but is most likely driven by dependencies between work or delivery teams. These roadmaps are often used to track progress against the features after they’ve started. The most common questions center around when things will be done and any delays associated with them.
Features with Flexible Dates
In this version of the roadmap, the start and end dates for features become vaguer as they are placed within a release, or a fixed duration as long as 3 or 6 months, sometimes longer. The features that are closer to the current time are firmer, but features farther out are negotiable.
Some versions of this will color code categories of features. This allows them to see patterns in the roadmap to determine whether any reordering should occur. For instance, you might move similar things together to create more focus and finish earlier. Alternatively, you might balance the work across categories over time.
Outcomes Now along with Features Throughout
This version is similar to the last, but we also add measurements of success, usually in the form of an OKR, an outcome with measures of success, to validate work in the next release or quarter. This is the first time success is marked beyond just delivering a feature. The longer-term portion of the roadmap does not define any success measures or outcomes.
Both Outcomes and Features
Outcomes become more prominent in this version of the roadmap, and are often weighed equally or more heavily than the features they accompany. People are reluctant to get rid of features, so this serves as a nice bridge. Each feature should be solving a specific problem and be measurable to prove the efficacy of the solution. As you see the types of problems that are being solved you can identify patterns and determine the impact of the direction you’ve set in the roadmap. From here, it’s easier to make adjustments to optimize the value of your work.
Outcomes Only
Easily the most polarizing roadmap, the outcomes only roadmap does not list features and is squarely focused on making an impact. For organizations or product groups that adopt this, they are moving towards an investment in outcomes. They know there can be multiple problems they could solve that might achieve the outcome. Likewise, whichever problem they pick could have several solutions. They leave these decisions open to determine the best option nearer to the time it’s needed.
Now What?
There are many materials I’ve linked to in this article, and many more you can find on your own, that can help you learn more. In an upcoming article, I will share some techniques to generate a roadmap of outcomes and use it to shift from feature to outcome roadmaps. In the meantime, see if you can identify where you are along this path and if there’s another option you’d like to explore to start or improve your focus on outcomes. I hope you find value in this path and that you will work to understand how an outcome roadmap might serve your organization.
