Now-Next-Later Roadmap: How to Plan an Early-Stage Product

The roadmap in a seed deck or a board pack usually looks certain. It promises a payments module in May and an AI assistant in Q3, months before anyone knows whether users want either. Each slipped date then costs the team credibility it will need at the next funding round or budget review.

The bigger risk sits upstream of the dates. CB Insights analysed 431 venture-backed startups that shut down since 2023 and found poor product-market fit in 43% of the 385 cases with identifiable causes. Running out of capital appeared more often. The analysts treat it as the point where the story ends. Weak fit, bad timing and unit economics explain why the money stopped.

A Now-Next-Later roadmap lets you plan an MVP without promising what you cannot know yet. Product teams have used Now-Next-Later roadmaps for more than a decade, and the format fits early-stage product development well. Below we compare it with a timeline roadmap, show what goes in each column and explain when the format is the wrong choice.

Key takeaways

• A Now-Next-Later roadmap trades release dates for three time horizons. The level of detail drops as certainty drops, so the plan stays honest about what the team knows.
• Early-stage products gain the most from the format. Most product ideas fail to move the metric they target. An MVP's scope also changes after first contact with users.
• Each column needs its own entry rule. The Now column holds committed, scoped work. The Next column holds problems with evidence behind them, while Later holds bets the team has not yet earned the right to plan.
• Use features in Now and themes in Next and Later. Attach a measurable outcome to every theme so it does not drift back into a feature list.
• Investors and boards still get dates. Commit to them for the Now column once discovery has shown what the solution is and what it costs.
• Fixed external deadlines call for a timeline. Typical cases are a regulatory change or a contracted pilot.

How does a Now-Next-Later roadmap differ from a timeline roadmap?

Both formats answer the question behind every product roadmap: what will the product team build, and in what order? A timeline roadmap adds a calendar. It places specific features against release dates and shows every bar on the chart with the same confidence.

The Now-Next-Later format swaps dates for three time horizons. Janna Bastow, a product manager who later co-founded ProdPad, says she sketched the first version in 2012 with the labels Current, Near Term and Future. She had watched release dates keep slipping in Jira-based plans.

An early customer renamed the columns Now, Next and Later, and the names stuck. Bastow has also acknowledged that a Thoughtworks post from the same year used similar wording independently.

Neither roadmap format is neutral. A timeline tells stakeholders that the plan is known. A Now-Next-Later roadmap tells them which parts are known and which are still bets.

Why does the format fit early-stage products?

An early product runs on assumptions about users and the problem itself. Each round of feedback can reorder the backlog. A plan built on fixed release dates goes stale as soon as the first user interviews come back.

Even mature product management teams struggle to predict which ideas will work. Ronny Kohavi and colleagues reported that in Microsoft's controlled experiments, only about one third of ideas improved the metric they were designed to improve. The figure dates from 2009 and comes from services with millions of users. An MVP team has far less data, and even less reason to trust its guesses.

Estimates break in a specific way too. A study of 5,392 IT projects found that cost overruns follow a power-law distribution, with many small misses and a fat tail of extreme ones. The sample covers IT projects in general and measures cost, so it says little about MVP schedules directly. It still shows why a date set months ahead carries more risk than a bell curve suggests.

The Now-Next-Later format matches planning effort to what the team actually knows. Detail goes into the Now column, where it pays off within weeks. The Later column stays rough on purpose, so nobody spends a sprint specifying features that research may cancel.

Dates still matter, though. Early-stage companies live by runway, and founders count it in months. A roadmap with no dates at all can look like a team avoiding accountability. The stakeholder section below shows how to bring dates back without losing flexibility.

What belongs in the Now, Next and Later columns?

Each column holds a different kind of item at its own level of detail. They do not need to be equal in size. What matters is an agreed rule for what earns a place in each one. Bastow makes the same point: a horizon with no shared definition turns into a vaguer timeline.

Now

The Now column holds work the team has committed to and is building at the moment. Items here are scoped, designed and broken into tasks. For an MVP, it usually covers the smallest flow that tests the core assumption: sign-up, one key action and basic analytics.

Keep the column short, because every extra item splits the same team's attention. A workable entry rule has three parts. The problem is validated, the solution is designed and the engineers have sized it.

Deciding what stays out is usually harder than deciding what goes in. Izabela Doniec, Product Manager at Miquido, uses one question to draw the line:

We assume the first release should be as small as possible. We cut everything that isn't essential for the core user journey, like extensive admin panels, advanced reporting or extra integrations. Where exactly the line falls depends on the product's context and on the time and budget for launch.My control question is simple: without this feature, can we still check whether the product solves a real problem? If the answer is yes, the feature can safely wait for Next or Later.

Izabela Doniec Product Manager at Miquido

Next

Problems in the Next column are the ones the team expects to pick up once current work ships. Each one has some evidence behind it, such as interview notes, support tickets or a pattern in usage data. The solution is still open and may change shape once the first release reaches users.

Later

Bigger bets and open questions live here. Typical examples are a second user segment, a marketplace model or an integration that only matters at scale. Write them as problems or opportunities, without specs or estimates. The column keeps the long-term product vision visible to investors and the team without turning it into a promise.

An example for a mobile MVP

Imagine an app that lets patients book physiotherapy sessions. Its first roadmap might look like this.

The table will change quickly. If the first release shows that patients book easily but rarely come back, reducing no-shows moves into Now. If bookings stall, nothing else moves forward until the core flow works.

Should your roadmap be theme-based or feature-based?

Any of the three columns can hold either features or themes. A feature-based roadmap lists specific features, like Apple Pay checkout or push reminders. A theme-based roadmap lists problems or goals, such as making the first payment faster or cutting no-shows.

Features are easier to read. Sales, marketing and engineering all know what to expect, and nobody has to translate a goal into a release. The cost is that the team commits to a solution before testing it.

Themes leave room for discovery, because the team can try several solutions to one problem and keep the one that works. Teresa Torres names the weak spot: marketing cannot plan a campaign around a theme, so theme roadmaps tend to slide back into feature lists. Early-stage teams feel the same pull once investors or launch partners ask what exactly ships.

A middle path works well for an MVP. Use features for current work, where the solution is already chosen, and themes in Next and Later. Attach one measurable outcome to each theme, written as a key result. Bastow describes the split in similar terms: the roadmap shows the plan, while OKRs carry the commitment.

How do you present the roadmap to stakeholders?

Investors, co-founders and early customers read the same plan with different questions in mind. Early users mostly want to know what's coming next. Funders model runway and hiring around milestones. A board will ask when revenue starts. A roadmap that refuses every date will not survive that meeting.

Marty Cagan of SVPG accepts the need for some dates. His argument dates from 2012 and still holds. The trouble starts when commitments are made too early, before the team knows whether it can deliver. He calls the alternative a high-integrity commitment, made after enough discovery to know the solution works and what it will cost.

At Miquido, MVP scoping talks often start with a request for a single launch date, even while the scope is still changing. Izabela Doniec handles it by splitting the commitment by horizon:

Instead of one date for the whole scope, I propose a date for what we know for sure: the Now horizon. Items in Next or Later stay without fixed dates. We show what they depend on and when we will estimate them again.Clients and investors get their predictability from a steady rhythm of decisions. In my experience as a project manager, a date promised against an unclear scope almost always becomes hostage to the next change.

Izabela Doniec Product Manager at Miquido

In practice, four habits make a Now-Next-Later roadmap work in front of a board. Each one fits into a regular investor update:

• Lead with the product strategy and its objective, then show the columns. Each item should point to the business goal it serves.
• Give dates where they are honest. Commit to a delivery window for the Now column and label Next and Later as sequence only.
• Show what changed and why. For every item that moved between columns since the last update, name the evidence behind the move.
• Keep one roadmap with several views. Investors see themes and key results, while the engineering team sees the scoped work behind Now.

Our MVP definition workshops follow a similar logic. The workshop narrows a long feature list to a first release, and its output typically includes an estimated schedule and quote for that scope. Next and Later then stay open while the first version meets real users.

One study on roadmapping points the same way. In interviews with 15 experts from 13 German companies, sharing or co-developing the roadmap with stakeholders was one of the most promising improvements. The sample is small, so treat it as a direction worth testing.

When should you not use Now-Next-Later?

The format assumes that scope is the main unknown and time is flexible. When an outside party fixes the date, horizons can hide risk instead of managing it. Four situations call for a different approach:

• A regulatory or contractual deadline, such as a compliance change with a legal effective date or a pilot already signed with a client.
• A launch tied to a fixed external event, such as a trade show or a partner's release.
• Heavy dependencies between teams or vendors, where a timeline shows the critical path far more clearly than three columns can.
• A team using the columns to avoid decisions, where nothing ever leaves Now and Later has become a parking lot.

In the first three cases, plan the fixed part on a timeline and keep Now-Next-Later for everything around it. You can run both views side by side for the same product. The fourth case is a discipline problem, and changing the format will not fix it.

The Now-Next-Later framework has limits too. Its value depends on clear entry rules and regular updates. A neglected Now-Next-Later roadmap misleads as much as a stale Gantt chart. Treat it as a planning habit that needs upkeep. Left alone, the roadmap stops showing any strategic direction.

Where should your first roadmap start?

Start with the Now column. If you cannot say which assumption your first release tests and what it will cost to build, the other two columns are guesswork.

You might be a founder or a team launching a new mobile product inside an established company. Either way, we can help you scope that first release in a product workshop. Tell us about your product and we will propose a workshop format that fits it.

Top AI innovations delivered monthly!

The administrator of your personal data is Miquido sp. z o.o. sp.k., with its ... registered office in Kraków at Zabłocie 43A, 30 - 701. We process the provided information in order to send you a newsletter. The basis for processing of your data is your consent and Miquido’s legitimate interest.You may withdraw your consent at any time by contacting us at marketing@miquido.com. You have the right to object, the right to access your data, the right to request rectification, deletion or restriction of data processing. For detailed information on the processing of your personal data, please see Privacy Policy.

Show more