A city product roadmap slide lists months of committed features. What should the Product Owner change?
Select an answer to reveal the explanation.
Short Explanation
Far-out roadmap boxes look like reservations, but they are really guesses in a nice font. Turn the distant stuff into themes and hypotheses, and keep crisp order only on what is actually next. A slide is a forecast, not a lease on next autumn's features.
Full Explanation
A city product roadmap slide that lists months of committed features confuses directional intent with Product Backlog order. The Product Owner should convert far-horizon items to themes or hypotheses and keep ordered backlog detail only for the near term, where evidence and refinement can support forecasting. Keeping far-horizon features as dated commitments so departments can staff against them hardens guesses into political contracts and makes later adaptation look like broken promises. Deleting the entire roadmap because Scrum products must never show work beyond the current Sprint is unnecessary secrecy; stakeholders can still see themes without fake dates. Copying the slide into the Product Backlog as Sprint Goals for the next six months hardens the contract further and misuses Sprint Goals as a multi-month feature schedule. Exam caveat: roadmaps may communicate intent; only near-term ordered backlog items carry commitment-like detail under empiricism. Operational check: rewrite the slide so the next one or two horizons show ordered, refined items, everything farther out is labeled theme or hypothesis without feature-level dates, and Sprint Goals remain outcomes for a single Sprint.