7 fails of roadmap-making
7 fails of roadmap-making
The most common potholes to avoid when creating long term plans
This article is brought to you by Paragon -
Making your users go to Zapier because you don’t have the Eng resources to ship native integrations? Then you need to read this Zapier vs. Native Integrations article to learn about the tradeoffs.
Roadmaps often feel like a necessary evil. They’re an essential bridge between the overarching company strategy and the practical realities of your quarterly OKRs. But unfortunately, many product leaders are doing them wrong to the point where they not only miss their purpose but also frustrate everyone around them.
Although there are plenty of guides for approaching road mapping, sometimes it’s helpful to focus on the warnings.
So here are the seven major issues I see teams making when it comes to roadmaps:
1. Too Much Detail on Effort Estimations
For most product teams, effort estimations are a core part of the roadmapping process. But they’re mostly wrong. This process gives us a false sense of certainty about how long things will take, but the reality is that detailed estimations on any project that goes longer than a few months are a waste of time.
Often mentioned in this context is Hofstadters Law:
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
This “Law” is so ridiculously on the point that I assume as a default that most project estimations from my teams are completely unreliable for my strategic planning, no matter how much buffer my colleagues have attributed and how carefully they did it.
This only becomes an actual problem when something cannot take longer than a specific amount of time because of hard factors, for instance, money runs out.
It’s still good to have a general idea of how long things could take but it’s usually pointless to go into detailed estimates for longer term projects.
2. Too Much Focus on Today
Another point of danger is when roadmaps are too zoomed in on your current operations. That’s what OKR & quarterly planning are for. Your roadmap should give a broader picture to understand where things are going and how everything comes together in the future.
Yes, you need to be able to anchor this process in the current situation and required short-term actions, but the goal is to connect the dots between that layer and the top-level vision.
If you focus too much on “today,” you rob yourself of important optionality further down the road. Things are changing constantly, and we are building things for Markets in the future, not today.
Think about it from an investor perspective: they invest in future performance, not today, and so should you.
For instance, at the beginning of COVID-19, a lot of companies started to shift their long-term roadmaps towards the COVID-19 market. This assumes that the markets stay the same for many years to come with COVID-19 around. The moment things turned back to “normal” all those developments stopped paying dividends.
3. Too Much Focus on the Competition
Very much related to the last point, I consistently see teams getting into trouble by structuring their roadmap as a reaction to their competitive landscape. While you should be aware of what your competitors are doing and how this could affect the perception of your product in the market, focus on your own goals and strategic plan. Your roadmap should be active, not passive or reactive.
The problem with copying the competition is that you can’t outperform them this way. Product leaders also tend to overestimate the skills of their competitors:
“Oh they just changed their pricing! That means they validated it for months and surely had a good reason, we should do the same!”
It’s the blind leading the blind. Your competition sucks just as much as you do.
While I think competitive understanding is especially important when you get into a new job to understand whats what, with time I don’t pay attention to competition at large. You should understand the market better overall than what’s publicly easily accessible after some time (like your competitor’s marketing material).
4. Too Much Focus on Outputs
I see this all the time: Roadmaps stuffed with features to launch and deadlines to hit. It’s not a problem to identify key initiatives that can drive the results that the organization needs, but the point is not to just launch a list of features.
My general approach, here, is a spectrum:
Really Short Term: Outputs where we can’t find simple outcomes. For instance, for maybe the next quarter, it may be okay to focus on specific outputs because we have some degree of certainty within that window.
For example: “Enable CSV export in our product”
Medium Term: User Outcomes. Beyond the immediate future, certainty dramatically decreases. Rather than trying to predict and prescribe what the company will do, provide guidance on the results that initiatives will drive.
For example: “Enable collaboration and easier sharing”
Longer Term: Product or Business Outcomes. As you get further from the present, the more reality will vary from your expectations. After more than a couple of quarters, you should really only be guiding in terms of the high-level objectives for the product or business.
For example: “Focus on increasing retention to drive up overall LTV in our US market.”
This approach tends to work for me well for company sizes anywhere between 10 and 100 million in ARR. For much smaller businesses we adopt a tighter time horizon with the same principles.
5. Too public
This can also dictate nicely how you communicate your roadmap. I would never communicate any roadmap in the first place, but I recognize that in some sales-led organizations, you want to find a good compromise to tease enterprise contracts. (Even though I’m skeptical this does anything at all, even though Gary, the salesguy, keeps telling you it’s necessary)
If you decide to make parts of it “public,” then do so only in the very short term and only for select things. Customers do care about features as a language and understand them so that lines up quite nicely. Resist the urge to go beyond a few months at any cost, though.
But I wouldn’t even do that. If we really believe in an organization that only ships what’s meaningful, we cannot define the results of anything we do before having tested it:
If you promise to ship something to customers, you can’t choose not to ship it anymore, therefore taking away the possibility of saying, “After looking at the data, maybe this wasn’t a good idea.”
A good nugget to prevent Gary the sales guy, from communicating a roadmap publicly if you decide no one should is to bake it into his compensation plan (source: Rich Mironov):
The first time Gary promises things to the customers, the compensation bonus for that customer is gone.
The 2nd time Gary is fired.
That works. Take that, Gary.
6. Not Actionable Enough
As my pal
likes to say: “Anything that’s not actionable is essentially just an alibi.”Because a roadmap is an artifact of strategy, some teams separate them almost completely from the practical realities of putting things into place. But if you haven’t thought through the implications of what this roadmap actually means for your teams on the ground, you’re in trouble. At best, people will ignore it.
At worst, different groups will move in different (and conflicting) directions.
Again, the closer to today and on the operational level something is, the more actionable it has to be.
7. Not Properly Communicated
Pay attention, here. Even if you get everything else right, if you mess this one up… it’s all wasted effort: If you want your roadmap to be useful, you have to make sure it’s communicated effectively to the relevant stakeholders until they are sick of hearing it.
As I like to say: The direction you go is only as good as the font you use on the roadsign that guides you.
You could have the world’s best roadmap in your head, but if you haven’t documented it in a simple and shareable format, it does you no good. If half your organization thinks it means one thing and the other half thinks it means something else, then your roadmap may do more harm than good.
Assume misalignment as a standard, and keep talking about it in a simple way.
How to communicate as a leader:
Conclusion: The Road Forward
Okay, got it? So here are the 7 mistakes to avoid:
Too much detail on effort estimations
Too much focus on today
Too much focus on the competition
Too much focus on outputs
Too public
Not actionable enough
Not properly communicated
Easy, right?
Okay, I know that all of that may feel a bit intimidating. But I’ve got good news: When it comes to roadmaps, the process itself is often more valuable than the end result.
Just going through the ordeal of gathering the relevant stakeholders will reveal misalignment and help everyone to sync up. For instance, if you’re talking through timelines and someone says ‘That will take a year’ and someone else says ‘3 months’… well, you may not know who’s right, but clearly there are some conflicting expectations about how difficult this is to build.
This is a great opportunity to identify the source of the misalignment and get on the same page. Every time you disagree and find a compromise, you learn something. This whole process will make your team and your whole organization better at working together.
Bon voyage and safe travels!
Thanks for including me pal! 😉
Great piece!