glossary · strategy
Product roadmap definition
A prioritized set of bets on which problems to solve, in what order, and under what assumptions.
A product roadmap is a prioritized set of bets on which problems to solve, in what order, and under what assumptions. It is not a delivery schedule. The most common interview failure is treating it as one: listing features with dates signals a feature-factory mindset, and interviewers at tier-one companies penalize it directly.
What interviewers actually test
When roadmap questions come up at Amazon, Google, and Meta, three things are being probed. First, can you connect each roadmap item to a business objective rather than narrate what engineering will build? Second, can you name the assumptions that would make each bet wrong? Third, can you manage stakeholder dependencies without letting the loudest team set the order?
Delivery accuracy is not on that list. Interviewers know sprints slip. They are checking whether you understand why a bet belongs on the roadmap at all.
Now/next/later vs Gantt
These formats answer different questions and belong side by side, not in competition.
- Now/next/later answers “What problems are we solving and in what order of confidence?” Only the Now column carries delivery commitment. Next and Later are direction signals: they communicate priority and sequencing without promising dates. Stakeholders will read any date as a promise. Now/next/later removes that misread.
- Gantt charts answer “When will each task finish and what does it depend on?” They are execution tools for coordinating dependencies across long engineering tracks.
When an interviewer pushes back (“But how do stakeholders know when to expect anything?”), the answer is: the Now column has scope small enough to finish this quarter, and you review signals monthly to decide what moves from Next into Now. That is the commitment mechanism, and it is honest.
Outcome-based vs output-based
An output-based roadmap item: “Redesign the incident panel.” An outcome-based item: “Reduce average incident review from 2 minutes to 90 seconds, targeting a 2x increase in customer referrals from reliability-sensitive accounts.”
The second item tells engineering why the work matters, tells design what success looks like, and gives you a clear decision rule: if the intervention moves the metric, it ships; if it does not, you stop. Output items have none of that. They produce work. Outcome items produce evidence.
RICE scoring is the standard lens for ranking bets inside a now/next/later format: Reach times Impact times Confidence, divided by Effort. A UI improvement that reaches five times more users at half the effort can legitimately outscore a payment integration, even if the payment integration feels more strategic. Show the math when you defend prioritization.
Feature-factory roadmaps carry an organizational cost that is easy to understate in interviews: they drive out engineering and design talent. When skilled engineers cannot connect their work to a problem worth solving, they leave. Framing roadmap discipline as a retention mechanism tends to land well with senior interviewers.
The 2026 shift: when feasibility is free
AI assistance means any feature can be prototyped in a sprint. When building the wrong thing gets cheaper and faster, discovery and prioritization become more critical, not less. The roadmap’s job is no longer scheduling what is buildable. It is deciding what is worth building (viable: someone will pay for this in a market that covers costs) and what is worth using (lovable: meets users where they are, anticipates needs, earns continued use).
Two practical consequences follow. First, products now have two user types: humans navigating a UI and agents calling APIs or MCP integrations. A roadmap that ignores agent-capability work is incomplete for any product with API surface area. An agent-capability column should track API reliability and task completion rate alongside the standard human-facing metrics (task success rate, human intervention rate). Second, annual roadmaps are obsolete: the signal environment changes faster than a year-long plan can accommodate. Signal reviews and strategy refreshes need to happen often enough to catch drift before it becomes a wrong-direction investment.
The hardest roadmap skill is not planning the Now column. It is having the rigor to keep the right things in Later indefinitely, and the reasoning to defend that choice when stakeholders push.
Strong vs weak answer
strong
"A roadmap is a prioritized set of bets on which problems to solve, in what order, and under what assumptions. I default to now/next/later because only the Now column carries real commitment. Next and Later are direction signals, not promises, and that distinction matters enormously when stakeholders expect dates. Each bet is framed as an outcome: the metric I am trying to move, not the feature I am planning to ship. For each bet I state the assumption that would make it wrong and the signal review date. In 2026, if the product has API or MCP surface area, I add an agent-capability column and track task completion rate alongside human-facing metrics."
weak
"A roadmap shows what features we'll ship and when. I'd structure it as MVP, v1, and v2 with dates and team owners." This conflates a Gantt chart with a roadmap, treats delivery accuracy as the success metric, and connects nothing to a user problem or business goal. When pushed ("What if engineering is slower?") the answer collapses, because no confidence level or assumption was ever stated.
For how roadmaps connect to quarterly goals, see OKRs. For the prioritization question itself, see how do you prioritize your backlog?. For why feasibility being free changes what a roadmap is for, see feasibility is free.