Now Next Later Framework: A Product Roadmap Without Dates

Created by Janna Bastow - https://www.prodpad.com/blog/invented-now-next-later-roadmap/

Overview

The Now Next Later framework is a product roadmap format that replaces the calendar with three columns. Now holds the work the team is confident about and is actively doing. Next holds the problems it expects to pick up once the current work wraps up. Later holds the larger, fuzzier problems the team wants to keep in view without committing to them. Janna Bastow, co-founder of ProdPad, describes the idea in her post Why I Invented the Now-Next-Later Roadmap, which opens by saying the format "exists because timeline roadmaps aren't effective, simple as that." The question this page answers most often, how a Now Next Later roadmap differs from a quarterly roadmap, has its own section below.

Bastow tells the origin story twice. In the recent version she writes that at her previous companies product planning ran out of Jira and a release planner, which nobody outside the team could read, and that she "needed something a stakeholder could understand in about ten seconds." So she "dropped the dates and drew three columns: Now, Next, and Later." Her longer account, The Birth of the Modern Roadmap, adds the detail. She and fellow product manager Simon Cast were building the first version of ProdPad, which at the time had a timeline roadmap. Early users most wanted a way to shift many roadmap items at once, and asking why revealed that nobody was delivering to their timelines. At a cafe in Wandsworth, south London, "nearing the end of 2012," Cast sketched three columns on a napkin: Current, Near term and Future. Those were the first column names, and Now, Next and Later came later.

The model underneath the columns is a confidence gradient. In a podcast interview with Userlist, Bastow says the three buckets "were sort of taken from the cone of uncertainty," the software estimation idea that estimates are least reliable at the start of a piece of work. Steve McConnell's description of the Cone of Uncertainty puts the error at the initial concept stage at up to four times too high or too low, and says the cone narrows only as decisions remove variability. ProdPad's glossary therefore calls the columns confidence horizons: Now is high confidence, Next is moderate and Later is low. Items move toward Now because the team has learned enough, and the passing of time on its own does not move them.

The format changes what goes on the roadmap as well as how it is laid out. Bastow's advice is to prioritize problems rather than ideas: agree on the main problems and objectives first, then choose which solutions or experiments to try within each problem. Each card on the roadmap is an initiative framed as a problem to solve, and each initiative should connect to a business objective. Bastow calls initiatives the forgotten "middle child" of OKRs, the game plan that links an objective to its key results. Detail follows confidence. Now items are specified and broken down, Next items are sketched, and Later items are, in her words, "big boulder blocks that you can see in the distance."

The format is not anti-date. The ProdPad glossary says dates belong on the roadmap when they are real, externally driven or strategically important, such as an audit or a contractual commitment, and that overusing them turns the roadmap back into a timeline. Its rule of thumb is that "roadmaps communicate direction, while OKRs communicate commitment." Simon Cast makes the same split between a roadmap and a release plan: the roadmap shows direction, and the release plan puts finished work on a timeline so marketing, sales and support can coordinate the launch.

Practitioners outside ProdPad have adopted and credited the format. Scrum.org introduces Bastow as the inventor of the Now/Next/Later roadmap, and a Mind the Product event recap refers to "the Now, Next, Later format she introduced." Teresa Torres writes that she is a fan of Bastow's Now Next Later roadmaps and uses the format for her own Product Talk roadmap. Marty Cagan's alternative to roadmaps makes a compatible argument from a different starting point: roadmaps exist to focus teams on the most valuable work and to track the date commitments a business really needs, and any replacement has to serve both purposes.

The framework suits teams whose priorities change as they learn, which covers most software product teams doing continuous discovery. It works less well when most of the work is bound to fixed external dates or when the organization cannot yet accept a roadmap without dates. The skills listed below cover each part of the practice: sorting items into horizons, setting graduation criteria, building a template, running reprioritization reviews, adapting the format for SaaS, communicating it to stakeholders and choosing between it and a timeline roadmap.

Core Principles

Confidence Sets the Column

An item's column reflects how much the team knows about it. Importance and urgency are separate questions. ProdPad's glossary puts it plainly: "Now, Next and Later are confidence horizons, not time horizons" (Confidence horizons). A strategically important bet can sit in Later because the problem has not been validated, while a small, well-understood fix sits in Now. Keeping importance and confidence apart is what lets the roadmap stay honest when a stakeholder argues that their item matters too much to sit in Later.

Problems on the Roadmap, Solutions Underneath

Each roadmap item names a problem or opportunity, and candidate solutions sit beneath it as ideas or experiments. Bastow's advice is to prioritize at the problem level first and only then choose which ideas or experiments to try within each problem (Prioritize Problems, Not Ideas). A roadmap of named features locks in solutions before discovery has tested them. When the headings on your board are still feature names, the conversion is not finished.

Detail Decreases With Distance

Now items are specified and broken into deliverable pieces, Next items are broken down less finely, and Later items stay broad. Bastow's reason is economy: "It doesn't make sense to go into detail about big, far-off ideas" (Why I Invented It), just as it makes no sense to give them deadlines. Detailed specs for Later items go stale before the team reaches them, and they also signal a readiness the team does not have. If a Later item has a full spec, either it belongs further left or the spec was premature.

Every Initiative Ties to an Objective

Bastow lists "ties back to objectives" as one of the format's main benefits, and ProdPad's conversion guide suggests questioning whether an initiative that cannot be linked to an objective belongs on the roadmap at all (Convert a Timeline Roadmap). The link does two jobs. It explains why each item is there, and it gives leaders a way to check progress against outcomes rather than dates. If every initiative serving a year-end target sits in Later, the gap is visible without a status meeting.

Dates Only Where They Are Real

The framework removes dates from work that is not certain enough to commit to and keeps them where a real obligation exists. Examples in ProdPad's guidance include a regulatory deadline, a contractual commitment and a launch tied to a market window (Convert a Timeline Roadmap). Bastow's advice for dated work is to plan it properly, with buffer, and to clear other work out of its way if needed (Mind the Product podcast). Stripping every date, including genuine ones, is its own failure mode.

Evidence Moves Work Forward

Items graduate from Later to Next to Now because discovery has raised the team's confidence. Seniority or persistence should not be what moves them. ProdPad's guidance is blunt: "If confidence hasn't increased, the Initiative shouldn't move left" (Convert a Timeline Roadmap). The same logic applies in reverse, so an item whose evidence weakens moves back or leaves the roadmap. Writing down what would have to be true for each move is how teams keep this principle from depending on one person's judgment.

The Roadmap Is a Communication Tool

Bastow calls a roadmap "a prototype for your strategy," something to put in front of people to gather feedback before code is written (Mind the Product podcast). That makes readability a requirement. The same board should work for executives, engineers, sales and, in a filtered version, customers. A roadmap that only the product team can interpret has lost most of its value.

Steps

1. Anchor on Vision and Objectives Start from the product vision and a small set of current objectives or OKRs before touching the backlog. ProdPad's conversion guide puts these first because every later placement decision refers back to them. If objectives are missing or vague, fix that first, since a Now Next Later roadmap without objectives has no basis for ordering. Keep the objectives visible throughout the session. Each one needs a label or color so initiatives can be tagged later.

2. Turn Features Into Problems Gather everything competing for the roadmap: the current plan, feature requests, strategic bets and technical work. Group the items by the customer or business problem each one addresses, an exercise the conversion guide runs as affinity mapping. Write each group as a short problem statement, often phrased as a question such as "How can we help our customers collaborate with other departments?" Keep the problem broader than any single solution, and move the specific features underneath as candidate ideas.

3. Link Each Initiative to an Objective Tag every initiative with the objective or objectives it serves. An initiative can serve more than one. Initiatives that fit no objective are candidates for removal, or evidence that an objective is missing. This tagging is what later lets you filter the roadmap by goal and answer "are we on track for this target?" without a separate report.

4. Define the Horizons for Your Team Write down what Now, Next and Later mean in your context before placing anything. ProdPad's glossary describes Now as validated work in motion, Next as problems being validated with solution exploration under way, and Later as strategic bets still under consideration. You may rename the columns; the conversion guide lists alternatives such as Doing, Discovering and Dreaming. Define the columns by confidence, and agree whether any real dates will appear and where they attach.

5. Place Initiatives by Confidence Put each initiative in the column that matches the evidence behind it. A problem with a validated solution and understood effort goes in Now. A validated problem with open solutions goes in Next, and an unexplored bet goes in Later. Keep Now small: ProdPad's glossary calls a long Now column "a sign of weak prioritization" and says the whole roadmap should fit "in a scroll or two." Then order the items within each column.

6. Scale Detail to the Horizon Add scope, owner and success measures to Now items. Give Next items a clear problem statement and the open questions discovery must answer. Leave Later items as a sentence or two. Note dependencies as a short remark on the initiative rather than drawing them as a chart, as Bastow suggests on the Mind the Product podcast.

7. Review and Reprioritize Continuously Review the roadmap every planning cycle and whenever new evidence shifts confidence in an item, which is ProdPad's own recommendation. In each review, check what finished, what is blocked, what gained or lost evidence and what new problems arrived. Move items in both directions and record why. The conversion guide warns that a roadmap which has not changed in a quarter usually means discovery has stalled.

8. Share It With Every Audience Present the board with a short explanation of what each column means, because readers used to timelines will read columns as dates. Tailor the view: leaders need the objective links, engineering needs Now and Next detail, and customers need a filtered, problem-level version. Separate the roadmap from the release plan so launch dates live where they belong. Expect the stakeholder transition to take longer than building the board.

Now Next Later vs Quarterly Roadmap

A quarterly roadmap and a Now Next Later roadmap can look alike, since both have a few wide columns and no exact dates. Bastow calls the quarterly roadmap "the friendliest trap" because "a quarterly roadmap organizes work by when" while Now Next Later orders problems by confidence (Why Time-Based Roadmaps Are Promises You Can't Keep). The same post cites the 2026 State of B2B Product Management survey as finding that 41% of teams use quarterly time-based roadmaps and that only 27% have moved to Now-Next-Later. The table compares the two formats with a feature timeline and an outcome-based roadmap.

Many teams run both. Torres suggests not fighting "the ideological war" with leaders who want dates, and instead introducing outcomes gradually into the roadmap they already use (Product Talk). The GO Product Roadmap, another outcome-based format covered at tryhamster.com/methods/go-product-roadmap, is a closer relative than the quarterly plan. The step-by-step choice between formats is covered in Now Next Later vs Timeline Roadmap: Choosing a Format.

When to Use

• When roadmap conversations keep turning into arguments about dates. The format moves the discussion to which problems matter and how much is known about each, which is where the product decision actually sits.
• When your team runs discovery and the evidence regularly changes what gets built. Columns defined by confidence absorb those changes without a formal replan, while a timeline has to be redrawn.
• When one roadmap must serve executives, engineers, sales and customers. The same board can be filtered by objective or by audience instead of maintaining separate decks that drift apart.
• When you want a public or customer-facing roadmap. ProdPad recommends a horizon format for public roadmaps because it communicates direction without promising dates or exact features (The Public Roadmap).
• When you already set OKRs and need a view of the initiatives behind them. The format places initiatives between objectives and delivery, which is the gap OKRs alone leave open.

When Not to Use

• When most of the work is bound to fixed external dates, such as contract deliverables or a hardware launch with partners. A timeline or release plan gives those dates the planning attention they need; Now Next Later can still frame the discovery work around them.
• When the main need is coordinating dependencies and shared resources across many teams on a critical path. That is program management, and a dependency-mapped plan does it better than three columns.
• When leadership evaluates the team on hitting feature dates and there is no appetite to change that yet. Introducing the format without buy-in risks a Now Next Later board for the team and a separate timeline for executives, which doubles the work.
• When the backlog is small, the direction is clear and one team decides everything. An ordered list is quicker and says the same thing.