My philosophy
A roadmap is not a backlog. It's a strategic communication tool that answers one question: what bets are we making and why? I build roadmaps around outcomes, not features - each item ties back to a measurable business or user objective.
How I build a roadmap
I start with a Now / Next / Later framework to give teams the right level of clarity without locking in false precision. Each horizon is driven by: company OKRs at the top, user pain points from research and support data in the middle, and technical debt or platform needs at the bottom. I score items using a simplified RICE model (Reach × Impact / Effort) and adjust for strategic weight - some bets matter because of their strategic position, not their raw score.
Stakeholder alignment
Before presenting a roadmap, I run individual alignment sessions with Engineering leads, Sales, and senior stakeholders. Surprises in a roadmap review kill trust. I use a one-pager format - one slide per quarter, each item with a 'why now' rationale - so reviewers engage with strategy, not just a list.
Real example
At Datachain, I defined a 12-month and 24-month roadmap for the IBC bridge project. The 12-month plan had hard commitments tied to integration milestones with banking partners. The 24-month horizon was directional - it communicated strategic intent to investors and internal leadership without creating false promises to engineering teams.
Tools I use
Notion for lightweight roadmaps, Jira for sprint-level execution, Confluence for documentation. For exec presentations I use a visual timeline in Figma or Google Slides. I avoid tools that add process overhead without clarity gain.