Engineering Roadmaps
Outcome-Based vs Feature-Based Roadmaps
A feature-based roadmap says: "Q1: Build recommendation engine. Q2: Add social sharing. Q3: Launch mobile app." An outcome-based roadmap says: "Q1: Increase average session duration by 30%. Q2: Grow organic traffic by 50%. Q3: Reach 100K monthly active users on mobile."
The outcome-based version works better for three reasons. First, it gives teams the freedom to find the best solution instead of dictating the implementation up front. Second, it ties engineering work to business metrics that executives actually track. Third, it survives pivots. If the recommendation engine turns out to be the wrong approach, the outcome (session duration) still points the team toward alternatives.
The Rolling Window Model
Detail should decrease the further out you look. For the current quarter, list specific initiatives with owners, estimated effort, and dependencies. For the next quarter, define themes and tentative initiatives that might get reprioritized. For 6-12 months out, capture only strategic directions that align with the technical vision. This keeps you from locking in specific features a year ahead when you have the least information.
Handling Dependencies
Cross-team dependencies are where roadmaps fall apart. For each one, document: which team you depend on, what you need from them, by when, and what happens if they're late. Hold a monthly dependency review where all team leads surface blockers. If a critical dependency can't be resolved, escalate right away. Don't sit on it until the quarterly review.
Buffer Management
Reserve 20-30% of capacity for three buckets: unplanned work (production incidents, urgent bug fixes), discovery and iteration (the first design is rarely right), and quality (testing, documentation, operational readiness). This buffer isn't slack. It's realism. Teams that plan at 100% capacity consistently deliver 60-70% of their roadmap and burn themselves out doing it.
The Review Cadence
Weekly: Team-level standup on roadmap item progress. 15 minutes. Flag blockers. Monthly: Cross-team roadmap review. 1 hour. Adjust timelines and reprioritize based on new information. Quarterly: Full roadmap refresh with product and executive stakeholders. 2 hours. Celebrate wins, acknowledge what was missed, and set priorities for the next quarter.
Key Points
- •Outcome-based roadmaps outlast feature-based ones. Define what success looks like, not just what to build
- •Build in 20-30% buffer for unplanned work. If your roadmap assumes 100% utilization, it'll fall apart by week 3
- •Map dependencies explicitly and resolve them before committing to timelines. Hidden dependencies are the number one roadmap killer
- •Use a rolling 3-month detail window with 6-12 month directional themes. Precision decreases with distance
- •Review and adjust the roadmap monthly. A roadmap that never changes is a fantasy document
Common Mistakes
- ✗Treating the roadmap as a promise instead of a plan. Stakeholders need to understand that timelines are estimates, not commitments
- ✗Including only feature work. Platform improvements, tech debt, and developer experience initiatives deserve roadmap space too
- ✗Not involving the team in estimation. Timelines handed down from above without engineer input are fiction
- ✗Overloading the roadmap to show ambition. A roadmap with 40 items communicates nothing about what actually matters