Following my webinar Key Ingredients for Successful Product Roadmaps and my blog post Do You Have a Good Outcome-Oriented Roadmap? I’ve received numerous questions on all things Roadmaps. As a result, I’ve compiled the five that have the broadest relevance and are the most pertinent when implementing Roadmaps.
Question 1: What are good metrics to measure on Roadmaps?
The only right answer here is to say, it depends. Every company and every project within a company is different. It is with this mindset that you should view all metrics. One thing is given though, each and every time you need to define what to measure, be sure to ask the following questions.
-
What am I trying to learn? What quantitative/qualitative metric will give me the signals that tie to what I want to learn?
-
Is the metric an actionable metric or a vanity metric? Actionable metrics give me a signal that tells me if things are going well or not. For example vanity metrics are metrics that usually only go up and to the right. For example, raw page visits.
-
What’s the metric that will help me learn if I’ve made the impact I wanted to with my customers/users?
-
Can I actually measure the metric I come up with?
You don’t need to have answers to all of these questions, but it’s is a great exercise to help you get at one or more honest measurements. In addition, here are a few articles that are worth checking out:
Metrics, Metrics On The Wall, Who’s The Vainest Of Them All?
On OKRs
Hate OKRs? Avoid these 7 mistakes
Why OKRs Do Not Help Us Measure What Matters
On innovation accounting
Question 2: What does it mean to be predictable in an agile environment?
First, it’s important to dig into the definition of predictability. In a waterfall world predictability implies deadlines and features delivered. In the agile world I would define predictability as continuously adding value to customers and being able to iterate on the product. To that end, the keys to having predictability are having the ability to CI/CD, a stable velocity and discipline around continuous discovery to drive iterative development.
Agile (velocity) injects a dose of honesty into the predictability discussion in that it predicts pace based on past trends versus. biased estimates. From the perspective of meeting software build goals, team velocity is a signal of the pace of value the team is providing and how healthy the product or team is. For a deeper dive into this topic I recommend you check out this blog post from Pivotal Tracker
Question 3: How would you advise dealing with and prioritizing technical debt?
This is a big question. My short answer is that I believe a roadmap should reflect all outcomes you are expecting the team to work on. This includes outcomes that help the team move faster and be more effective and tech debt is an integral part of that. On past teams we prioritized tech debt with product outcomes and gave space for both.
For a much fuller answer to this question I recommend watching Setting Priorities: How to Balance Planned vs. Unplanned Work.
Question 4: How far into the future should a roadmap go?
Any product team should always be considering two tracks of work. The first track is the known knowns. This track is the validated set of features that are ready for build. The second track of work are the known unknowns—these are opportunities that require further analysis and customer validation in order for the team to gain confidence that it’s worth building. I believe that a roadmap should provide insight into both tracks.
The other dimension I consider is the feedback loops and how short or long they are. The team I work with has a 3-month release cycle, and our teams tend to articulate their roadmap for this release, next release, and the future. The further out you plan the more your goals/roadmap items should be learning goals over feature/solution specifics.
The Silicon Valley Product Group has a nice piece on dual-track agile.
Question 5: How should you create a first roadmap for a new project or young company?
When I think about the progression of intent regarding what to build to drive enduring and sustainable value I think about the cascading intent from vision to backlog.
Your company must have a clearly defined Vision and Strategy that everyone is aligned on. These need to be in place before you tackle the next abstraction, timeline and tactics, aka the Roadmap. I make this point, because there are times when organizations either don’t have this in place or lose sight of their vision and mission. In those scenarios, what happens is that the work is focused on user input. In my opinion, the impactof having Roadmaps being driven by customer requests is that teams fall into patterns of building whatever is being demanded of them and you lose the strong compelling story of what your product is meant to do. This can lead to output focused on gratifying/appeasing customers without deeper thinking about strategy for the business to be successful in the market.
Ideas like cascading intent, cascading OKRs are intended to help all levels in the organization articulate their goals so that the highest order goals can be used as north stars for lower levels of the organization to set their objectives. There are many great talks on this but Des Trayner nails it on how to scale strategically.
Learn More
-
White Paper: A Roadmap to Agility
-
Video: Escape the Feature Factory with Outcome-Oriented Roadmaps
