Roadmapping Guide

*End-to-end guide for technical PMs: from discovery through delivery, getting stakeholder buy-in, maintaining your roadmap, and avoiding common pitfalls.*

1. The Purpose of a Roadmap

A roadmap is a communication tool, not a project plan. It answers three questions:

1. Where are we going? (vision and goals)

2. How will we get there? (prioritized initiatives)

3. What are we NOT doing? (explicit trade-offs)

A roadmap is NOT:

• A list of features with deadlines (that's a release plan)
• A Gantt chart (that's a project schedule)
• A contract with stakeholders (that's a commitment; roadmaps are directional)

2. Choosing Your Roadmap Format

Can You Use Multiple Formats?

Yes. Many teams maintain:

• Annual roadmap for executive communication (strategic level)
• Quarterly roadmap for team execution (tactical level)
• Now/Next/Later for product discovery and stakeholder conversations

The key is that they're consistent — the quarterly roadmap should be a zoom-in on the current quarter of the annual roadmap.

3. Building Your First Roadmap

Step 1: Gather Inputs (1-2 weeks)

Step 2: Prioritize (1 week)

1. List all candidate initiatives (features, improvements, tech debt, experiments)

2. Score using RICE, ICE, or MoSCoW (see the prioritization guide)

3. Stack rank by score

4. Check against team capacity (see the capacity planning template)

5. Draw the line: what's above the line gets resourced; what's below waits

Step 3: Structure (2-3 days)

1. Group initiatives into themes (e.g., "Onboarding", "Enterprise", "Reliability")

2. Assign to time horizons (quarters, or Now/Next/Later)

3. Identify dependencies between initiatives and across teams

4. Add milestones and success metrics

Step 4: Validate (1 week)

Share the draft roadmap with:

1. Engineering lead — "Is this feasible? Did I miss any dependencies?"

2. Design lead — "Are the user experience implications clear?"

3. Key stakeholder — "Does this align with your priorities?"

4. Your manager — "Does this connect to company strategy?"

Incorporate feedback. Iterate. Get explicit approval.

4. Maintaining Your Roadmap

A roadmap that's written once and never updated is worse than no roadmap at all — it creates false expectations.

Review Cadence

When to Change the Roadmap

5. Getting Stakeholder Buy-In

The Pre-Sell

Before your formal roadmap review, have informal 1:1 conversations with key stakeholders. Ask: "I'm thinking about X for next quarter. What's your reaction?" This surfaces objections early and lets you address them before the group review.

The Roadmap Review Meeting

Format:

1. Remind the group of the company strategy and product vision (2 min)

2. Present the roadmap themes and prioritized initiatives (10 min)

3. Explain what's NOT on the roadmap and why (5 min) — this is where buy-in happens

4. Open for questions and discussion (15 min)

5. Close with explicit ask for approval (2 min)

Ground rules:

• New ideas go into the backlog for the next prioritization cycle, not onto the current roadmap
• Scope changes require showing the trade-off ("we can add X if we remove Y")
• The roadmap is directional, not a contract

Handling Pushback

6. Common Roadmapping Mistakes

7. Roadmap Delivery Checklist

Before sharing your roadmap with anyone, verify:

• [ ] Every initiative connects to a company goal or product objective
• [ ] Prioritization is backed by a framework (RICE/ICE/MoSCoW), not just gut feel
• [ ] Capacity plan shows the math works (initiatives fit within available resources)
• [ ] Dependencies are identified and have owners
• [ ] Success metrics are defined for every initiative (how you'll know it worked)
• [ ] Non-goals are explicitly listed (what you're NOT doing)
• [ ] Risks are identified with mitigations
• [ ] Different stakeholder views are prepared (executive view vs engineering view)
• [ ] The roadmap has a review cadence defined
• [ ] You've pre-sold key stakeholders before the group review

Roadmap Planning System

A product roadmap communicates the strategic direction of a product — what you will build, why, and in what order. The Roadmap Planning System provides templates, spreadsheets, and frameworks to create, maintain, and communicate roadmaps that align engineering, design, and business stakeholders.

Prioritization Frameworks

Product managers have more ideas than engineering capacity. The following frameworks help you decide what to build next using objective, repeatable criteria.

RICE Framework

Scores each initiative on four dimensions:

• Reach — How many users will this impact in a given time period?
• Impact — How much will this move your key metric (e.g., 0.25x, 0.5x, 1x, 2x, 3x)?
• Confidence — How confident are you in your estimates (low/medium/high)?
• Effort — How many person-months or engineering weeks will this require?

RICE Score = (Reach × Impact × Confidence) / Effort

Higher scores get prioritised. The spreadsheet in this kit auto-calculates RICE scores from your inputs.

ICE Framework

A simpler variant often used for growth experiments:

• Impact — Expected outcome
• Confidence — How sure you are
• Ease — Implementation difficulty (inverse of effort)

ICE Score = Impact × Confidence × Ease

ICE is faster to apply than RICE and works well for rapid experimentation cycles where precision is less critical.

MoSCoW Method

Categorises every item into one of four buckets:

MoSCoW is best for release planning and scope negotiation with stakeholders.

How to Use the Templates

1. Collect inputs — Gather feature requests, bug reports, customer feedback, and strategic initiatives from all stakeholders.

2. Score each item — Use the RICE or ICE spreadsheet tabs to assign scores and calculate priority rankings automatically.

3. Build the timeline — Drag items from the prioritised list into quarterly and monthly roadmap views.

4. Create stakeholder views — Use the filter templates to show executives (strategic themes), engineering (issues and milestones), and customers (shipping dates).

5. Review and adjust — Revisit the roadmap each sprint or month. Scores change as new data arrives. The templates include a changelog section.

Alignment with Business Goals

A roadmap disconnected from business goals is a wish list. Every item on the roadmap should trace back to a strategic objective:

• Revenue growth — Features that increase conversion, reduce churn, or unlock new segments
• Cost reduction — Infrastructure efficiency, automation, reducing support load
• Competitive parity — Features users expect but you currently lack
• Innovation — Bets that differentiate your product in the market

The planning spreadsheet includes a "Goal Alignment" column for each item. If an item cannot be mapped to a clear business goal, it is probably not worth building.