Now-Next-Later Roadmap

A Now-Next-Later roadmap replaces the timeline axis with confidence. Now holds work actively underway — scoped, staffed, and expected to ship soon. Next holds the small set of bets the team intends to pick up after Now clears: directionally agreed, but not yet fully shaped. Later is the parking lot of problems worth solving someday — real enough to record, too uncertain to size. The horizons are deliberately unequal: Now is specific and short, Later is broad and vague.

Crucially, the unit of each item should be an outcome or problem ('reduce onboarding drop-off', 'unblock enterprise SSO buyers'), not a feature with a fixed scope. This keeps the roadmap honest about what is genuinely known versus what is still being discovered, and it lets the solution change as evidence arrives without the roadmap looking broken.

A Gantt-style roadmap encodes a promise: this feature, on this date. Under real product uncertainty — shifting requirements, discovery still in flight, dependencies you do not control — those dates are forecasts dressed as commitments, and they age badly. When a date slips, stakeholders read it as a failure rather than as new information, which pressures teams to either pad estimates or ship half-built work to hit the line.

Now-Next-Later sidesteps this by being honest about diminishing certainty. It still communicates sequence and intent — stakeholders can see what is coming and roughly in what order — but it does not manufacture precision that does not exist. The format also absorbs change gracefully: a Later item moving to Next is normal progress, not a missed deadline. The popularised version traces to ProdPad co-founder Janna Bastow, who built it as a deliberate alternative to the timeline roadmap.

The format fails when teams smuggle dates back in — relabeling 'Now / Next / Later' as 'Q1 / Q2 / Q3'. That recreates the date-promise problem with extra steps and loses the whole point. Another trap is letting Later become an infinite dumping ground that no one grooms; if nothing ever graduates or gets killed, the column stops being a roadmap and becomes a graveyard.

The most damaging failure is filling the columns with features instead of outcomes. A feature list cannot flex when discovery changes the answer, so the roadmap fossilizes into a backlog with three buckets. Pairing the format with an explicit prioritization method — RICE, WSJF, or revenue-weighting — keeps movement between horizons defensible rather than driven by whoever lobbied last.

A Now-Next-Later roadmap is only as trustworthy as the signal behind each item. The honest question for any card is: which customers does this serve, what revenue is attached, and what evidence says it matters? When feedback, customer records, revenue, and product work live in separate tools, answering that means a manual cross-reference before every planning session — so the roadmap drifts toward opinion.

A product operating system such as AIOProductOS keeps those records joined on one shared spine, so a roadmap item can carry the feedback and revenue context of the accounts behind it. That makes promoting something from Later to Next a defensible, evidence-backed move rather than a gut call, and lets the roadmap stay current as the underlying signals change without a separate reconciliation step.