glossary · general
Product roadmap definition
A prioritized, time-horizon plan that communicates what a team is building, in what order, and why. A communication artifact as much as a planning tool.
A product roadmap is a prioritized, time-horizon plan that communicates what a team is building, in what order, and why. It is a communication artifact as much as a planning tool: not the source of truth for every ticket, but the document that aligns executives, engineers, and customers on direction and sequence.
Three terms that get conflated: strategy is the why and where (which market, which problem); the roadmap is the what and roughly when (sequenced work tied to that strategy); the backlog is the unordered universe of possible work. Not every backlog item earns a roadmap slot. Conflating roadmap and backlog signals list management rather than decision-making, and interviewers test this distinction directly.
Three formats in use in 2026
Timeline (date-based): commits to delivery windows by calendar. Useful when stakeholders need contractual commitments: enterprise sales, hardware supply chains, regulatory deadlines. The risk is false precision: a date no one modeled is noise.
Now-next-later (horizon-based, no hard dates): commits to direction without committing to dates. “Now” is in active development; “Next” is decided and designed; “Later” is directionally committed but not sequenced. Default to this in an interview unless the company or prompt signals otherwise. Notion and Linear use it internally because it prevents false precision from becoming a stakeholder expectation.
Outcome/bet-based: each item names the user problem, the outcome metric it is expected to move, and a review date rather than a ship date. The review date is a checkpoint: continue, kill, or expand based on data. Shopify operates closer to this model.
A roadmap item that reads “Build [feature name]” is output thinking. A strong item names the user problem, the outcome metric it moves, and a review date.
How AI products change the roadmap in 2026
In 2026, feasibility is nearly free. A capable team can ship most things in weeks with AI-accelerated development. The roadmap’s job is no longer sequencing what engineering can handle. It is a viability and lovability filter: is there a paying market for this outcome, and will users actually integrate this into how they work, not just try it once?
Any product with current or likely agent users needs a dual-stream roadmap: one lane for the human UI experience, one for the API and MCP surface that AI agents will call. A roadmap that only covers the UI layer is already incomplete.
The shipping velocity trap is real. AI-assisted development makes it cheap to ship the wrong thing fast. The roadmap’s job is a decision system with explicit kill/continue/expand checkpoints, not a delivery schedule.
What interviewers are actually testing
Roadmap questions check three things: can you anchor on an outcome before touching format; can you match the format to the uncertainty level; and can you name the assumptions that would change the sequence.
weak
"I would list the features we need, score them by impact and effort, and create a quarterly timeline. Q1: feature A, Q2: feature B, Q3: feature C. Then I'd share it with stakeholders." Output thinking, false precision, no outcome framing. This signals a PM who manages a list rather than shapes a direction.
strong
"A roadmap is a communication artifact, so I start by anchoring to a specific outcome: what metric are we moving, for which segment, over what horizon? Then I pick the format that matches the uncertainty. For a mature product with committed enterprise stakeholders, a quarterly timeline works. For anything with real unknowns, I'd use now-next-later, because it commits to direction without committing to dates I cannot keep. Each item names the user problem and the outcome metric it moves, not just the feature. I'd call out key assumptions and a review date for each bet. In 2026 I'd also ask: are we planning for human users, agent users (API/MCP), or both? A roadmap that only covers the UI layer is already incomplete."
The seniority signal is whether the candidate starts with the item list or starts with the outcome. Features before goals is output-mode thinking, and interviewers recognize it immediately.
For the format this answer defaults to, see now-next-later. For how to sequence what earns a roadmap slot, see prioritization. For the 2026 context on why feasibility being free changes the calculus, see feasibility is free.