20/36 : 🧠 Outcome based Product roadmaps?
An Outcome is a measurable change in customer behavior.
👋 Hey PMs
We’re thrilled to announce our Product Discovery Course!
🎓 "From Pre-Discovery to Solution Execution" is a comprehensive course on product management techniques and strategies.
"The BEST INVESTMENT you can make is in YOURSELF " - Warren Buffet
What is a product roadmap?
A product roadmap is a document that communicates the short- and long-term initiatives that each team will work on—the ‘how and when’ of the overarching product strategy. Both the ‘how’ and ‘when’ will change over time—especially in product teams that are continuously iterating based on user and market research.
The product roadmap is more than just a step-by-step schedule for how business objectives will be achieved and how the product strategy will be executed. It’s not a list of features or a product requirements document—and it certainly doesn’t have to include dates if you don’t need them.
By acknowledging that a roadmap is a living, changing document, it removes the idea that it’s a definitive static document
Who are roadmaps for?
Roadmaps come in several different forms and serve a variety of audiences:
Internal roadmap for development team: These roadmaps can be created in several ways, depending on how your team likes to work. Some common versions include the detail about the prioritised customer value to be delivered, target release dates and milestones. Since many development teams use agile methodologies, these roadmaps are often organized by sprints and show specific pieces of work and problem areas plotted on a timeline.
Internal roadmap for executives: These roadmaps emphasize how teams’ work supports high-level company goals and metrics. They are often organized by month or by quarter to show progress over time towards these goals, and generally include less detail about detailed development stories and tasks.
Internal roadmap for sales: These roadmaps focus on new features and customer benefits in order to support sales conversations. An important note: avoid including hard dates in sales roadmaps to avoid tying internal teams to potentially unrealistic dates.
External roadmap: These roadmaps should excite customers about what’s coming next. Make sure they are visually appealing and easy to read. They should provide a high-level, generalized view of new features and prioritized problem areas to get customers interested in the future direction of the product.
Why should I create a product roadmap?
The biggest benefit of the product roadmap is the strategic vision it illustrates to all stakeholders. The roadmap matches broader product and company goals with development efforts, which align the teams around common goals to create great products.
For organizational leadership, the roadmap provides updates on the status of work and “translates” developer tasks in Jira into non-technical terms and a format that’s easily understood.
For product owners and managers, roadmaps unify teams working on high impact product enhancements and allow them to communicate priorities effectively with adjacent teams.
For the developers themselves, roadmaps provide a better understanding of the “big picture,” which allows team members to focus on the most important tasks, avoid scope creep, and make fast, autonomous decisions.
What’s an outcome-based roadmap?
Traditional roadmaps follow a waterfall/Scrum-fall approach, with a list of features relying on a strict delivery timeline, often mapped a year into the future. None of which help us understand why we need particular features, or, how to prioritize one over the other.
We use outcome based roadmaps to communicate a high-level strategy describing the outcomes we want to achieve, as opposed to outputs. The focus shifts from outputs to outcomes and protects us from the aforementioned dangers of a more traditional approach.
Outcome: The way a thing turns out; a consequence.
Output: The amount of something produced by a person, machine, or industry.
Outcome-based roadmaps provide:
Visibility while enabling the team to prioritize and plan based on value
Clarity and alignment between sponsors, stakeholders and the product team
Autonomy and empowerment for product teams to solve problems, rather than implement solutions
Space for user feedback in the product development process, with time allotted for learning and implementing changes
By centering the product conversation around outcomes, we become feature-agnostic and enable our team to use their expertise to explore the solutions that solve the unique needs of users.
We optimize for learning and allow the team to use their expertise which provides a sense of purpose and leads to a better product.
How to get started with outcome-based roadmaps
Let’s go through the four foundation stages of developing outcome-based roadmaps, starting with long-term planning (in years!) and gradually moving to short-term (weeks). It is important to note that your whole team needs to be involved in this process, along with stakeholders—but don’t worry, the process shouldn’t take longer than half a day.
Outline of the outcome-based roadmap-building process.
Outcome-based roadmaps provide:
Visibility while enabling the team to prioritize and plan based on the value
Clarity and alignment between sponsors, stakeholders, and the product team
Autonomy and empowerment for product teams to solve problems, rather than implement solutions
Space for user feedback in the product development process, with time allotted for learning and implementing changes
Current-Next-Future roadmap
The now, next, later roadmap helps teams to clearly communicate priorities and timeframes.
It’s perfectly suited to fast-paced environments with ever-changing priorities, like businesses that use agile methodologies. Teams can quickly and easily keep stakeholders in the loop with any roadmap fluctuation by using now, next, later roadmaps.
It’s important to note that the now, next, later roadmap is not a finalized plan — or even a concrete statement of intent. It’s a tool to be used by businesses that understand how plans can change at the drop of a hat and teams that have the flexibility to pivot at the last second. It is there to remind you of the product and business vision. It’s simply a view to the bigger picture, with wiggle room to handle any changing requirements.
Stages of the now, next, later roadmap explained
The beauty of the now, next, later roadmap is in its simplicity. But for the sake of avoiding any doubt, let’s break down each stage of this roadmap template in more detail.
Understanding “Now”
The “Now” stage focuses on what is being worked on already. This first stage can be both practical and executional, depending on the needs of the team. It allows teams to easily track high-level issues and focus on specific features that are currently being worked on.
Say you’ve just come up with an idea for an app, your first steps — the “now” — would be to go out to the market and seek proof of concept and market validation. If you’ve already validated the concept, the thing to do ‘now’ might be to start developing wireframes. If you’ve already got the wireframes, the thing to do ‘now’ might be to test those wireframes with users. And so on.
Understanding “next”
Next up is the “next” stage, which focuses on what’s to come. What’s on the schedule for the next few months? What do we hope to achieve? What’s the next stage in the development cycle?
This is the stage where you start communicating priorities to your team and stakeholders. It’s also where the now, next, later framework starts to shine, as it offers a clear and useful level of segmentation. This does however mean your “next” stage could look completely different compared to your “now” stage, but don’t worry about that. While it may look strange, it is all covered by the same framework, which means all the stages will naturally flow into each other.
When it comes to developing apps, this “next” stage could outline principles for going to market or display the role of the sales team when it comes to the product launch.
Understanding “Later”
If that “next” phase is starting to look a little bloated, then you’ll be pleased to learn about the “later” part of the now, next, later roadmap.
We know how tempting it can be to bundle every single task into the “next” stage, even if those tasks aren’t essential. This is where the “later” stage comes into play. This stage is for tasks that are in the product backlog that aren’t urgent or crucial to the product but may offer further value if pursued.
During this stage, you can visualize any aspirations for the product and look ahead to how the product may evolve over time. So for an app, this may include future feature updates or UX overhauls.
Building a now, next, later roadmap
Simple ideas come with simple executions, and your now, next, later roadmap doesn’t need to be any more complicated than a Kanban-style board like the now, next, later example shown below.
Best practices for the best roadmaps
Building and maintaining product roadmaps is an ongoing process to embark upon with your team. There are a few simple ways to set yourself up for success:
Only include as much detail as necessary for your audience
Keep the roadmap evenly focused on short-term tactics and how these relate to long-term goals
Review roadmaps on a regular basis and make adjustments when plans change
Make sure everyone has access to the roadmap (and checks it on a regular basis)
Stay connected with stakeholders at all levels to ensure alignment
What is an outcome-based roadmap?
Communicate, collaborate, and align with your stakeholders on the what and the why with this now-next-later roadmap.
The outcome-based roadmap helps outline the potential scenarios for the product. Product teams can use an outcome-based roadmap to better communicate, collaborate and align with stakeholders on the what and the why of product development. With our outcome-based roadmap template, you can get started reaping those benefits in no time at all!
How do you create an outcome-based roadmap?
An outcome-based roadmap differs from other roadmaps a product team might use, in that it’s focused on the overall goals and objectives of the product development, rather than features or sprints. These goals will also often be critical to the success of the business.
Tony Ulwick of Strategyn has been quoted saying: “Without knowing precisely what target you are trying to hit, your chances of actually hitting it are slim.” And that’s exactly what an outcome-based product roadmap helps to avoid.
How do you create an outcome-based roadmap for yourself?
Step 1: Meet with the team, and key stakeholders to (re)agree on your product vision, strategy, and objectives.
Step 2: Distill these high-level goals into actionable ‘wins’ for the product development team.
Step 3: Build and design your outcome-based roadmap (we’ve got a template for that!) and put priorities in place.
Step 4: Share your outcome-based roadmap with the team and have it tattooed on their arm (we’re joking, of course, but the team should consider this roadmap as the holy grail for project planning.)
Why use an outcome-based roadmap
Now that you understand what an outcome-based roadmap is, the big question is, “Why use one?”
At a very high level, an outcome-based roadmap will prioritize specific outcomes a product should achieve rather than the traditional approach of listing features which should be developed. At its core, the outcome-based roadmap is about strategy rather than tactics. This helps product teams adjust their focus from the fine-grain day-to-day feature building and instead zoom out a bit to look at the product through a wider lens.
So, what’s in it for a product team looking to deliver the best possible product? The benefits of using an outcome-based roadmap include:
Providing context for items on the roadmap and prioritizing features based on outcomes rather than tactical elements.
Ensuring product strategy is properly communicated while aligning key teams with that strategy. Focusing on strategy rather than features means an outcome-based roadmap will make sense for all stakeholders rather than just development teams.
Giving product teams more autonomy to make informed decisions aligned with the product's long-term goal.
Shifting the team's focus from the minutiae of specific features and updates to more holistic, strategic outcomes.
Example of an outcome-based roadmap
The best way to understand exactly how outcome-based roadmaps work is to look at an outcome-based roadmap example.
Let’s consider a fictional stock control and order processing SaaS product called “StockPal,” and let’s imagine that our long-term strategy includes two key long-term objectives. In this case, here’s what an example of an outcome-based roadmap might look like:
Product name: StockPal
Strategic goal #1: Improve the efficiency of order processing
Key outcomes:
Reduce order processing time by 50%
Increase order accuracy to 99%
Improve customer satisfaction rating by 10%
Strategic goal #2: Enhance the capability of stock control
Key outcomes:
Reduce out-of-stock incidents by 50%
Reduce over-stocking by 25%
Improve inventory accuracy to 95%
As you can see, this roadmap focuses on highly specific outcomes, like a reduction in key metrics, which will result in the efficiency of order processing and stock control capabilities of StockPal.
If this were a traditional feature-focused product roadmap, each element of the roadmap would be far more tactical. For example, rather than “Reduce order processing time by 50%,” this item might be “Upgrade the server back-end for order processing” or ano
their specific technical improvement.
Another example of an outcome-based roadmap
