Product Roadmap

A product roadmap is a communication artifact showing what a product team plans to build, in what order, and on what time horizon. It is used to align engineering, design, sales, leadership, customers, and investors around the same direction of travel. It is the most-misunderstood deliverable in product management because internal audiences want commitments and external audiences want certainty, while a good product roadmap exists to communicate priorities and tradeoffs honestly across both.

The dominant modern format is now / next / later (popularized by Janna Bastow at ProdPad), which groups initiatives into three time-horizon buckets without committing to fixed dates: now (in active development, this quarter), next (planned for the following quarter, less detail), and later (directional commitments, no specific timing). This format replaced the classical Gantt-chart roadmap (specific features on specific dates over 12 to 18 months) because Gantt-chart roadmaps either lock teams into bad bets or get blamed every time something slips, both of which damage trust. Other widely-used formats: outcome-based roadmaps (organized by the metric or customer outcome each initiative drives, not by feature), opportunity solution trees (Teresa Torres's discovery framework that maps roadmap items back to validated opportunities), and theme-based roadmaps (initiatives grouped by strategic theme rather than individual feature). The 2024 to 2026 convention in most modern product orgs is to maintain two views: an internal roadmap with more detail and the actual bets, and an external customer-facing roadmap that's deliberately less specific to avoid commitment debt. Companies like Linear, Notion, and Productboard have built tools designed for this two-view pattern.

Ryan's Take

A product roadmap is not a project plan. The moment you put dates on a roadmap and start tracking on-time delivery against them, you have stopped doing product and started doing project management. The good versions communicate priorities and tradeoffs: what we believe matters most, what we are deliberately not doing, and what we are still learning. The bad ones are commitments dressed up as plans, which the team then either gets blamed for missing or gets locked into shipping after they realize it was the wrong bet. Roadmaps should change when the evidence changes. If yours hasn't shifted in six months, you are either not learning or not being honest with yourself.

What founders get wrong: Treating the roadmap as a sales tool and committing to features in customer conversations that aren't actually committed internally. Every customer-promised feature becomes a future obligation that distorts prioritization. Keep the customer-facing roadmap directional and the sales team trained to say "that's on our roadmap, no specific timing" rather than "we'll have that by Q3."

Related: [Product Management] · [Product Strategy] · [Product Backlog] · [Product Vision] · [Feature Prioritization]

FAQ

What is a product roadmap? A communication artifact showing what a product team plans to build, in what order, and on what time horizon. Used to align engineering, design, sales, leadership, customers, and investors around the same direction of travel.

What is a now-next-later roadmap? A roadmap format popularized by ProdPad's Janna Bastow that groups initiatives into three time-horizon buckets without fixed dates: now (in active development), next (planned for the following quarter), and later (directional commitments). It replaced the date-committed Gantt format that broke trust when dates slipped.

Should I share my product roadmap with customers? Yes, but with a different version than your internal one. The customer-facing roadmap should be directional and less specific to avoid commitment debt. Train sales to say "that's on our roadmap, no specific timing" rather than "Q3 delivery" unless the date is genuinely committed.