Now/Next/Later product roadmap

Why the format exists

A classic dated roadmap with a Gantt chart works in exactly two situations: when your team ships infrastructure with a known endpoint, or when you can predict the future. Most product teams have neither. Three months in, the plan no longer matches reality — priorities shifted, a hypothesis didn't pan out, a security review pulled two engineers, a competitor shipped something that changed your sequencing.

Now/Next/Later removes that pain by changing what you commit to. The team stops promising dates and starts promising order. Right now we're working on these. Next we'll pick up these. Later, if priorities hold, we'll touch these. Stakeholders see what's in flight, what's queued, what's on the radar — without the false comfort of a "June 24 release" line that always slips.

The format was popularized by Janna Bastow of ProdPad and became the de facto standard at companies like Linear, Notion, and Figma. It matches how discovery behaves: you learn, you adjust, you don't pretend the calendar is a contract.

What goes in each column

Now. What the team is actively building or will start in the next 2–6 weeks. The scope is understood, a PRD or design doc exists, an owner is named. Confidence is high.

Next. What the team picks up after now. Horizon of 1–3 months. The hypothesis is framed and there's a rough estimate, but design and scope can still shift. Confidence is medium.

Later. Candidates on the radar. Hypotheses, themes, problem spaces. No estimates, no owner required, no commitment. Confidence is low. This is also the holding pen for anything that didn't fit in next but is worth keeping visible.

The single rule that separates a real roadmap from a wishlist: every entry ties to a user problem or a metric, not to a feature. "Build a new onboarding" is a weak entry. "Lift D7 retention of new signups from 38% to 48%" is a real one.

Promotion criteria between columns:

• Later → Next. A solution shape exists, the hypothesis names a metric, a T-shirt estimate is on the table (S/M/L).
• Next → Now. PRD or design doc is ready, the team has capacity, an owner is named.
• Now → Shipped. Released, monitored for 1–2 months, hypothesis verified or killed.

If a theme has sat in next for more than a quarter without moving, that's a signal. Either the priority dropped (push to later) or you don't actually understand the problem yet (kick it back to the discovery stage and re-frame it as a problem statement, not a solution).

The template

One row equals one theme. Attach the following to every theme that lives in now or next:

• A one-sentence hypothesis.
• A success metric.
• An owner.
• Confidence (low / medium / high).
• A T-shirt estimate (XS / S / M / L) as a rough sizing signal.

Tools that work: Linear, Notion, Productboard, or a shared spreadsheet. The tool matters less than the discipline of linking each row to a real PRD. If a row opens a stale doc, the roadmap is decorative.

A filled-in example

Let's use a hypothetical interview-prep app — call it the NAILDD product team — to make this concrete.

What to notice in this example:

• Each column holds three rows. If you have eight, you have a backlog, not a roadmap.
• Every theme has a metric. None of them say "improve UX."
• Later rows have no owner and no confidence. That's the point — they're watchlist items, not commitments.

This is also why later is the most under-used column on most teams: PMs feel naked listing themes without owners, so they delete them. Don't. The visibility is the value.

An expanded card behind a now row — useful to attach to every entry:

Theme: Lift onboarding completion
Hypothesis: choosing 1 topic instead of 3 lowers
            the activation barrier, more users finish onboarding
Primary metric: onboarding completion rate
Guardrail: D7 retention of new signups
Target: 62% → 75% (+13 pp)
Experiment: A/B 50/50, 14 days, MDE +5 pp
Owner: Anna
Confidence: high
T-shirt: M (~2 sprints)
Status: in design

How to update it every month

A healthy cadence looks like this:

1. Every 2 weeks — team sync on now. What moved, what shipped, what slipped.
2. Every month — review next. What's ready for now, what should drop to later.
3. Every quarter — large refresh. Re-align with OKRs, reshuffle all three columns.

The most useful ritual after each release is honestly marking whether the hypothesis held. If yes, the theme exits and the team picks the next one. If no, it drops to later or dies. Skip this and the roadmap becomes a graveyard of shipped features no one remembers the result of.

A 45-minute monthly review usually breaks down as:

• 5 min — recap of last month's closed themes.
• 15 min — review next: what's ready to promote, what's not.
• 15 min — sweep later: what's gained relevance, what's stale.
• 10 min — write decisions and ship an async update to stakeholders.

Without that ritual, the roadmap turns into a parking lot. The team moves on Slack but nothing changes in the document, and trust quietly erodes.

How it differs from a Gantt chart

The contrast in one table:

Gantt isn't evil. It works wherever scope is genuinely fixed: a signed partner integration, a data migration, a compliance audit. In open-ended product work where the goal is to move a metric, now/next/later is more honest because the scope is the variable, not the date.

Many companies run both in parallel — now/next/later for product themes, Gantt for platform projects with external deadlines. That hybrid is often the right answer at Series-B and above.

How to defend the format to leadership

The recurring fight is "we need dates." The arguments that actually land:

• Show the receipts. Pull the last three quarterly Gantt charts and measure how far they slipped. The honest number is usually 30–50%. A roadmap that's wrong half the time isn't a planning tool; it's theater.
• Explain that now still contains sprints with timelines. The difference is you don't promise dates for themes that haven't started. That's not less rigorous, it's more honest.
• Tie every row to an OKR. Stakeholders see that priorities trace back to business goals, not to PM whim.
• Add soft launch windows only to now. If marketing needs lead time, that's where you give it — never on next or later, and never in any external comms.

The other common objection is "we don't know what we'll be doing in six months." Correct — and that's the point. The business shifts faster than any roadmap. A six-month Gantt would be wrong anyway; later is the honest container for "themes we'll get to when we have signal and capacity." A six-month Gantt lies with precision; a six-month later list tells the truth with ambiguity.

If you want to drill product-management questions like these — roadmap defense, OKR design, prioritization frameworks — NAILDD is launching with 500+ PM and analytics interview problems.

Common pitfalls

The most common failure mode is stuffing every column with eight or ten entries, which turns the roadmap into a backlog dump. The fix is brutal: cap each column at three to five themes and force a "promote or drop" decision on everything else. A roadmap that contains every idea contains no priorities.

A second trap is themes without metrics. "Improve onboarding" sounds like work but commits nothing — no way to know if it succeeded. Require a primary metric and target on every now and next row. If you can't name the metric, you don't yet understand the problem.

A third common failure is stakeholders reading next and later as dated commitments. They'll cite a later row in a board meeting and ask why it slipped. The fix is repetition: state in every stakeholder update that only now is a commitment, and repeat it until it's annoying.

A fourth pitfall is the roadmap that never updates. Two months in, the document is fiction and the team plans in Slack. The fix is a calendar invite: monthly 45-minute review with a named owner. If no one owns the update, no one updates it.

A fifth trap is inconsistent grain combined with no owner on now rows. One row reads "improve retention," the next reads "fix the empty-state button" — not the same kind of work. And "the team will handle it" reliably means no one will. Pick a level (usually "user problem with a target metric"), normalize every row to it, and attach a single name to every active theme.

Related reading

• How to choose a North Star metric
• ICE prioritization framework for PM
• RICE prioritization for product managers
• PRD in product manager interviews
• JTBD framework: how to apply it

FAQ

How many rows should I keep per column?

Three to five. More than five and the column stops being scannable — readers can't tell what's important. Fewer than three and you've over-compressed; you're hiding real work in your head instead of making it visible. Three is the sweet spot for most teams under 30 engineers.

Can I put dates inside now?

Sprint-level estimates are fine — "shipping by sprint 14" or "design freeze by Friday" — because now is the column where you actually have scope. The thing to avoid is calendar dates on next and later rows. Once you write "Q3" next to a later item, stakeholders will treat it as a promise, and the format dies.

What do I tell a stakeholder who demands dates?

Acknowledge it, then re-frame. Now has sprint estimates, next has a horizon in months, later has none. If a theme genuinely needs a calendar date — external contract, marketing commitment — promote it into now with its own plan rather than dating the whole roadmap.

How often should I update the roadmap?

At minimum, monthly. Healthy teams sync on now every two weeks, refresh next monthly, and do a full quarterly review. Consistency beats frequency — a roadmap on a known rhythm builds far more trust than one updated whenever someone remembers.

Where should I host it?

Anywhere with version history and team-wide access. Linear, Notion, Productboard, Confluence, or a shared Sheet all work. The wrong answer is "in my slide deck" — if the roadmap only updates when you give an exec readout, it's not a roadmap.

Does this format work for B2B with long sales cycles?

Yes, usually as a hybrid. Now/next/later covers the product themes — discovery, experimentation, UX work. A parallel Gantt covers contractual integrations, security audits, and customer-committed deliverables with hard dates. Trying to force enterprise commitments into a later column will get you yelled at; don't.

How do I tie roadmap rows to OKRs?

Every now and next row should reference a specific Objective or KR. If a row ties to nothing, either the row is extraneous or your OKR set is incomplete. Both are useful signals — the roadmap quietly surfaces gaps in the strategic plan.

What do I do with themes that have lived in later for a year?

Sweep them quarterly. If a later theme hasn't moved in two consecutive reviews, delete it. Genuinely important ideas come back. Leaving dead themes in the column makes the rest of later look like noise, and stakeholders stop reading it.