Building a Roadmap: Now-Next-Later and Outcome Roadmaps Instead of Feature Timelines

Version note: This post is conceptual; Now-Next-Later follows ProdPad's (Janna Bastow) articles, and appetite and the betting table follow Basecamp's "Shape Up" (Ryan Singer, 2019).

Guess First

November 2026. Bookstore's sales director wants a roadmap for the first half of 2027: "Which feature ships in which month, one slide is enough. I'll show it in our annual meetings with publishers." Looking at last year's roadmap, the team sees this: it had nine features spread month by month; three shipped in the stated month, four slipped by a month or two, and two were never built because priorities changed during the year.

Would the result be different if this year's slide used the same format? What does the sales director really need: dates, or the ability to tell publishers "this year we'll improve these things for our customers"? And consider this: was it a bad thing that last year's two features were never built?

Vision, Strategy, Roadmap, Backlog

A roadmap doesn't mean much on its own; it sits in the middle of a hierarchy. At the top is the product vision: what the product wants to be for customers in a few years. For Bookstore, a sentence like "the place where readers most easily find the book they're looking for and buy it most reliably." Below it comes strategy: which path leads to that vision, which customer segment and which problem get priority. "Next year we focus on turning first-time guest customers into loyal customers" is a strategy sentence.

The roadmap is a communication tool that shows how the strategy will move forward over time: which problems will be tackled first and which later. At the bottom sits the backlog: the concrete items the team will work on in the coming weeks. In Scrum this is the Product Backlog; its mechanics are the subject of the Scrum series.

In this hierarchy each level is more concrete and shorter-lived than the one above. A vision lives for years, a strategy for a few quarters, a roadmap for a few months, a backlog for a few weeks. Most problems come from forcing the roadmap to be as concrete as the backlog.

The Problems with a Dated Feature Roadmap

The format the sales director asked for is the one most companies know. Here is the Bookstore team's first draft:

This table has three problems. First, every row is an output and none says why it's being done; when subscriptions ship in June, you can't tell from this table whether anything improved. Second, the dates were given at the moment of least information: an estimate in November for a June feature is, in the language of the Monte Carlo post, a forecast without a stated probability, and most likely below 50%. Third, the table reads like a promise. The publisher expects subscriptions in June; even if discovery in March shows subscriptions aren't a good idea, the team builds them because they were promised.

Seen this way, two of last year's nine features never being built may not be a failure but a learning. The real question is whether not building them was a decision or a slip, and how that was explained to stakeholders.

Now-Next-Later

Janna Bastow, co-founder of ProdPad, describes developing the Now-Next-Later format in the early 2010s; the first version was sketched in 2012 with the headings "Current / Near Term / Future," and the Now-Next-Later names were later suggested by one of their customers. The idea is simple: columns of uncertainty instead of columns of dates.

Now is the work the team is actively doing; it has the highest certainty and is broken into detailed, well-defined pieces. Next is the work that comes after Now is done; it's less certain, less detailed and may change depending on what is learned from Now. Later holds larger, fuzzier problems the team doesn't want to lose sight of; certainty is lowest and they haven't been broken into solutions yet.

The strength of this format is that it doesn't hide uncertainty. A dated roadmap shows a June feature as certain as a January one; Now-Next-Later says openly that work for June is still a problem statement.

Outcome Roadmap: Make the Rows Problems

Now-Next-Later's columns solve time; what the rows are is a separate decision. In an outcome roadmap each row is not a feature but a problem or an outcome. Here is Bookstore's second draft for the first half of 2027:

All the features from the first draft are still in this table: guest checkout in Now, saved cards and recommendations among Next's candidate solutions, the mobile app and subscriptions in Later. The difference is that each sits under a problem, as a candidate solution. The mobile app is no longer a promise but one possible solution to "the shopping experience on mobile"; if discovery shows a better mobile web is enough, the roadmap doesn't change, only the list of candidate solutions does.

The payment SDK row is deliberately not an outcome but an obligation. An outcome roadmap doesn't ignore fixed-date work; it marks it clearly. In the previous post we saw why CD3 (Cost of Delay Divided by Duration) put this work at the top.

How to Communicate It to Stakeholders

When the sales director sees this table, the first question will be "so when?" That question is legitimate and shouldn't go unanswered. Three principles help.

The first is giving a confidence range. Dates can be given for work in Now, but with a probability: as in the Kanban series' Monte Carlo post, "we forecast guest checkout will ship by the end of February with 85% probability." For Next, a quarter-level range is honest; for Later, no date at all.

The second is saying clearly that Later is not a promise. One sentence under the roadmap is enough: "The work in the Now column is a commitment; Next and Later show our priorities with what we know today and will change as we learn." A slide shown to a publisher should carry this sentence.

The third is separating the roadmap from the release plan. The roadmap describes which problems are tackled in which order; a release plan describes when a specific release ships and with what content. If the sales director has a fixed-date need like the 27 November campaign, it's met with a release plan. Version numbering and release processes are the subject of the upcoming Versioning and Release Management series.

Shape Up: Appetite and the Betting Table

There is another method that looks at roadmaps from a completely different angle: "Shape Up," Basecamp's book written by Ryan Singer. Shape Up doesn't ask "how long will this take?"; it asks "how much time are we willing to spend on this?" That is called appetite. Appetite is not an estimate but a budget: "we have a six-week appetite for guest checkout" means shaping the best guest checkout that can ship in six weeks; scope fits the time, not the other way around.

In Shape Up, work moves in six-week cycles with two-week cool-down periods in between. Before each cycle a betting table meets: shaped pitches are put on the table and a decision is made on which to "bet" on for the next cycle. A pitch that isn't bet on doesn't automatically roll over to the next cycle; if it's important, it comes up again. If a project doesn't finish by the end of the cycle, it isn't extended by default; the book calls this a circuit breaker.

Shape Up doesn't suit every team and doesn't map one-to-one onto Scrum or Kanban. But two of its ideas are valuable for any roadmap. Appetite turns the "how long will this take?" argument into "how much is this worth to us?" And not hoarding a backlog, that is, not automatically carrying unbet ideas into the next period, keeps the roadmap from swelling with stale ideas every period.

In Production

Run the roadmap as a rhythm, not a document. The Now-Next-Later table should be reviewed once a month or at the start of every quarter: finished items leave Now, a row moves from Next to Now, one from Later to Next. Note in a sentence or two what changed and why with every update; stakeholders react less to change itself than to unexplained change.

Keep the roadmap's versions. The difference between the roadmap shown to the sales director in November and the one in March is a record of what the team learned. A sentence like "we removed the mobile app from Later because discovery showed 80% of mobile users were happy shopping on the web" turns a feature not being built from a failure into a decision.

Don't leave the team unaware of the roadmap. If developers only see the roadmap through the backlog items that reach them, they can't know how a big change in Later (mobile, subscriptions) would affect today's architecture decisions. Reading the roadmap together with the team at the Sprint Review or in a monthly meeting brings feasibility questions in early.

Common Pitfalls

The first pitfall is turning Now-Next-Later back into a date table. A table mapped as "Now = January, Next = February-March, Later = April-June" is a dated roadmap with renamed columns.

The second is presenting the Later column as a promise. If the slide shown to the publisher says "Later: Subscription" with no caveat underneath, the publisher will expect subscriptions. Writing the rows in Later as problems reduces that risk.

The third is detailing the roadmap like a backlog. If you see story-level items on your roadmap, you've mixed up two different tools. The roadmap carries problems and order; the backlog carries the work itself.

The fourth is leaving technical work off the roadmap. If obligations like the payment SDK aren't visible on the roadmap, stakeholders can't understand why the team's capacity shrank. Making them visible is easier than explaining them.

A Small Experiment

★☆☆ Open your team's latest roadmap and mark whether each row is an output or an outcome. Rewrite one output row with the problem behind it.

★★☆ Prepare a Now-Next-Later table for your product: at most three rows per column, each row with an outcome, a measure and candidate solutions. What data would you need to give an 85%-probability date for one of the rows in Now?

★★★ Set an appetite for the biggest piece of work in the coming period: "we're willing to spend at most this many weeks on it." Then shape, on one page, the smallest solution that fits that time. What did you consciously leave out?

Every row on the roadmap carries an outcome and a measure. In the next post we focus on those measures themselves: we'll build a North Star metric, the HEART (Happiness, Engagement, Adoption, Retention, Task success) framework, AARRR (Acquisition, Activation, Retention, Referral, Revenue) and a metric tree for Bookstore, along with guardrail metrics.