A framework for re-purposing your [broken] product roadmap
Most product roadmaps suck. 💩
Throughout my PM career, I hated them with a passion. They're full of broken promises and disappointment.
And I'm relieved to say that I was not alone.
A poll I ran (546 responses) shows that less than 8% of product teams feel like they are getting it right.
But why is that? And what can we do to fix it?
Before we confront this abomination 👺, we need to get their origin story.
👋🏼 Hi, it's Raj. Welcome to Product Playbooks. Every week, I dive into reader questions about the challenges of working in product teams.
Send me your questions, and I'll provide no-fluff advice in an actionable "1 hour playbook" format. Let's jump into this week's play...
Q. I’ve been tasked with re-building our product roadmap. Can you please help?
The Roadmap Origin Story
Product roadmaps were invented by Motorola [a.k.a Dr Jerkyl] in the 1980’s.
They were meant to "inform" stakeholders of major upgrades so they could plan out their purchases many months in advance.
And the traditional “features on a timeline” approach was a concise format that became generally accepted.
It worked well back then [or so I've been told] because product releases were done infrequently.
The "Modern" Product Roadmap
Fast forward to today, this approach does not work for most industries.
And that's because modern product teams face one constant: Uncertainty.
The rapid pace of technological advancement forces teams to continuously consider “What should I build? How should I build it? & How long will it take?”.
To succeed, product teams need flexibility to adapt.
The development function recognized this problem and shifted from waterfall to Agile. As a result, teams today run short sprints, release more frequently, and course correct often.
But the planning function seems to have missed the memo. 📝
They’re still stuck in the old school way of putting “features on a timeline”.
Why is this? Maybe because longer term planning is done by executives.
And they are more used to giving memos than getting them.
But jokes aside, the reality is that old-school roadmaps give product teams no flexibility and set them up for failure.
Is my product roadmap broken?
Here are some signs that your product roadmap needs to be rethought.
-
You struggle to keep promises made to stakeholders [dates slipped again]
-
You stick to plans that no longer make sense [sorry, features are locked in]
-
Stakeholders have lost trust in you [history of poor planning]
-
The product roadmap is used mostly by “management” types [builders do not rely on it]
What can I do?
I put together this “1-hour” framework to help PMs audit their current roadmap.
The output of this play should [hopefully] be a more useful roadmap template that can then be socialized within your company.
Playbook Instructions:
⏰ Run time: < 1 hour
🧑🏼 People: PM only [can workshop with others later]
✂️ Material: Google docs + current roadmap
🔁 Repeat: None
Step 1 Choose your format
To get started, you may want to reconsider the format currently used.
Action: Select the best format for your roadmap based on 1) the tool you prefer to work with and 2) what is used in your company
Step 2: Check your roadmap components
Action: Check if your current roadmap is missing any of these components.
A) The primary components
These are the "must have" bits in your roadmap. A good product roadmap will contain:
i) Product Vision: A short, inspiring statement describing how your customer will benefit from your product.
❌ Is the highest paid persons opinion
✅ Is clear, inspiring & customer-driven
ii) Business Objectives: This is the "why" of your roadmap. It'll help you measure your progress:
❌ Is ambiguous and hard to track
✅ Is exciting and rallies stakeholders
iii) Timeframe: These should be broad timeframes [don't overcommit]
❌ Is Nov 18, 2024
✅ Is 3rd quarter 2024, or "now next later" format
iv) Themes: Themes focus on outcomes, and not features
❌ Is for importing contacts from iPhone
✅ Is for providing easier onboarding
v) Disclaimer: The disclaimer is a reminder to the reader that "things can change without notice".
❌ Is in "tiny" legal language, hidden in the bottom
✅ Is in a visible location, in simple language