Skip to content

Roadmap Review Template

A roadmap review is a periodic check-in where engineering, product, and leadership align on progress, risks, and priorities. It's not a demo or a status update—it's a conversation about whether we're building the right things, at the right pace, with acceptable trade-offs.

What problem this solves

Without structured roadmap reviews:

  • Stakeholders lose visibility into what engineering is actually delivering.
  • Scope changes and slips accumulate without explicit acknowledgment.
  • Teams don't have a forum to raise risks or ask for priority changes.
  • Misalignment between product vision and engineering reality grows silently.

Roadmap reviews create a regular moment of truth: here's what we planned, here's what happened, here's what we recommend now.

When to use this

Cadence Audience Focus
Monthly Engineering + Product leads Progress on current quarter, near-term adjustments
Quarterly Broader leadership, exec sponsors Quarter recap, next quarter priorities, strategic alignment
Ad-hoc As needed Major scope changes, reorgs, strategy shifts

Monthly reviews keep the flywheel spinning. Quarterly reviews are more strategic. Use the same template for both—just adjust depth.

Roles and ownership

Role Responsibility
Engineering Manager Prepares progress summary, risks, and capacity outlook. Owns the review for their area.
Product Manager Provides context on customer feedback, priority shifts, and upcoming commitments.
Tech Lead Adds detail on technical blockers, architecture concerns, or delivery risks.
Leadership / Exec sponsor Asks clarifying questions. Makes decisions on proposed trade-offs.

The EM typically runs the review meeting. Product provides input beforehand.

How to run a roadmap review

Step 1: Prepare before the meeting

Don't prepare in the meeting. Come with:

  • Progress update against planned work.
  • List of risks and blockers.
  • Any proposed scope or priority changes.
  • Capacity outlook (holidays, departures, dependencies).

Share the document at least 24 hours before so attendees can read ahead.

Step 2: Review progress (10 minutes)

Walk through what was planned vs. what was delivered. Be honest about slips—explain, don't hide.

Step 3: Surface risks and blockers (10 minutes)

Raise anything that threatens upcoming delivery. Include:

  • Dependencies on other teams.
  • Technical risks (unknowns, complexity).
  • Capacity issues (hiring, attrition, holidays).

Step 4: Propose adjustments (10 minutes)

If priorities should change, say so explicitly. Present trade-offs:

  • "If we add X, we drop Y."
  • "We can accelerate A if we defer B."

Ask for a decision, not just awareness.

Step 5: Align on next steps (5 minutes)

Confirm what's decided. Capture action items with owners and dates.

Step 6: Document and share

After the meeting, update the roadmap artifacts (Jira, Notion, roadmap tool) to reflect decisions. Share the summary with stakeholders who weren't present.

Signals that roadmap reviews are working

  • Stakeholders trust the roadmap and don't ask for constant updates.
  • Scope changes are discussed explicitly, not discovered after the fact.
  • Engineering has a voice in prioritization, not just execution.
  • Risks are surfaced early—before they become crises.
  • Decisions are made in the meeting, not deferred.

Failure modes and mitigations

Failure mode What it looks like Mitigation
Reviews become status updates Just reading Jira tickets; no strategic discussion Focus on risks and trade-offs; use async for status
No decisions are made "Let's discuss offline"; nothing changes Explicitly ask for decisions; escalate if blocked
Over-optimistic progress Everything is "on track" until it isn't Ask probing questions; compare plan vs. actual
Product not involved Engineering reviews happen in isolation Co-own the agenda; Product presents priority context
Roadmap changes without review Scope changes happen between reviews, untracked All significant changes go through a review (even async)

The template

Roadmap review document

# Roadmap Review — [Team/Area Name]

**Date:** [YYYY-MM-DD]
**Period:** [Month / Quarter]
**Attendees:** [List]

---

## Executive summary

[2-3 sentences: Overall health of roadmap delivery. Key wins. Top concern.]

---

## Progress against plan

| Initiative     | Planned          | Actual           | Status                                | Notes     |
| -------------- | ---------------- | ---------------- | ------------------------------------- | --------- |
| [Initiative 1] | [Milestone/date] | [What delivered] | ✅ On track / ⚠️ At risk / ❌ Blocked | [Context] |
| [Initiative 2] | [Milestone/date] | [What delivered] | ⚠️ At risk                            | [Context] |
| [Initiative 3] | [Milestone/date] | [What delivered] | ❌ Blocked                            | [Context] |

**Highlights:**

- [Key accomplishment]
- [Key accomplishment]

**Slips:**

- [Initiative X] slipped by [N weeks] due to [reason].

---

## Risks and blockers

| Risk/Blocker                        | Impact | Likelihood | Mitigation         | Owner  |
| ----------------------------------- | ------ | ---------- | ------------------ | ------ |
| [Dependency on Team Y]              | High   | Medium     | [What we're doing] | [Name] |
| [Technical complexity in Feature Z] | Medium | High       | [What we're doing] | [Name] |
| [Upcoming PTO affecting capacity]   | Low    | Certain    | [Coverage plan]    | [Name] |

---

## Proposed adjustments

### Add

| Item       | Rationale            | Trade-off               |
| ---------- | -------------------- | ----------------------- |
| [New work] | [Why it's important] | [What we defer or drop] |

### Defer

| Item            | Original target | New target | Rationale |
| --------------- | --------------- | ---------- | --------- |
| [Deferred work] | [Q1]            | [Q2]       | [Why]     |

### Drop

| Item           | Rationale              |
| -------------- | ---------------------- |
| [Removed work] | [Why no longer needed] |

**Decision requested:** [Clearly state what you need approved]

---

## Capacity outlook

**Current team:** [N engineers]

**Changes:**

- [Name] joining [date]
- [Name] departing [date]
- Holiday period: [dates] — reduced capacity

**Effective capacity for [next period]:** [N] FTEs

---

## Looking ahead

**Next period focus:**

- [Priority 1]
- [Priority 2]
- [Priority 3]

**Dependencies to resolve:**

- [Dependency] — need from [Team/Person] by [date]

---

## Decisions made

| Decision     | Owner  | Date   |
| ------------ | ------ | ------ |
| [Decision 1] | [Name] | [Date] |
| [Decision 2] | [Name] | [Date] |

---

## Action items

| Action     | Owner  | Due    |
| ---------- | ------ | ------ |
| [Action 1] | [Name] | [Date] |
| [Action 2] | [Name] | [Date] |

Quarterly roadmap review agenda (60 minutes)

# Quarterly Roadmap Review — [Team/Area]

**Date:** [Date]
**Attendees:** [Engineering, Product, Leadership]

---

## Agenda

| Time        | Topic                                       | Lead           |
| ----------- | ------------------------------------------- | -------------- |
| 0:00 - 0:05 | Opening: Quarter goals reminder             | EM             |
| 0:05 - 0:15 | Progress review: What delivered vs. planned | EM             |
| 0:15 - 0:25 | Risks and blockers discussion               | EM + Tech Lead |
| 0:25 - 0:35 | Priority/scope adjustment proposals         | PM + EM        |
| 0:35 - 0:45 | Decision-making: Trade-offs and approvals   | Leadership     |
| 0:45 - 0:55 | Next quarter preview                        | PM             |
| 0:55 - 1:00 | Action items and close                      | EM             |

---

## Pre-read

- [Link to roadmap document]
- [Link to review summary]

Please review before the meeting. We'll focus on discussion, not presentation.