Now-Next-Later Roadmaps: When They Work and When They Don't

TL;DR. A now-next-later roadmap groups work into three horizons — what the team is doing now, what it expects to tackle next, and what it is considering for later — instead of placing features on a calendar. It works well when the main uncertainty is what to build, and when stakeholders need direction more than dates. It breaks down when the business runs on fixed external dates, when many teams must coordinate tight dependencies, or when the columns fill up with features instead of problems. Most teams that use it well keep a small, separate list of genuinely date-bound commitments alongside it.

What is a now-next-later roadmap?

A now-next-later roadmap is a product roadmap organised by time horizon and confidence rather than by delivery date. Items move from right to left as the team learns more about them:

• Now — work that is in progress or about to start. The problem is understood, the approach is largely decided, and the team is committed.
• Next — problems the team expects to take on soon. They are understood well enough to prioritise but still being explored and validated.
• Later — problems and opportunities the team believes matter but has not yet invested in. They carry the least detail and the most uncertainty.

The format is closely associated with Janna Bastow, co-founder of the product management software company ProdPad, who has written about why she created it as an alternative to timeline roadmaps.

The key property is that detail and certainty decrease as you move right. "Now" can be specific; "Later" should be deliberately vague. That is a feature of the format, not a gap in it.

How is it different from a timeline roadmap?

A timeline roadmap answers "what will ship, and when". A now-next-later roadmap answers "what are we working on, in what order, and why".

	Timeline roadmap	Now-next-later roadmap
Organised by	Dates, quarters or releases	Horizons of confidence
Typical item	A named feature with a target date	A problem or outcome, with features only in "Now"
Implied promise	Delivery by a date	Order of attention and direction
Handles new information by	Slipping or re-baselining dates	Moving items between columns
Best at communicating	Coordination and commitments	Strategy and priorities
Main risk	False precision about the future	Vagueness that hides a lack of decisions

Neither is universally better. They make different promises, and the right one depends on which promise your stakeholders actually need.

When does a now-next-later roadmap work well?

• When the main uncertainty is what to build. Early products, new markets and discovery-heavy teams learn quickly. A dated plan made in January is often wrong by March; a horizon-based plan absorbs that learning without a public re-plan.
• When the roadmap's job is to explain strategy. Leadership, sales and customers often need to know which problems you are prioritising and why, more than they need a list of dates. Framing items as problems — tied to the customer jobs you found in discovery, as described in Jobs to Be Done for B2B Product Teams — makes the reasoning visible.
• When teams are organised around outcomes. If teams own a metric rather than a feature list, a now-next-later roadmap lets each item name the outcome it is meant to move. A clear North Star metric with defined inputs makes this much easier.
• When you want to stop over-committing. Removing dates from the public view removes the pressure to promise delivery on work nobody has scoped yet.

When does it not work?

• When the business runs on fixed external dates. Regulatory deadlines, contractual commitments, trade events, seasonal launches and partner integrations have dates whether the roadmap shows them or not. Hiding them in "Now" or "Next" does not make them movable.
• When many teams share tight dependencies. Programmes where hardware, platform, data and product teams must land work in sequence need a shared schedule to coordinate. Horizons alone do not tell team B when team A's piece will be ready.
• When enterprise buyers need dated commitments. In some B2B deals, a feature date is part of the purchase decision. A roadmap that refuses all dates can cost deals — the answer is a controlled way to make specific commitments, not pretending they are never made.
• When the columns are feature lists in disguise. If "Next" is simply the next ten features in priority order, the team has built a timeline roadmap without the dates and kept all of its problems.
• When "Later" becomes a storage unit. A "Later" column that only grows turns into a list of things the team will never do, and stakeholders learn to read it as "no".

How do you handle stakeholders who need dates?

Keep two artefacts rather than forcing one to do both jobs.

1. The now-next-later roadmap communicates direction and priority. It is the default view for most audiences.
2. A short commitments list records the few items that genuinely have a date — a contractual deliverable, a compliance deadline, a launch tied to an event. Each entry has an owner, a date and the reason it is date-bound.

When a date is requested for something in "Next" or "Later", treat it as a prioritisation decision: committing a date means scoping the work now and accepting what it displaces. Most requests for dates are really requests for confidence that a problem is being taken seriously, and a clear position in "Next" with a stated reason often answers that.

How do you build a now-next-later roadmap?

1. Start from strategy, not the backlog. Write down the two or three outcomes the product needs to achieve this year. If there is no stated strategy, fix that first — Product Strategy, Explained is a starting point.
2. Frame items as problems or outcomes. "Reduce time for finance teams to close the month" survives learning; "add bulk export" may not.
3. Place items by confidence, not by desire. An item belongs in "Now" only if the team has capacity and understands the problem. Important but unexplored work belongs in "Next" or "Later".
4. Limit "Now". It should hold only what the team is actively working on. If everything is in "Now", nothing is being prioritised.
5. Attach the reason and the measure. For each item, note why it is on the roadmap and which metric or customer signal will show it worked.
6. Prune "Later" on a schedule. Review it regularly and remove items the team no longer believes in. Removing an item is a decision, not a failure.
7. Review on a fixed cadence. Move items between columns at a regular review — monthly works for many teams — so the roadmap stays current without constant churn.

For deciding the order within each column, the criteria in Prioritizing 101 for PMs — business value, user impact, effort and urgency — apply unchanged.

What should each column contain?

Column	Level of detail	Typical content	Commitment
Now	High	Scoped problems, chosen solutions, active work	The team is doing this
Next	Medium	Validated problems, candidate solutions, open questions	Likely, subject to what "Now" teaches
Later	Low	Opportunities, themes, strategic bets	Direction only, no commitment

A useful sense check: if an item in "Later" has a detailed specification, either it belongs further left or the team has spent effort too early.

How does it fit with OKRs?

Quarterly OKRs and a now-next-later roadmap reinforce each other. The Objectives state what the team is trying to change this quarter; the "Now" column shows the work chosen to change it. When a quarter ends, the OKR review is a natural moment to move items between columns. The Complete Guide to OKRs for SaaS Teams covers the quarterly ritual in more detail.

Related reading

• Choosing a North Star Metric for a B2B Product — the metric that roadmap items should move.
• Jobs to Be Done for B2B Product Teams — framing roadmap items as customer problems.
• Prioritizing 101 for PMs — ordering work within each column.
• Product Strategy, Explained — the strategy a roadmap should express.
• All Product Roadmap & Prioritization articles — the growing cluster.