9.3 Product Roadmaps

What a Product Roadmap Is (and Is Not)

A product roadmap is a strategic document that communicates the high-level direction, priorities, and planned evolution of a product over time. It is the bridge between product strategy (the vision) and execution (the backlog and releases). On the CAPM exam, the single most-tested idea is this distinction: a roadmap is a strategic communication tool, not a detailed project schedule or a list of every technical specification. When an answer option describes "every task with exact dates," it is describing a project plan, not a roadmap.

Why roadmaps exist

• Communicate vision — share product direction with stakeholders.
• Align teams — keep development work pointed at strategic goals.
• Set expectations — convey what is coming and roughly when.
• Guide prioritization — inform what to build next.
• Enable planning — provide the frame for release and iteration planning.

Types of Roadmaps

Modern agile practice favors goal/outcome-oriented roadmaps over feature lists, because committing to specific features far in advance reduces the flexibility the roadmap is supposed to preserve.

Roadmap Components

Release Planning

Release planning decides which features, components, or capabilities go into each release. Domain 4, Task 4 explicitly asks you to "determine which components go to which releases."

The seven release-planning steps

1. Define release goals — what this release must achieve.
2. Prioritize features — which deliver the most value (MoSCoW, value/effort).
3. Estimate effort — size each feature (story points or hours).
4. Determine capacity — what the team can actually deliver (velocity).
5. Allocate features to releases — fit priorities into capacity.
6. Identify dependencies — sequence work that must precede other work.
7. Communicate the plan — share it with stakeholders.

Worked example: A team has 40 story points of velocity per release and a backlog of features sized 20, 15, 10, and 8 points, prioritized in that order. Allocate to Release 1 until capacity is reached: 20 + 15 = 35, and the next item (10) would push to 45 and exceed 40. So Release 1 holds the 20- and 15-point features (35 points), and the 10- and 8-point features slide to Release 2. This "fill to capacity by priority" logic is a frequent CAPM release-planning question.

MVP vs. MMP — A High-Yield Distinction

The Minimum Viable Product (MVP) is the smallest version that can be released to validate assumptions and gather feedback. It exists to learn with minimal investment, reducing the risk of building the wrong product. The Minimum Marketable Product (MMP) is the smallest version that is ready to sell and use — it exists to generate value/revenue.

Trap: The MVP is not a low-quality or unfinished product, and it is not a prototype thrown away. It is a usable slice that delivers enough to produce real learning. Options that define MVP as "a rough prototype with no real users" are wrong.

Tailoring the Roadmap to the Audience

A single roadmap is re-cut for each audience. The level of detail rises as you move from boardroom to backlog.

Trap: Giving executives a sprint-task breakdown, or giving the development team only vague themes, are both wrong-altitude answers. Match the detail to the audience's decisions.

Keeping the Roadmap Alive

Roadmaps are living artifacts. They are reviewed and re-prioritized as the team learns from each release, as market conditions shift, and as stakeholder priorities change. A roadmap that is locked and never updated has stopped serving its purpose. This flexibility is exactly why outcome-oriented roadmaps (themes and goals) are preferred over rigid date-and-feature commitments — they communicate intent without over-promising specifics the team may need to change.

Key principle: A roadmap shows where the product is going and why; the backlog and release plan show how it gets there. Confusing the two — treating the roadmap as a guaranteed delivery schedule — is the trap CAPM tests most often in Task 4.