Moving Beyond Gantt Charts
Old-school infrastructure planning was often a massive, multi-year Gantt chart detailing every server upgrade, patch cycle, and hardware refresh. It communicated tasks and timelines, but not why any of it mattered to the people who depended on the infrastructure.
A Product Roadmap is fundamentally different. It communicates the vision — the outcomes you want to achieve for your customers — and the sequence in which you plan to achieve them. It is a communication tool as much as a planning tool. A good roadmap aligns your platform team internally, manages the expectations of your developer customers, and invites feedback before you've committed to building the wrong thing.
The Now / Next / Later Framework
One of the most effective roadmap structures for internal platforms is the Now / Next / Later model, popularized by product management practitioners. It deliberately avoids specific dates (which are almost always wrong) in favor of relative time horizons:
| Horizon | Timeframe | What It Contains |
|---|---|---|
| Now | This quarter | Features actively in development, with committed delivery |
| Next | Next 3–6 months | Features in design/research phase; direction is set but details may change |
| Later | 6+ months / Future vision | Big ideas and strategic bets; subject to change based on learning |
Example Platform Roadmap:
- Now: Self-service Redis provisioning via API; automated TLS certificate renewal for all services.
- Next: Automated canary deployments for Tier 1 services; developer portal with service catalog.
- Later: Global multi-region failover as a managed service; AI-assisted incident runbook generation.
Share this roadmap publicly within the organization. Post it in your internal wiki. Present it at engineering all-hands. Actively solicit feedback. Be willing to reprioritize "Next" and "Later" based on what you learn from your users — and communicate those changes transparently. A roadmap that never changes is a roadmap that isn't being used.
A common interview question for platform engineering leads is: "How do you prioritize your platform roadmap?" A strong answer combines quantitative signals (support ticket volume, adoption metrics, time-to-deploy measurements) with qualitative signals (empathy interviews, NPS scores) and frames prioritization around developer impact per unit of platform team effort. Mentioning the Now/Next/Later framework and explaining why you avoid hard date commitments in "Later" demonstrates product maturity.