Skip to content
The corporate visionAn understanding of the current experienceThe product roadmap
Driving Your Product Roadmap from Your Experience Vision
Bruce McCarthy, C. Todd Lombardo, Evan Ryan, and Michael Connors wrote a fantastic book on the topic: .
Thinking of roadmaps as UX tools puts the company in a market leading positions because it describes real innovation (proactive roadmap), rather than playing catch up with the competitors (reactive roadmap). The trick is to integrate the roadmaps with our experience vision.
In the experience vision we should avoid describing products or service; we should keep it agnostic and describe the experience of using the product or service. The roadmap is where you start to describe the product or service.
Experience visions have three main inspirations:
We can use any combination of them to get our experience vision. They’re not mutually exclusive.
We can take the corporate vision - usually a forward looking statement that describes what the organisation thinks it wants to do in the future - and turn it into a UX Outcome. Then we turn the UX Outcome into the experience vision.
We can take the current user experience on a scale from frustration to delight and ask “What would it look like if it was delightful all the way across?” That helps us figure out where the most frustrating parts are. We then make them better, and that becomes our UX Outcomes, that turn into the experience vision.
The third inspiration is the roadmap. For each item on the roadmap, each feature (F), we can ask “How does this feature, if we do it really well, improve somebody’s life?”, and we come up with a bunch of little UX outcomes. It will turn out that those little outcomes are related to each other in some way: the experience vision.
Problems to be solved
Bruce McCarthy has this notion of Themes for roadmaps.
This is a reframing: Changing how we think about what's on the roadmap.
With Themes, we convert the features into Problems To Be Solved. Problems to be Solved are obstacles currently preventing users from getting the improvements today.
We replace the name of a feature (F) with the problem (P) it solves. For example, instead of calling a feature “Exporting data”, we call it “Making backups”, or “Have confidence”.
Sometimes problems are gonna be multiple things. For example, instead of calling a group of features “Mobile”, we call it “Access my data from any device”.
A mindset change
There are three kinds of changes: tool changes, skill changes, and mindset changes. Shifting everybody’s language from the feature to the problem is a pure mindset change.
This has two advantages.
The first advantage is that that we’re not committing to a specific technology: by the time we get to the moment we have to work on a feature, the technology might have changed, but if you have phrased roadmap items as a problem, then you haven’t committed to a specific solution. It can also happen that you can’t phrase the feature as a problem, and in that case the item simply comes out of the roadmap, because it’s not a problem anymore.
The second advantage is that, since the problems are user centered, we’re keeping the user always at the center of the roadmap, he’s dictating the roadmap.
McCarthy also helped us understand a systematic way for prioritizing items on the roadmap.
The formula is Priority = Value ÷ Effort) x Confidence.
Value can be derived by how much the roadmap item gets us closer to the vision.
Confidence comes from the research we've done.
We can establish a rule that says nothing gets added to the roadmap unless we know the problem to be solved.
Research will increase our confidence for the prioritization formula.
We'll now be researching before things are added to the roadmap, instead of after.
A formula for prioritizing items on the roadmap
Bruce McCarthy also has a formula for prioritizing items on the roadmap:
Priority = (Value ÷ Effort) * Confidence
Value can be derived in many ways: it can be the actual money you will make out of the roadmap item, or it can be how much it takes you closer to the vision, for example on a scale from 1 to 4. It is important that you use a consistent scale across all roadmap items.
Effort must be estimated in the same scale as the value (e.g. 1 to 4).
Confidence comes from the research we've done. It’s a measure, from 0 to 100%, of how much we believe in our estimated value and our estimated effort. The more we know about the problem to be solved, the easier it is to estimate the effort it will take to do it and the value. Therefore the more research we do, the higher our confidence will be, and the higher the numbers for that roadmap item will be. Therefore the roadmap items where there’s been more research will be the one that pop out. Therefore we'll now be researching before things are added to the roadmap, instead of after. We will have to invest in research to understand the problems, because if we don’t understand the problem it will not go on the roadmap. We can establish a rule that says nothing gets added to the roadmap unless we know the problem to be solved. Research will increase our confidence for the prioritization formula.
By integrating the experience vision into the roadmap, we create a virtuous cycle, and by pushing the experience vision into the roadmap, we now have a better capability of estimating value and effort by upping our research game. And UX is now an essential part of the proactive strategy instead of just reacting to whatever is at the top of the roadmap, driving change in the organisation with the user at the center of everything.
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.