3.4. Product Roadmaps
💡 First Principle: A product roadmap answers "what, roughly, and roughly when" at a strategic level — it's not a detailed schedule. Its job is to show how features and capabilities will roll out across releases in a way stakeholders can plan around.
Applying a product roadmap. A roadmap communicates direction and sequencing without committing to the same level of schedule detail as a project schedule (covered in Phase 5). It answers questions like "will the reporting feature be available before or after the mobile app launch?" — useful for stakeholder planning — without pretending to know the exact day it ships.
Assigning components to releases. Deciding which components land in which release is a prioritization exercise: highest business value and dependencies that unlock other work typically move earlier; nice-to-have or dependent-on-earlier-work items move later.
⚠️ Exam Trap: A roadmap is not a substitute for a detailed schedule, and a scenario asking for exact dates, dependencies, or critical-path detail is pointing you toward schedule-management content (Phase 5), not the roadmap.
Why dependencies drive earlier placement. In the diagram above, core login lands in Release 1 not because it's the most exciting feature, but because advanced reporting and the mobile app in Release 2 both assume users can already authenticate. A roadmap that ignored this dependency and tried to ship the mobile app first would set the team up to build against a foundation that doesn't exist yet. Recognizing which components unlock later work — versus which are simply nice to have sooner — is the actual judgment being tested, not just reading a roadmap that's already been laid out correctly.
How stakeholders use a roadmap differently than a schedule. A sponsor deciding whether to greenlight a related marketing campaign needs to know "mobile app ships in Release 2," not the exact day it deploys — that's a roadmap-level answer. A delivery team member deciding what to work on this week needs the schedule, not the roadmap. Matching the artifact to who's asking, and what decision they're trying to make, is what separates roadmap-level communication from schedule-level communication.
Updating a roadmap after it's already been shared. A roadmap isn't a one-time document frozen the moment stakeholders first see it. When a newly discovered technical constraint means a feature's release genuinely needs to move — a dependency turns out to be more complex than expected, say — the correct response is updating the roadmap to reflect the new reality and communicating that change transparently, not quietly adjusting it without telling anyone, and not stubbornly keeping an outdated commitment just because it was already shared. Stakeholders planning around a roadmap need it to stay accurate more than they need it to stay unchanged.
When two features tie on value but capacity only allows one. A roadmap review sometimes surfaces two high-value features both slated for the same release, with neither blocking the other, but team capacity only supporting one of them per release. In that situation, moving one to a later release is the right call — not keeping both in against the stated capacity constraint, and not combining them into a single feature just to make the numbers fit, which blurs both features' actual scope. Respecting a stated team capacity limit takes clear priority over squeezing in everything that happens to score reasonably well on value alone, since an overloaded release helps no one.
