How to Build a Product Roadmap for an Early Startup

A product roadmap for an early startup should be three columns, Now, Next and Later, under two or three written goals for the next six months. Now holds committed work with owners, Next holds problems you have evidence for, and Later holds bets. Skip dates beyond the current quarter. Review it monthly, link each Now item to a goal, and keep the backlog separate.

That is the format we use for every product we run, and the one we suggest to founders who ask. A dated Gantt chart looks more serious, but at the pre-product-market-fit stage every date past six weeks is a guess, and a roadmap full of guesses either gets ignored or becomes a promise you break. This post covers how to build the Now/Next/Later version in an afternoon, how to tie it to goals and ideas, and when to show it to customers and investors.

What a startup roadmap is for, and what it is not

A roadmap answers one question: what are we going to work on, in what order, and why? It is a communication tool first. The people reading it are your team, your investors, sometimes your customers, and the version of you three months from now who has forgotten why the order made sense.

It is not a backlog, a release plan or a list of promises. Those exist too, and confusing them is the most common reason early roadmaps fail. A roadmap with 140 items is a backlog with a nicer name. A roadmap with a date on every row is a release plan that nobody can keep.

Roadmap vs backlog vs release plan

	Roadmap	Backlog	Release or cycle plan
Question it answers	What problems, in what order, and why?	What specific work could we do?	What ships in the next few weeks?
Unit	Outcome or problem ("new teams get value in their first session")	Issue, story or task	Issues assigned to a time box
Typical size	8 to 15 items	Dozens to hundreds	10 to 30 issues
Time horizon	6 to 12 months, mostly undated	Open-ended	1 to 4 weeks
Audience	Team, investors, sometimes customers	The team	The team
Changes	Monthly	Daily	Each cycle

The three link together. A Now item on the roadmap becomes a project or epic; its issues sit in the backlog; some of those issues get pulled into this cycle. If you can follow a line from a cycle issue back to a roadmap item and from there to a goal, the system is working.

Why Now/Next/Later beats a dated Gantt chart early on

The Now/Next/Later format was created by Janna Bastow, co-founder of ProdPad, who describes its origin as a sketch first titled "Current / Near term / Future". Its core idea is to replace deadlines with time horizons, so that certainty decreases from left to right instead of being faked evenly across a timeline.

For a startup, that matches reality:

Now is the next four to six weeks. You know what you are building and who owns it.
Next is roughly the following quarter. You know the problem and have some evidence; the solution is open.
Later is everything beyond. You have a hypothesis and a reason to keep it visible.

A Gantt chart forces you to invent a start and end date for work you have not designed, for a customer you may not have yet. When the dates slip, and they will, the roadmap loses credibility and people stop reading it. Now/Next/Later lets you be precise about the near term and honest about the rest.

Dates still have a place. If you have a fixed external deadline, such as a conference, a regulatory date or a contract milestone, put it on the item as a constraint. Just do not invent dates where none exist.

How to build a Now/Next/Later roadmap in an afternoon

Set aside three hours with the founders and whoever leads product and engineering. You need a whiteboard or a shared page, last quarter's customer notes, and your metrics.

1. Write two or three outcomes for the next six months

Start with goals, not features. "Twenty paying teams using the product weekly by March" is an outcome. "Build Slack integration" is not. Two or three outcomes are enough; five means you have not chosen. If you already run OKRs, these are your objectives, and our guide to setting OKRs for a startup covers how to write them.

2. Collect ideas and evidence in one place

Pull every candidate into one list: feature requests, sales call notes, support tickets, things the team wants to fix. Next to each, write the evidence: how many customers asked, what it would move, what it costs you today. An idea with no evidence can still go on the roadmap, but in Later and labelled as a bet.

3. Sort into Now, Next and Later

Ask of each item: does it serve one of the outcomes, and how sure are we? Serves an outcome and we know the solution: Now. Serves an outcome but the solution is open: Next. Interesting but unproven: Later. Anything that serves no outcome goes off the roadmap, not into Later. Keep Now to what the team can actually start in the next six weeks, usually two to four items for a team of five.

4. Write each item as a problem, not a feature

"New users cannot find their first project" is better than "Redesign onboarding", because it leaves room for the cheapest fix and tells a reader why the item exists. Add one line on how you will know it worked.

5. Link Now items to goals and to work

Every Now item gets an owner, the outcome it serves, and a link to the project or epic that carries the work. This is the step that makes the roadmap a working tool rather than a slide. When someone asks why the team is building something, the answer is one click away.

Our product roadmap template has this structure ready to copy: outcomes at the top, Now/Next/Later columns, evidence and owner fields, and a review section.

Tying roadmap items to goals and ideas

The roadmap sits between two other lists, and keeping them connected is most of the work.

Ideas feed the roadmap. Keep a single ideas inbox where anyone can drop a suggestion with the evidence behind it. Each month, review it: promote the strongest ideas into Next, add new evidence to existing items, and archive the rest. An idea that collects evidence from five customers in two months has earned a conversation.

Goals judge the roadmap. Each Now item should move a key result. If you finish a Now item and the key result does not move, that is information: either the item was wrong or the measure was. Weekly or fortnightly check-ins on goals, a status and a sentence, keep this honest.

The glossary entry for product roadmap has the short definitions of each term if you need to share them with a new hire.

When to publish your roadmap, and to whom

Not everyone needs the same version.

Audience	What to show	How often
Team	Everything, including evidence, owners and Later bets	Always visible, reviewed monthly
Investors	Outcomes, Now and Next, what you learned since last update	Monthly or quarterly update
Customers	Now and selected Next items, as problems you are solving, no dates	When it changes, or on request
Prospects in a sales call	The one or two items relevant to them, framed as direction, not commitment	Case by case

Publishing to customers is worth doing once you have customers who ask. It shows the product is alive, it invites useful feedback, and it stops sales from making promises on the side. Two rules make it safe: show problems rather than features, and never put dates on anything past Now. GitHub's public roadmap is a useful model for the disclaimer: it states that items are not commitments, that dates may change, and that customers should not base purchasing decisions on it.

Before you have customers, keep it internal and share it with investors in your monthly update.

How often to review it

Weekly: nothing. The roadmap should not move in a week. Your cycle plan does that job.
Monthly: a 45-minute review. Move finished Now items out, promote from Next, add evidence from the ideas inbox, and check whether the outcomes still hold.
Quarterly: rewrite the outcomes. This is where you decide whether the next six months still point the same way.

If your roadmap changes every week, you are using it as a backlog. If it has not changed in three months, nobody is using it.

Tools for a startup roadmap

You do not need a dedicated tool to start. As of October 2026, these are the common options.

Option	Good for	Watch out for
A shared doc or page	The first year; anyone can edit; free in most tools	Goes stale unless it links to the actual work
ProdPad	Teams that want Now/Next/Later, idea management and feedback in one product tool	A separate tool to keep in sync with your tracker
Linear initiatives	Teams already on Linear; groups projects under company objectives with status and target dates	Organised around projects and dates rather than Now/Next/Later columns
Atrix	Small teams that want ideas, goals, roadmap and work in one workspace	No free plan; Now/Next/Later lives in a page rather than a dedicated board

Linear's initiatives documentation describes initiatives as groups of projects around a shared objective, each with a status, owner and target date, which works well as the Next and Now layers once you have projects.

Atrix is the tool we build, so here is what it does and does not do. Ideas have their own inbox where you add signals and a brief, and an idea can be promoted into a project when it is ready. Goals hold key results and check-ins, and some key results update from issues, deals or hiring. The roadmap shows initiatives and milestones with their status and issue counts. The Now/Next/Later columns themselves are a page built from the template, linked to those projects and goals, not a separate board view. There is no free plan, only a 7-day trial. The project management page covers how projects, cycles and the backlog fit underneath.

FAQ

What should a startup product roadmap include?

Two or three outcomes for the next six months, and a short list of problems sorted into Now, Next and Later. Each Now item needs an owner, the goal it serves and a link to the work. Add evidence for Next items and label Later items as bets.

How far ahead should an early startup roadmap go?

Six to twelve months, with only the current four to six weeks in detail. Beyond the current quarter, use horizons rather than dates. Most early-stage plans change too fast for a dated 12-month view to stay true.

What is the difference between a roadmap and a backlog?

A roadmap lists a handful of problems or outcomes in priority order and explains why. A backlog lists the specific issues and tasks that could deliver them. The roadmap changes monthly; the backlog changes daily.

Should a startup make its roadmap public?

Once you have customers who ask, usually yes, in a reduced form: Now and selected Next items, written as problems, with no dates beyond Now and a clear note that items are not commitments. Keep evidence and Later bets internal.

Is Now/Next/Later better than a timeline roadmap?

For early startups, usually. It is honest about uncertainty and does not invent dates. A timeline suits teams with fixed external deadlines or mature products with predictable delivery. You can add a hard date to a single item when one exists.

Next step

Copy the product roadmap template and fill in your outcomes first. If you want the roadmap, the ideas behind it and the work under it in one workspace, see Atrix for startups.

Sources

Checked in October 2026: ProdPad on the origin of Now-Next-Later, ProdPad features, GitHub public roadmap, Linear initiatives.

How to build a product roadmap for an early-stage startup: Now, Next, Later, tied to goals