My top 5 resources on roadmapping
Two videos and three articles to expand your thinking on product roadmaps
Wow, ‘Escaping the roadmap trap‘ has been read 20.000+ times and 250 new readers signed up. Thanks for sharing it and a warm welcome to the new members!
Since the topic sparked significant interest, here’s a followup article with two videos and three articles that shaped my thoughts on product roadmaps. I added some key insights from each piece for you. Feel encouraged to share your favourite resources with us in the comments.
Happy watching and reading 👇
1. The art of building a roadmap (Atlassian)
Cliff notes
Roadmap = set of decisions. Good decisions are made by first knowing your inputs.
Understand your roadmap inputs
Company goals
Product vision
Business model
Customer feedback
3 types of roadmaps at Atlassian
Goal-driven: When you want to optimise a feature or funnel
Persona-driven: When you want to improve customer satisfaction
Vision-driven: To launch a new product or ship an epic on an existing product
Is there such a thing as an agile roadmap? Yes, when you…
Focus on problems: Stay flexible on the solution. Be more agile in how you can respond to change and move around.
Group problems into themes: Abstract proposed solution to tackle a broader problem set.
Plan for “now”, “next” & “someday”: Don’t bother speccing out the someday list.
Questions for you
Do I understand my roadmap inputs?
Are the roadmap inputs balanced? Which inputs have we not factored in?
Does your roadmap style reflect your current goals?
2. Des Traynor on Product Roadmaps (Intercom)
Cliff notes
A company’s true goals are written on its roadmap.
5 key roadmap ingredients at Intercom
New Ideas
Customers won’t be asking for them
The data won’t support them
They’re likely to fail
They’re nearly impossible to justify
Iterate on Product
Every new feature brings its own roadmap
Customer Problems
Customers have expertise in their problem
But they speak only in terms of pre-conceived solutions
Abstract the use case to find the root problem and find commonalities
Improve quality
Consider the balance between quality, importance, satisfaction and frequency
Quality: how well executed is it
Importance: how important in the workflow is it
Satisfaction: how happy are users with it currently
Frequency: how often do they use it
Features to help scale
Your roadmap formula changes over time
First you make it
Then you make it good
Then iterate & solve problems
What kind of company are you (at the moment)?
Questions for you
New Ideas: What ideas did you rationalise to death?
Iterate on Product: What features did you ship and never revisit?
Customer Problems: What features did you ship without really considering the problem?
Improving quality: What features are under-used or under-adopted in your product? You can increase usage frequency or increase adoption.
3. Baskets of options > Option on a basket
The article ”Decisions, Decisions or Why Baskets of Options Dominate” by Kent Beck illustrates why a roadmap full of options is better than an option on a roadmap by explaining the mathematics behind optionality. If you want to convince stakeholders to explore a different roadmapping approach to a feature release plan for the entire year, this might hit home.
The article deserves a full read, but I’ll share Kent Beck’s conclusion here so you know what to expect:
I want your intuition to be attuned to options on baskets so you spot them and address them as soon as they appear, regardless of their superficial attraction. I want you to be able to transform an option on a basket into a basket of options. I want you to identify the problematic linkage between the items in an option on a basket. I hope this essay has started that process for you. Let me know how it goes.
4. Options, Not Roadmaps (Basecamp)
Ryan Singer explains Basecamp’s approach to roadmaps in the introduction:
Since Shape Up came out, many people asked some version of this question:
I understand you make bets six weeks at a time. But how do you plan in the longer term? Don’t you have some kind of a roadmap?
The short answer is: no. We don’t have roadmaps. We think about what to do at the timescale larger than single bets, but we do it in a different way.
Why not a roadmap?
No matter how you try to hedge it, a roadmap communicates a plan—a series of commitments—to other people.
It’s an interesting read that reflects an approach that a few commentators on the previous issue were also in favour of: No roadmaps at all. Only commit to the next opportunity. The gist of it is that a roadmap communicates a series of commitments, which Basecamp wants to avoid because of uncertainty, expectations and guilt. Ryan elaborates on each of these problems in the article and proceeds to explain how they maintain a portfolio of options. This approach is embedded in the larger context of how Basecamp does product development, so it’s worth reading the full book on ShapeUp.
While this works for Basecamp, it depends what type of company you’re working in. For a vision-driven product, a VC-funded company or a company with a set of clearly defined milestones, this likely wouldn’t work. To combine the best of both worlds, I believe there are other ways of introducing optionality beyond the current development cycle in the roadmap, some of which were discussed in the last issue.
5. The alternative to roadmaps (SVPG)
In The alternative to roadmaps, Marty Cagan proposes replacing the roadmap with business objectives, using OKRs as an example framework. He advocates providing the necessary context to the team through the following two components:
The Product Vision: this describes the holistic view of what the organization as a whole is trying to accomplish.
The Business Objectives: this describes the specific, prioritized business objectives for each product team.
You’ll recognise these two elements in Atlassian’s four roadmap inputs. In ‘Escaping the roadmap trap‘, I discussed some of the challenges of using OKRs-as-a-roadmap and a few ideas on how to transition from feature-based to OKRs-based roadmaps. I also share a rough concept for how to structure such a roadmap.
Reader comments on ‘Escaping the roadmap trap’
Here are some of my favourite thoughts from you on the last issue:
“There isn't a one-size-fits-all solution. The article is super comprehensive” - Bruno Pedro
“Great, thanks for sharing your thoughts on this topic. The way a roadmap is structured really says a lot about the product culture and agility of a company.” - Lucas Wagner
“It's very easy to go for what seems to be the easiest option when building out a roadmap -- a series of features spaced out over time. After all, everyone can understand this, and it gives all the appearances of progress and certainty. […] But I have never seen a traditional roadmap like this last for more than a few weeks -- maybe months if you're lucky. New information becomes available, new ideas emerge, teams evolve, and unforeseen opportunities open up. So why don't we build this uncertainty into our roadmapping, and turn that roadmap from a lovely plan which we can print out and stick on the wall (and then tear down again in a week) into a useful tool?” - Barry van Oudtshoorn
“A lot of resources on product management are mixing what some commentators are pointing here: roadmap can mean: (1) Communication tool to tell others in the organization (or even outside) what you're planning to build. (2) A framework for your product and/or engineering team that helps you prioritize the work. This article obviously focuses on the latter. One of the most common mistakes however is that PMs try to use a single deliverable for both.” - rokkk
That’s all I have for you today! Here’s what you can expect from the upcoming issues:
10 principles of a great product roadmap (I might end up with 9 or 11, so don’t quote me on it ;-)
Stop looking at the customer through your product
Why Figma is winning: Strategy lessons from the evolution of design tools