Intro
Roadmapping is one of the most critical activities a product management leader must undertake.
A roadmap is not a building blueprint; it does not list exactly what must be done. It is more like a map for early explorers, used to give direction, with route adjustments as new lands and currents are discovered.
Over the years, I have had the pleasure of working with brilliant people who taught me a lot about how this should be done, most notably Yoav Stahl and Kevin Savina. I’ve refined their methods to better fit the agile reality.
In this article, I’ll outline my system in the hope that you find it useful and adapt it to your own context.
Preparation
You can’t just “jump into” a roadmap. It starts with preparation — gathering information and building context.
Connect to strategy
Make sure you understand the company’s mission and high-level strategy. Everything in your roadmap should connect clearly to it.
Understand your market
Identify your real market, even if it takes time. Learn its size, growth, key players, and, most importantly, who your customers are and what problems they face.
Absorb information
Read articles, watch videos, review analyst reports, explore forums, and even take a short course. Be a sponge.
Listen before you talk
Speak with people, inside and outside the company — but hold back opinions. Ask questions, listen carefully, and look for patterns rather than anecdotes.
Know your product
Understand your own product deeply, including adjacent ones in your company. You can’t propose change if you don’t fully understand what exists.
Document evidence and assumptions
Keep notes on insights, questions, and uncertainties. This becomes your reference when prioritizing or explaining choices later.
Honing In
Once you’ve absorbed enough, start defining direction.
Define clear goals
Limit yourself to no more than four product goals. Each goal should have a simple statement in the format:
[action] → [value to customers]
Go deeper
For each goal, describe what success looks like, key outcomes, and measurable targets required to achieve it.
Socialize and validate
Create a simple presentation and meet with major stakeholder groups — management, engineering, marketing, sales, product marketing, customer success, solution architects, etc.
The purpose is not to impress with slides but to get feedback:
- Is it clear?
- Does it align with company and customer needs?
- Does it connect to their goals?
- What might be missing?
You’ll likely need follow-ups or 1:1 conversations to clarify points and reach alignment.
Building the Roadmap
Once alignment is achieved, start building.
Translate goals to themes and initiatives
Goals → Themes
Targets → Initiatives
Each initiative should represent a problem to solve or outcome to achieve, not a feature list.
Work with engineering
Collaborate closely with engineering to break initiatives into large, logical pieces. Look for ways to deliver value iteratively. Early partnership prevents over-commitment and ensures feasibility.
Prioritize systematically
Use your preferred framework, RICE, WSJF, or a similar scoring model — to get an objective base.
Then, invite stakeholders to contribute by rating each initiative from 1–5 for perceived impact or importance.
Combine all results into a weighted score:
- Product and engineering: higher weight
- Customer-facing functions: moderate weight
- Others: lower weight
This keeps collaboration high without turning prioritization into a popularity contest.
Create the roadmap view
Build a simple, readable formatm, three columns and multiple swimlanes:
| Now (1–3 months) | Next (4–6 months) | Later (6+ months) |
|---|---|---|
| Current work or what’s close to release | Likely upcoming items being validated or designed | Future opportunities or bets that may change with new information |
Swimlanes represent your themes or goals.
Some initiatives will span multiple columns if delivery continues across phases.
Tip: Epics should stay in Now or Next. Never place them under Later — that space belongs to problem areas, not planned builds.
The further out you go, the more uncertainty — “there be dragons.”
What’s Next
Now that your roadmap exists, make it live through constant, transparent communication.
Internal sharing
Present the roadmap regularly to all relevant groups. Reference it at the start of planning, progress, or review meetings so everyone stays aligned.
Everyone in your organization should know the roadmap well enough to explain it simply.
External validation
Share a version (sanitized if needed) with customers, partners, or consultants to get feedback. Focus on direction and outcomes, not dates.
Use what you hear to adjust — not reactively, but deliberately.
Keep it alive
Your roadmap is a living document. It must evolve as you learn, but not so often that it creates instability.
Revisit and refresh it quarterly, or when there’s a major change in company direction or market signal.
Balance consistency with adaptability
Avoid changing the roadmap mechanically or too frequently. Let evidence and clear reasoning drive updates, not noise or opinion.
Closing Thought
A roadmap communicates intent and alignment under uncertainty.
It’s not about being “right” but about helping your teams and stakeholders move in the same direction — together.