A communication and planning tool that shows sequential outcomes that help execute your strategy and build towards your vision.
Phases
Suggested Time
2+ hours
Participants
Product Manager(s), core team, stakeholders
Why do it?
- Align our day-to-day work with the product vision and strategy
- Keep focused on one goal at a time, and move metrics incrementally
- Prioritize based on business & user value
- Establish and maintain stakeholder and cross-team alignment, collaboration and visibility
- Create a backlog
When to do it?
- You’ve started development but don’t have a roadmap
- During development, you need a way to align your backlog with your goals and metrics
- Product sponsors and stakeholders ask for more visibility into the product direction and your progress
How to Use this Method
Using outcome-oriented roadmaps, rather than organizing our roadmaps around fixed features and dates, helps us to visibly communicate what the value is of what we want to achieve while maintaining flexibility in how we implement.
Outcome-oriented roadmaps are typically created during or shortly after Inception to help frame the MVP through prioritizing multiple problems/opportunities for immediate focus. However, they are living documents that change over time.
This session is usually better to do once you have a product mission, vision and strategy already, or know the business goals and metrics your product must contribute to.
Sample Agenda & Prompts
-
Explain the difference between an outcome and an output: (5 minutes)
An Output is a thing the product does — like a feature.
An Outcome is a measurable change in behavior that drives business results. Outcomes describe the ‘why’ of a set of features and the value they are intended to deliver.
Tip/Example: For example, for a musical instrument retailer, an outcome might be “a customer is able to see our different instruments”. But this outcome can be achieved through several outputs, like sending mail order catalogs, or creating a web page they can browse, or creating an augmented reality product where a musician can see what the instrument might look like on them. Any one of these outputs could help to achieve the outcome, but one might be more successful than the other.
We don’t want to get too focused on a potentially unsuccessful output too early, so we should focus on being clear about the outcome (the “why”) during roadmapping.
Your stakeholders may be more used to features-over-time roadmaps, which focus on specific features (without context of why they are needed) and fixed delivery dates, and may not have the flexibility to release the most valuable things first. In contrast, an outcome-oriented roadmap helps us to be clear about the value of what we build, and allows us to release the most valuable things first and less valuable things incrementally after that.
-
Understand the Vision and Strategy (5-15 minutes)
If you have a vision statement for your product, write it down and put it on your board. Check to see if everyone understands it.
Tip: If no vision statement has been created, make sure the team is aligned by adding a 15 min vision exercise (Practice coming soon!) to the agenda.
Summarize the strategy for achieving this vision to ensure collective understanding.
-
Brainstorm Outcomes (10 minutes)
In groups of 3, quickly generate potential outcomes (that are in alignment with the strategic approach) to achieve the vision using large sticky notes or the outcomes cards, either printed out or in a Miro board.
Ask the team: “What outcomes do you want to deliver against your vision? Try to limit yourself to the next 6-12 months.”
For the moment, do not bother detailing them. Quantity trumps quality here.
These outcomes will form the steps in your outcome-oriented roadmap.
-
Rapid Prioritization (10 minutes)
Have groups share them out quickly. This could give ideas to other groups.
Discuss in groups which 2–3 outcomes they feel are most important. Aim for 10 outcomes across groups. Zoom breakout rooms work well for small, time-boxed group discussions remotely.
If you end up with more than 10 outcomes, consider sticking them up on the board, combining duplicates, and dot voting them down to a manageable count.
Tip: If you have a large team, ask groups to select 1–2 outcomes only.
-
Fill out Outcome Cards for each outcome (40 minutes)
Now encourage the groups to look at their outcomes, and fill in the card for each outcome, thinking about:
- The value/user benefit of that outcome
- What success might look like for that outcome
- How confident we are that users really need this
- How valuable it is for the users/the business
- (Optional) Potential features
- (Optional) Risks
- (Optional) Dependencies/Blockers
- (Optional) Target users
- (Optional) Assumptions
Take up to 4 minutes per card.
Tip: If your team has a fixed idea of what they want to build, this is a good opportunity to get them to break down their idea, think about the value it delivers, and design metrics to validate it’s delivering that value.
-
Prioritize the Outcomes (20 minutes)
Construct a 2×2 matrix, and if you’re in a meeting room, you can use the blue painter’s tape and label the axes:
- X-Axis — We think this is less effort (right) to We think this is more effort (left) OR depending on the nature of vision & outcomes
- X-Axis — We think this is easy to be achieved (right) to We think this hard to be achieved (left)
- Y-Axis — We think this will bring more value to customers or the business (top) to We think this will bring less value to customers or the business (bottom)
With the whole team, plot outcome cards according to how much value and effort you think it is on this quadrant. (You can go around in a circle, go through person by person, etc). Try not to plot any outcome as having the exact same value or effort as another outcome, otherwise nothing can emerge as a priority.
Remind the team that this doesn’t have to be a perfect or final guess on value and effort—this is roughly what the team thinks, based on what is known at the time.
Tip: Sometimes customer value and business value conflict; for example, in dating sites customers might find it more valuable to meet the right person as soon as possible, while the business might find it more valuable to keep them on the platform slightly longer. In these cases, get the product stakeholders to prioritize one of those and make very explicit whose value they are prioritizing.
At this point, you should have a 2×2 grid that shows something about what the value is and how valuable you think an outcome is, how much effort/ease it will take to build, and how confident you are that this outcome is needed.
-
Build Your Roadmap (30 minutes)
Have the team build the roadmap by prioritizing the order in which you deliver the outcomes, from things you want to do “now” (in the next few weeks) to things you want to do in the “near term” (3-6 months) and “future” (6+ months) (25 minutes). Do this on a physical board or a Trello/Miro board.
Tip: Concentrate on outcomes in the upper right quadrant first as they are high value & less effort/high confidence.
Some principles you can apply here are:
- Don’t add all the outcomes to the roadmap.
- Don’t do the things that are low value and high effort.
- We generally want to prioritize things that are high value.
- Something might seem of lower value on its own, but be necessary to do first because other highly valuable things depend on it being in place.
- Among high value things, some things might be more risky or unknown, and need to be validated first. It is often a good idea to make sure unknown (and therefore high-risk) business-critical outcomes are built and tested earlier and prioritized in the roadmap.
- It is a good idea to not work on too many outcomes at one time — for this exercise it might be helpful to force the group to think about only delivering one outcome at a time
- It is normal to have more of a solid idea about what you will do now than what you will do in the future (>6 months) – it is possible that things that are further into the future may not need to get done.
Tip: Your roadmap should regularly be re-prioritized as you learn more (see step 9); creating a long roadmap could feel daunting for the team.
-
Check the First Draft of the Roadmap, and Adjust as Needed (10 minutes)
Discuss using the following prompts:
- Does this roadmap help us move towards our vision?
- Are these the highest value outcomes for us to work on first?
If answers are not a clear yes, which adjustments do team members suggest? Repeat step 6–7 as needed.
Don’t forget to celebrate: your team has built an iteration of its outcome-oriented roadmap! ?
-
After this Session
On a regular basis, review your progress through your roadmap by asking the team to roman vote their progress through each outcome.
- Thumbs up – We’ve achieved the outcome!
- Middle – We’re still working on this outcome.
- Thumbs down – We’ve not started to work on this outcome or it’s no longer relevant.
This is to align on the team’s assessment of your progress. For outcomes that have been voted middle or thumbs down, action items need to be defined (e.g. break down outcome, focus better, revisit relevancy).
Alternatively, the team could review the metrics and assess whether the outcomes have been achieved.
Find a way for your team to capture the progress for each outcome – this could be done via color coding (e.g. green, orange, red), by using progress bars (e.g. 75% achieved), or by whatever works for you.
Following this alignment session, update your roadmap. You can do that by repeating steps 3–8.
Tip 1: Block out time on a regular cadence (~ monthly) to review your roadmap to keep your roadmap up to date. Also make your roadmap visible for everyone: Either on the wall in your office or prominently in a remote working board to be reviewed during Iteration Planning Meetings, internal and stakeholder updates.
Tip 2: Less mature product ideas often may require more frequent updating, as outcomes are validated or invalidated, and there is generally less certainty about what is right to do next. Do not worry if you have to update and change this regularly!
Success/Expected Outcomes
At the end of this exercise, you will have a roadmap of product organized sequentially in this way:
Facilitator Notes & Tips
MVP: The Minimum Viable Product (MVP) is an experiment designed to test our product’s value proposition. It’s the smallest possible version of our product that enables us to learn the most about our customers with the least amount of effort.
Additional resources:
Real World Examples
Companies adopt different formats of roadmaps. Most will have some kind of outcome/benefit written as minimal. Companies more confident of their velocity might have specific timelines, some may have more established OKRs as a company already (e.g. measured in sales targets, etc.). We have put some examples here, but the minimum they should have is outcomes and a priority order.
Recommended Reading
The GO Product Roadmap by Roman Pichler
What Does an Agile Product Roadmap Look Like? by Jeff Gothelf
