Simplifying What Kills Product Teams: Roadmap
One template to move away from nonsense roadmaps
A few things can limit product teams more than a poorly defined roadmap.
Do you remember a moment when:
You had to cut corners to meet deadlines
Painfully negotiate scope with stakeholders
Struggle to decide what to do next because everything is mandatory
Didn’t know where to start, as you had a mountain of requirements in front of you
If the above rings a bell, I welcome you to the Feature Factory Club. You gain your subscription when delivering features is the ultimate success metric.
I’m sorry to welcome you here because this club isn’t fun. On the contrary, everyone is stressed and frustrated. But we all have one thing in common. We want to find a way out.
A prescriptive roadmap is a bug, not a feature. And it needs an immediate hotfix.
Let me work with you on it.
What’s a Product Roadmap?
First, we need to have a shared understanding of a roadmap. You will find several definitions, and each company may interpret them differently. One of the key aspects is understanding where the roadmap positions in the big picture of a product management equation:
Why → Product Vision
What → Product Strategy
Who → Target Audience
When → Product Roadmap
How → Discovery & Delivery
The roadmap is the glue between vision, strategy, audience, and getting things done. Without a roadmap, teams struggle with prioritization and get lost. Yet, a roadmap isn’t a plan telling precisely who does what by when.
Common traps are:
Feature roadmaps: Teams have to deliver outputs instead of aiming for outcomes.
Strict deadlines: Meeting deadlines is what matters most.
Dependencies: Teams cannot get their work done because they are tightly coupled with other teams.
What Does an Empowering Roadmap Lead To?
When your product roadmap is done right, teams know essential milestones to achieve and understand what they can ignore. With that, they can focus and create outstanding results.
I’ve been part of dozens of teams, and I cannot tell you a solution that works for everyone. But I can tell you what maximizes the chance of thriving.
Vision → Top management defines where to land
Strategy → Top management and product leaders clarify the product strategy
Target Audience → Based on the evidence, product management sharpens the audience and defines who to serve and who not to
Roadmap → Leaders set goals, and teams define how to reach targets
When the team is empowered to achieve goals, they have higher success chances
A prescriptive roadmap describes outputs, while an empowering roadmap describes outcomes. Let me give you some examples:
Output: Show product recommendations during check-out
Outcome: Increase basked size by 10%
Output: Implement a chatbot to address delivery issues
Outcome: Reduce customer service requests related to delivery by 50%
Output forces execution, while outcome opens up to explore different solutions.
Setting an Empowering Roadmap
Have you ever tried googling “product roadmap?” The results can be overwhelming. You’ll find too many options, and the question is, what should you use?
Let me tell you one thing.
Some templates will give you more trouble than you need. Finding the best format is hard because the only way is to try out different options.
After experiencing different roadmaps, I came up with one that worked the best for me. Let me share it with you.
This format is simple, and it works like the following:
Now → What matters most right now. This should provide the focus for one to three months. The key is never to commit to individual initiatives but to the lane called “Now.”
Next → This column represents aspects you know are relevant, and potentially you will work on them right after you finish the critical ones. The content evolves based on what you learn.
Later → Digital products are dynamic. You cannot predict more than six months. Whatever enters here means you’re considering working on it only after you finish the other parts. You lack evidence of these topics and aren’t convincing enough to go to the previous columns.
Trash → This is the most critical part. You need to agree on what you don’t do, which goes to the trash. Sometimes, I say that great product managers increase the size of the trash bin instead of the product backlog.
Roadmap Example
Let’s move from abstraction to something concrete. The following represents an example of a roadmap using this template.
This is a real roadmap for one of the e-commerce companies for which I worked. Back then, we struggled to balance customer lifetime value and acquisition cost. We knew we had to help customers find products they wanted to have a better balance between lifetime value and acquire costs, the LTV: CAC ratio.
Many feature options came to me. Everyone had a solution. Some examples:
Redesign the product detail page
Increase the newsletter frequency
Present products according to the persona
Price differentiation per location
What’s the issue with the above solutions?
The truth is that they present no issues, and all solutions make a lot of sense. The real trap is that they are already solutions and not the outcome. This would force the team to implement solutions instead of solving problems. After a lot of discussions, we could commit to the following:
Now → Increasing basket size has become our ultimate goal. We came up with two targets: reduce no-result searches and increase recommended products added to the cart.
Next → Right after this, we wanted to return to growth while keeping our customers satisfied. We had some ideas, so we clarified them but agreed not to tackle them during the next three months.
Later → Growth would become our focus, and we wanted to continue exploring it later. Some aspects came to our mind, like new markets and creating new revenue streams, but we all agreed that would be a talk for another coffee.
Trash → During our lengthy exchanges, we agreed on dropping some of our beloved topics to ensure we would not get distracted. We concluded that promoted products and free vouchers weren’t part of our identity, so we trashed them. Combined with that, we agreed that search was our core, and we could not outsource it, which made part of the trash bin, too.
Is this roadmap oversimplified? Yes.
Does it get the job of providing focus to the team? Yes.
Do you need a complex roadmap? No.
Often, your real job is to simplify what everyone else is complicating.
Let me make your life easier. You can download my template from here. Alternatively, you find my Miro template :)
Wrap Up
Roadmaps aren’t bad by design, and companies doing bad roadmaps aren’t intentionally evil. Sadly, many teams haven’t experienced a different way of working. What about taking that as an opportunity?
Executives welcome new ideas with the true intention of helping deliver results faster. The secret is to make the change as small as possible and prove with results.
One final hint to you. With outcome roadmaps, your accountability grows. You must reach results instead of simply putting features live. It’s more stressful work, yet more fulfilling. You may have some sleepless nights when you face the unknown, but you’ll be proud of your achievements in the midterm.
Let’s rock the product world together!
Here are three ways I can help you even more:
Upgrade your subscription to Premium and get one deeply thought newsletter per month (20+ minutes reading) plus access to 300+ episodes
Join my cohort, Product Discovery Done Right
Have a lovely day,
David
Good one !!
Interesting. But when does the outcomes translated to features?
Let’s say for the basket size increase, there are indeed 4-5 features that could help. In the end, you still need to estimate the effort of each, prioritize among them, and decide which to take and when to move to the next outcome.
I have only experienced ‘feature factory’ roadmaps (which I definitely don’t like), but I find it hard to imagine how the alternative works in practice. In regular roadmaps the features are also connected to some KPI you want to improve.
It seems that the difference is you put the KPI in the roadmap and the team is responsible for deciding which feature to develop in that time. That a good way to make developers involved, but in the end you’ll still have a work plan, no?