September 7, 2026 · 8 min read
TL;DR: The product roadmap and release plan appear in 23 answer options across the bank and are keyed 7 times. Every keyed use treats the roadmap as a coarse view of what arrives when, derived from a vision and owned by the product owner. The 16 distractors ask it to do something else: explain why the project exists, stay fixed while customers leave, get built before the vision is shared, or bend to one stakeholder's preference.
The roadmap is easy to describe and easy to misuse in an answer option, because it sounds like planning and planning sounds safe. The bank keys it less than a third of the time, and the losses fall into patterns you can learn.
When someone asks what is ahead, at a horizon and a grain the backlog does not serve.
A sponsor and product owner, pleased with progress, ask about upcoming items and what development will look like ahead. Keyed is the product roadmap. The product backlog is the strongest distractor and contains the upcoming items, but it is an ordered list at item granularity with no dates, and a sponsor reading it gets detail without a horizon. The velocity chart reports the past. The project management plan describes how the project is controlled, not what the product will become.
A team new to agile refuses a customer's request for a schedule on the grounds that schedules belong to predictive work. Keyed is asking the team to develop a high-level release plan, like a product roadmap, showing the features in each release. Telling the customer that adaptive work does not plan ahead is the distractor the bank is built to catch.
A scrum team has lost its technical lead and been hit by repeated operational issues. Keyed is reviewing the constraints in the ongoing sprint planning and evaluating the options for the release plan. Stopping the sprint to cut resource levels reduces capacity that is already short. Pressing on with the existing plan ignores constraints the team already knows are binding. And when velocity comes in at 37 and 35 points against an estimate of 50, the keyed pair tells the product owner that on the empirical data the release plan is not achievable, and explores adding resources with them rather than pushing the team to hit the number.
Requirements for a seed-bank application are vague: outcomes described, features not. Keyed as a set of three is settling a product vision with the sponsor, decomposing the roadmap progressively from themes into features into buildable requirements, and running story-writing workshops. The roadmap is the middle step, and it comes after the vision.
That ordering is the whole slice in miniature. A roadmap after eight months has items that no longer trace to the vision and releases sequenced by whatever is easiest to build. Keyed is confirming with the product owner and key stakeholders that the vision still holds, then having the roadmap rebuilt from it. Re-ranking the same items by business value skips that step, because value only means something measured against the outcome you are aiming at.
It is asked to answer why. An incoming project manager needs to understand the project's strategic benefits and objectives. The roadmap is offered and loses to the business case, because the roadmap describes the plan of delivery rather than the justification. It answers what and when, never why.
It is built before the vision is shared. A project manager has drafted a vision statement after a workshop with the client and product owner. Beginning the roadmap is offered and loses to discussing the vision with the team and inviting their questions. The roadmap follows buy-in, and the product owner creates it.
It stays fixed while the market moves. Customers are drifting to a competitor's easier checkout. Staying on the current roadmap and revisiting the checkout in a later release is offered and loses to a detailed discussion with the product owner about the feedback and the market shift. The explanation calls staying on the roadmap the one reading that treats a live loss of customers as a scheduling matter. Note that a full overhaul is also wrong here: the project manager has noticed a signal, not established a requirement.
It bends to one stakeholder. A senior business stakeholder presses an agile team to deliver nearly everything in one release eighteen months out. Passing the position to the team and reshaping the release plan around it loses to meeting the stakeholder to understand their concern while explaining what incremental delivery buys them.
It belongs to someone else. A vendor's product lead sets release content from the vendor's own roadmap, and each release arrives full of self-service features while the rest-rules engine slips. Stripping the roadmap features out of each release is offered and loses to settling one version of the outcome this deployment must achieve with that product lead. A vendor's conference demonstration puts a feature on its roadmap with no contracted date, and operations directors are planning staffing cuts around it. Keyed is agreeing what the directors must see working in their own service before the decision is taken. A supplier's roadmap is not a commitment, and disputing it in front of people who trust it gains nothing.
Common trap: putting predictive artefacts inside the roadmap, or the roadmap inside predictive artefacts. Asked how product scope should be approved on an agile automotive project, decomposing the deliverables into work packages in the product roadmap is offered and loses to demonstrating features and obtaining the product owner's approval at the iteration review. The explanation says the option mixes two artefacts that do not belong together. Asked what eliciting requirements on an adaptive delivery produces, the roadmap loses to the product backlog, because the roadmap is agreed earlier and at a much coarser grain. The bank makes this grain error in three separate items, and each explanation names the horizon the roadmap serves rather than just marking the option wrong.
The vision is one statement, the roadmap is themes and releases over months, the release plan is the next release or two, and the backlog is item by item.
| Artefact | Grain | Horizon | Who owns it | The bank keys it when |
|---|---|---|---|---|
| Product vision | One statement of what the product is for | The product's life | Sponsor and product owner, shared with the team | Items have stopped tracing, or the purpose has been delivered and nothing replaced it |
| Product roadmap | Themes, features, releases against rough dates | Months | Product owner | A sponsor asks what is ahead; a customer asks for a schedule |
| Release plan | Which features in which release | The next release or two | Product owner with the team | Constraints change and options must be re-evaluated |
| Product backlog | Ordered items | Item by item | Product owner | Requirements are being elicited; a request arrives |
The five-year programme in the bank shows the top row failing. Its chartered purpose has been delivered since year two, roadmap items are now chosen release by release on each team's own reading, and two consecutive releases pulled in opposite directions. Keyed is re-forming the intended outcome with the sponsor and key customers, then re-deriving the roadmap with the teams. Having the delivery teams agree a working statement among themselves is the closest miss, and a purpose settled without the sponsor or the paying customers is a preference the next disagreement can overturn.
When is the product roadmap the keyed answer on the PMP exam? When a sponsor or product owner asks what is coming over the next months, when a customer new to agile asks for a schedule, when a release plan has to be re-evaluated against new constraints, or when vague requirements need to be decomposed progressively from themes into features. The roadmap is the high-level what-and-when view.
When is the roadmap the wrong answer? When the question is why the project exists, which the business case answers; when staying on the roadmap would ignore a live market signal; when it is built before the team has discussed the vision; or when it is reshaped around one senior stakeholder's preference instead of the value the increments deliver.
Who owns the product roadmap? The product owner. The roadmap says what value the product will deliver and in roughly what order, so ownership follows the authority to decide what is worth building. The project manager may maintain it in a hybrid setting with no product owner, but the sequencing by value is not the team's or the scrum master's to set.
What is agile release planning for? A high-level summary timeline of the release schedule on less predictive projects, showing how many iterations a release needs. It deliberately stays coarse rather than fixing precise scope, dates or fully detailed requirements up front.
PMP Practice's 2,141 questions are certified against PMBOK 8 and the July 2026 ECO, with every wrong answer explained rather than just marked wrong. Start the free 20-question sample — no card, no signup required to try it.
Related reading: The Product Owner on the PMP Exam: What They Decide, and What They Never Get to Decide and Developing a Common Vision: Why the Answer Is Never the Document. Schedule tasks are mapped on the Process domain study page.
When is the product roadmap the keyed answer on the PMP exam?
When a sponsor or product owner asks what is coming over the next months, when a customer new to agile asks for a schedule, when a release plan has to be re-evaluated against new constraints, or when vague requirements need to be decomposed progressively from themes into features. The roadmap is the high-level what-and-when view.
When is the roadmap the wrong answer?
When the question is why the project exists, which the business case answers; when staying on the roadmap would ignore a live market signal; when it is built before the team has discussed the vision; or when it is reshaped around one senior stakeholder's preference instead of the value the increments deliver.
Who owns the product roadmap?
The product owner. The roadmap says what value the product will deliver and in roughly what order, so ownership follows the authority to decide what is worth building. The project manager may maintain it in a hybrid setting with no product owner, but the sequencing by value is not the team's or the scrum master's to set.