8 Steps to Convert Your Timeline Roadmap to a Now-Next-Later
Already convinced timelines aren’t working? Here’s how to convert your existing roadmap and adopt confidence-based planing in a single workshop.
In this guide you’ll:
- ✅ Keep the useful thinking from your timeline roadmap
- ✅ Replace feature lists with problem-focused Initiatives
- ✅ Organize work using confidence horizons
- ✅ Link everything to OKRs
- ✅ Bring stakeholders with you
Perfect for:
Product Managers, Heads of Product, Product Leaders
A lot of work went into your timeline roadmap. The good news is you don’t have to throw it away. Work through the eight steps below and you’ll have a working Now-Next-Later roadmap by the end of the workshop.
💡 Workshop tip
Don’t do this alone. The best Now-Next-Later migrations happen with Product, Design, Engineering and key commercial stakeholders in the room together.
Signs your roadmap is too timeline-driven
Before the how, a quick diagnostic. Some teams know their timeline roadmap is hurting them. Others have lived with the symptoms so long they read as normal. If several of these sound familiar, your roadmap is doing more harm than good.
Your roadmap might be too timeline-driven if:
- Dates slip every quarter. The same items keep sliding right, and re-planning has become a recurring tax rather than a rare event.
- Sales treats roadmap items as promises. Anything on the roadmap gets sold as committed, which means a planning artifact has quietly become a contract.
- Teams pad their estimates. Developers add buffer to protect themselves, the roadmap bloats to absorb it, and everyone moves slower so the dates feel safe.
- Discovery gets skipped to hit a date. Validation work is the first thing cut when a deadline looms, so you ship on time and find out later you built the wrong thing.
- Leadership asks “when?” far more than “why?” The conversation centers on delivery dates instead of the problems you’re solving and the outcomes you’re chasing.
None of these are people problems. They’re what a date-shaped planning tool does to the system around it. The roadmap rewards certainty theater, so the team performs certainty theater. Changing the format changes the behavior.
Recognize three or more of these and still need to convince the people around you? Read 5 Ways to Convince Your Boss Product Roadmaps Don’t Need Deadlines.
The 8 steps to converting your timeline roadmap to a Now-Next-Later
- Start with Vision so your Now-Next-Later roadmap has a spine
- Check Objectives/OKRs to anchor outcomes
- Translate features into problems to solve
- Create Initiatives and Ideas the Now-Next-Later way
- Map Initiatives to Objective
- Define your Now, Next, and Later horizons
- Place Initiatives by confidence, not calendar dates
- Review your Now-Next-Later roadmap and cut waste
Step 1. Start with Vision so your Now-Next-Later roadmap has a spine
By the end of this step: You’ll have a clear Product Vision that gives every roadmap decision a shared direction and purpose.
Before you pick up your timeline roadmap and start the transition, get your foundations in place. The outcome-focused nature of the Now-Next-Later format means it’s tied directly to the value your product drives for customers and the business. Any good Now-Next-Later roadmap is grounded in a strong Product Vision.
We won’t cover the full craft of writing a compelling Product Vision here. If you don’t have one, or yours could use a refresh, our Product Vision Template gives you the structure, and our collection of good Product Vision examples helps spark ideas.
If you do have a Vision in place, check that it:
- is inspiring and motivating
- includes details on your buyers and users
- covers your value proposition and links back to the desired outcomes
- is unambiguous and not open to multiple interpretations
The Product Vision is the beating heart of your product strategy. It’s the foundation of your roadmap and it shapes the daily decisions your team makes.
Step 2. Check Objectives and OKRs to anchor outcomes
By the end of this step: You’ll have a small set of Objectives or OKRs that every roadmap Initiative can be linked back to.
The second pillar of your foundation is your Product Objectives. Whatever goal-setting framework you favor (OKRs, a Strategy Map, HEART, Balanced Scorecard, or anything else), you should have a set of things you’re trying to achieve as a product and a business. You may not have drilled down to specific measurable targets yet, but you should have three to five core Objectives at minimum.
If you’re light here, work through our course on how to create Objectives and Key Results. OKRs are our preferred goal framework at ProdPad and the one that aligns most closely with the Now-Next-Later approach.
Gather your Objectives and have them to hand as you work through the next steps.
Step 3. Translate features into problems to solve
By the end of this step: You’ll have a roadmap organized around customer and business problems instead of a list of features.
If you’re working with a timeline roadmap today, the items on it are almost certainly specific feature Ideas rather than broader themes, areas of focus, or problems to solve.
Structuring a roadmap as a list of features creates an output mindset. That matters because output isn’t a measure of success. You need to measure outcomes and have the confidence that you’ve solved the problem you set out to solve. A roadmap built on locked features quietly turns you into a feature factory, shipping things rather than moving numbers.
A Now-Next-Later roadmap is never a stack of feature cards. It’s structured around a two-level hierarchy: Roadmap Initiatives and their corresponding Ideas. Initiatives describe the problem to solve, the customer or business value you’re chasing. Ideas are the possible ways you could solve that problem. Depending on where an Initiative sits, those Ideas are either possibilities still to be researched and explored, or Ideas you’ve run discovery on, validated, and are ready to proceed with.
Here’s how to make the shift. Get a whiteboard, physical or virtual, and run an Affinity Mapping exercise.
First, make a sticky note for every item on your timeline roadmap and put them all on the board. Gather your team (or do this solo if you prefer) and group the notes by theme. Resist the temptation to group by product area or user persona. Those groupings aren’t outcome-focused, and outcome focus is the whole point.
Group your feature notes by the problem each one is trying to solve. That problem might be a customer problem or a business problem. For example, you might have a cluster of features that all help customers share content more easily, or several attempts to improve collaboration. In that case your problem to solve might be “How can we help customers collaborate more effectively?”
Look at the value each feature would bring if it succeeded, for the customer or the business. Frame that value as the solution to a broader problem, then write the problem as a short sentence. Questions work well, particularly for items headed to your Later column. That sentence becomes your theme, your problem-to-solve title.
Keep the problem broader than any single solution. If you have a Slack integration on a sticky note, don’t make the problem “build a Slack integration.” Keep it wide, something like “How can we help our customers collaborate with other departments?” You’ll get more specific later.
Before and after: features become problems
This is the transformation that trips people up, so here’s a concrete example. On the left, a typical timeline roadmap. On the right, the same work reframed as Now-Next-Later.
Before (timeline roadmap):
| Q2 | Q3 |
|---|---|
| Slack integration | Teams integration |
| Export to CSV | Scheduled report emails |
| Onboarding setup wizard |
After (Now-Next-Later roadmap):
| Now | Next | Later |
|---|---|---|
| Improve cross-team collaboration (Ideas: Slack integration, Teams integration) | Increase reporting flexibility (Ideas: Export to CSV, Scheduled report emails) | Reduce onboarding friction (Idea: setup wizard, pending discovery) |
The features didn’t vanish. They moved down a level, from roadmap headline to candidate Idea inside a problem-shaped Initiative. The roadmap now communicates intent and outcome, and the specific solutions stay flexible until you’ve validated them. Notice too that the setup wizard was scheduled on the old timeline but lands in Later, because the team hasn’t validated that a wizard is the right fix. That’s confidence-based placement at work, and Step 7 covers it in full.
🚩 Checkpoint
If your roadmap headings are still feature names, you’re not finished with this step.
Step 4. Create Initiatives and Ideas the Now-Next-Later way
By the end of this step: You’ll have a set of outcome-focused Initiatives, each containing the Ideas that could solve the problem.
The groupings from your Affinity Mapping session become your Roadmap Initiatives, with their related Ideas nested underneath. A little more work turns a board of stickies into a list of Initiatives ready to map onto your roadmap.
Start with any groupings that hold a lot of feature notes. If none of your groups has more than four or five features, skip ahead to the next step. If one or more groups has five or more features in it, spend some time breaking those down.
A large pile of features all aimed at one problem usually means the problem is too broad. Take this grouping:
“How can we help our customers increase collaboration with other departments?”
If you have a dozen collaboration features under that heading, narrow it. You could break it down by solution type:
“How can we help our customers collaborate with other departments through integrations?”
Then the integration-related Ideas sit underneath, things like “Teams integration” or “Enhance our Slack integration to pull in discussion threads.”
Or break it down by the department being served:
“How can we help customers collaborate more efficiently with their sales teams?”
Then “Automated report generation for sales updates” and “Question submission by email” sit under that more specific problem.
Once your problems are broken down to the right level, you’ve reframed a list of specific features into a set of broader Initiatives. The feature items inside each grouping are now your Ideas: the candidate ways to solve each problem.
Want to compare your roadmap to a finished one? Explore real Now-Next-Later roadmaps complete with linked Ideas, Initiatives, and OKRs.
Step 5. Map Initiatives to Objectives
By the end of this step: Every Initiative will be connected to at least one strategic Objective, making its purpose and value clear.
The last step in finalizing your Initiatives is mapping each one back to your Product Objectives. This is essential to the format. The Now-Next-Later roadmap requires that everything on it both solves a problem and contributes to a Product Objective.
Go back to the core Objectives you gathered in Step 2 (the ones that align with your wider business goals) and give each one a color, icon, or flag. Then work through your Initiative groupings one by one and tag each with the Objective or Objectives it helps achieve. An Initiative can serve more than one Objective.
Now you have a set of agile Initiatives that are outcome-focused and tied to your Objectives. Next comes the timing.
💡 Workshop tip
If an Initiative can’t be linked to an Objective, question whether it belongs on the roadmap at all.
Step 6. Define your Now, Next, and Later horizons
By the end of this step: You’ll have shared definitions for each horizon so everyone understands what Now, Next, and Later actually mean.
Define your time horizons before you place anything. This matters because “now,” “next,” and “later” mean different things to different people, and you need to set explicit expectations with your stakeholders.
The goal isn’t to define time. It’s to define confidence. That’s the essence of confidence-based planning.
When you’re weaning a team off a timeline roadmap, exact parameters like fiscal quarters can help as a bridge. You don’t have to keep the words Now, Next, and Later either. You can adopt the process and principles without the exact terms.
Even inside ProdPad, customers customize their column headings. You might prefer “This quarter,” “Next quarter,” and “The future.”
Other great time horizon titles we’ve seen:
Current – Near Term – Future
(this is what Simon and I originally called the Now-Next-Later)
Under active development — To be implemented next — Suggested future projects
Doing – Discovering – Dreaming
The goal isn’t to define time. It’s to define confidence. That’s the essence of confidence-based planning.
Once you’ve defined what each horizon means, you can roughly map the periods on your old timeline to these horizons.
Step 7. Place Initiatives by confidence, not calendar dates
By the end of this step: You’ll have your Now-Next-Later roadmap organized by confidence and readiness instead of speculative delivery dates.
Now you have Initiatives with their Ideas and a set of well-defined horizons. Combine the two and distribute your Initiatives across the roadmap.
Now–Next–Later is really about confidence horizons. It organizes work by how much you actually know, not by when you hope to do it.
Start by roughly preserving the priority order from your old timeline, so you’re not detonating every existing stakeholder expectation at once. For each Initiative, look at its Ideas, find the one that sat soonest on your old timeline, and place the whole Initiative in the horizon that corresponds to that date.
Then sense-check every placement against confidence. This is the real work. For each Idea, ask: how validated is it? How confident are you that it solves the problem? Placement on a Now-Next-Later roadmap correlates to the confidence you’ve reached for the Ideas inside each Initiative, and that confidence reflects the discovery work you’ve done.
Broadly, that means:
- Now: validated, high confidence, ready to build.
- Next: validated problem, solution still being explored.
- Later: problem area that still needs discovery.
💡 Workshop tip
Place Initiatives according to confidence, not chronology. If confidence hasn’t increased, the Initiative shouldn’t move left.
Notice that an Initiative’s title often shifts as it moves from right to left. As Initiatives mature through your process, you narrow the problem and get more specific, and it helps to update the titles and descriptions to reflect that.
So look again. Is there an Initiative sitting in Now with Ideas that haven’t been validated yet? Move it back to Next to make room for the discovery work. Watch out for genuine hard deadlines, though. If something has to ship by a fixed date, you don’t have the freedom to move it.
Examples of hard deadlines:
- A race to market where launching before a competitor is strategically important.
- A time-sensitive feature relevant only at a particular point in the year.
- A legal or regulatory obligation with an external deadline that puts the business at risk if missed.
- A commercial commitment, such as a major deal that depends on a specific capability being live.
When you move something and there’s no hard time sensitivity holding it, note the change. You’ll want a list of where you’ve diverged from the old priority order so you can explain it to stakeholders. You have a solid reason: moving an Idea back buys time to validate it, so you spend expensive development effort on work that stands a better chance of driving the results that matter.
A note on release, delivery, and sprint planning
What you’re building here is a Product Roadmap. It is not a Release Plan, a Delivery Plan, or a Sprint Backlog. Those are different tools.
A roadmap is a strategic document that communicates direction, the problems you’re prioritizing, and how you’ll move your Objectives. Release and delivery plans are tactical project-management tools for organizing known tasks: features to build, ship, and launch. That’s where exact dates and detailed deliverables belong. Once an Idea on your roadmap is fully validated, specced, and ready for development, push the ticket into your delivery tool and work it into sprint planning.
ProdPad runs two-way syncs with tools like Jira, Trello, Linear and Azure DevOps, so the move from roadmap to delivery plan stays smooth and your delivery tool stays clean.
🚩 Checkpoint
If an Initiative moves left only because of a deadline and not because confidence has increased, you probably haven’t finished the discovery work.
Step 8. Review your Now-Next-Later roadmap and cut waste
By the end of this step: You’ll have a focused roadmap containing only the highest-value Initiatives, ready to communicate with stakeholders.
Most of your Initiatives are placed roughly where they sat on the old timeline. Now sense-check that placement, with everything reframed around problems and tied to Objectives.
Step back and look at the whole thing. Are these the most important problems to solve? Did any Initiative resist being mapped to an Objective? If so, question whether it belongs on the roadmap at all.
At the Initiative level, look at the Ideas again. Now that you’ve grouped features under problems, you may find several Ideas all chasing the same outcome. You rarely need all of them. If one Idea is likely to prove far more effective than the rest, consider cutting the others so you’re spending your resources well. Solve the problem with one feature instead of three, measure it, then move on to the next problem.
This is one of the ways the format helps you solve more problems in less time. You stay focused on the outcome rather than feeding a feature factory, and you deliver more value, faster.
Common migration mistakes
Most failed Now-Next-Later migrations fail in the same handful of ways. Watch for these.
Mistake 1: Renaming your quarters
The most common one. A team relabels Q1, Q2, and Q3 as Now, Next, and Later and calls it done. A timeline with new headings is still a timeline. If your three columns map cleanly onto three fixed time periods, you’ve changed the words and kept the date theater. The horizons describe confidence and proximity, not a calendar.
Mistake 2: Keeping feature commitments
Now-Next-Later describes problems and outcomes. If your Initiatives are really just locked solutions wearing a problem-shaped label (“Now: build the Slack integration”), you’ve kept the commitment and lost the flexibility. The point of the format is that the solution stays open until discovery closes it.
Mistake 3: Overloading the Now column
Teams often dump everything urgent into Now, and the column becomes a backlog. Now is for validated work actively in motion with committed resources. If your Now column has fifteen Initiatives in it, most of them belong in Next, and you’ve recreated the overcommitted plan you were trying to escape.
Mistake 4: Removing every date
The opposite failure. Some teams hear “no timeline” and strip out all dates, including the genuine commitments. Now-Next-Later doesn’t ban dates. It removes them from work that isn’t certain enough to commit to, and keeps them where a real obligation exists. Throwing out the regulatory deadline along with the speculative ones helps no one.
How to bring stakeholders with you
This is the part most migration guides skip, and it’s where most migrations actually live or die. The format change is a half-day workshop. The stakeholder change takes longer, because you’re asking people who relied on dates to trust a different kind of certainty.
The reframe that makes it work: the commitment lives in the OKR, not in the roadmap timeline. When a stakeholder needs a date, you don’t put it on every line item. You capture the business intent as an Objective with measurable Key Results, then link the contributing Initiatives to it. The roadmap shows the plan to hit the number, laid out by confidence. The OKR carries the commitment. That separation answers the “but when?” objection without dragging you back into a Gantt chart.
Here’s how that plays out against the three objections you’ll hear most.
“But Sales needs dates”
Sales needs to sell with confidence, which isn’t the same as needing a date on every feature. Give them confidence levels and direction instead of speculative commitments. A published roadmap view shows sales which Initiatives support a given target and where each one sits on the horizon. They can speak to direction honestly without promising a ship date the team can’t stand behind. The commitment they can point to lives in the Objective, where it belongs.
“But Leadership wants predictability”
Replace date certainty with strategic certainty. Leadership wants to know you have a credible plan to hit the numbers the business is counting on. The OKR-to-roadmap connection gives them exactly that: a visible plan, sequenced by confidence. It also flags risk on its own. If every Initiative supporting a year-end target is sitting in Later, that’s a course-correction signal anyone can see, without waiting for a status meeting to surface it.
“But Customers ask what’s coming”
Share the problems you’re solving and the order you’re solving them in, rather than promising specific features by specific dates. Customers get a clear, honest sense of direction, and you avoid making commitments you might have to walk back when discovery changes the plan. Transparency about intent builds more trust than precision about dates you can’t guarantee.
“The transparency it brings to the product process. We use our ProdPad roadmaps to communicate about our initiatives and the outcomes and objectives they relate to. Anyone in the business can access that and stay up to date.”
Keji Adedeji, Head of Product, Talis
The thread running through all three is the same. Stakeholders don’t actually want dates. They want to know their priorities are understood, that there’s a real plan behind them, and that they’ll hear early if something is at risk. A Now-Next-Later roadmap connected to OKRs gives them all three, with more honesty than a timeline ever could.

FAQs
- Do Now-Next-Later roadmaps have dates?
Yes, selectively. This is the most common misunderstanding. Now-Next-Later doesn’t ban dates. It removes them from work that isn’t certain enough to commit to, and keeps them where a real commitment exists: a regulatory deadline, a contractual obligation, a launch tied to a market window or a trade event. The date lives on the Objective or the specific Initiative that genuinely has one, not on every line item.
- How long does it take to migrate to Now-Next-Later?
If your Vision and Objectives are already in place, the conversion itself usually fits inside a single workshop, a half day to a full day. You don’t need to pause delivery to do it. The longer part is the stakeholder transition, which typically takes a couple of planning cycles before the new format feels normal to everyone reading it.
- Should engineering teams use Now-Next-Later??
A Now-Next-Later roadmap is a strategic document, not a delivery plan, so engineering keeps working in its delivery tool: Jira, Azure DevOps, Linear, whatever you use. Once an Idea is validated and specced, it moves off the roadmap and into the delivery backlog with dates and detail attached. The roadmap and the sprint board do different jobs, and the two-way sync keeps them connected without blurring the line.
- Can enterprise companies use Now-Next-Later?
Yes. Larger organizations roll multiple Now-Next-Later roadmaps up into portfolio and product-line views. The format scales precisely because the unit of planning is the problem to solve rather than the individual feature, which keeps a portfolio view readable even across dozens of teams. In regulated industries, genuine commitments live on OKRs and compelling deadlines while the rest of the roadmap stays confidence-based.
- How often should you update a Now-Next-Later roadmap?
Treat it as a living document. Review it every planning cycle, and any time new evidence shifts your confidence in an Idea. Initiatives move left as they mature and gain validation, and their titles get more specific as the problem narrows. A roadmap that hasn’t changed in a quarter usually means discovery has stalled.
Where Now-Next-Later sits in the roadmap maturity model
Now-Next-Later isn’t a random alternative to timelines. It’s the top rung of a ladder that most product teams climb as they mature. Seeing the full ladder helps you place where you are today and where you’re heading.
Level 1: Feature roadmap. A flat list of features with no time structure and no link to strategy. Useful as a backlog, useless as a roadmap.
Level 2: Timeline roadmap. Features plotted against dates, usually as a Gantt chart. It looks authoritative and creates false certainty, which is exactly the problem you’re here to solve.
Level 3: Theme roadmap. Work grouped into themes, which is a real improvement. The risk is that themes can still be output-shaped (“the payments theme”) and still get pinned to a timeline underneath.
Level 4: Outcome roadmap. Organized around outcomes and problems to solve, but often still laid out against a timeline. The mindset has shifted; the format hasn’t caught up.
Level 5: Now-Next-Later roadmap. An outcome roadmap that drops the timeline for confidence-based horizons and links every Initiative to an Objective.
Most teams converting a timeline roadmap are jumping from Level 2 to Level 5. That’s a big leap, which is exactly why doing it in deliberate steps matters.
Why the switch is worth the disruption
Converting from a timeline roadmap feels like a lot of change at once, and it is but you’re not throwing away your roadmap. You’re keeping the useful thinking and removing the false certainty. That’s why most teams find the switch easier than they expected.
The mechanics take a workshop.
Janna Bastow – Creator of the Now-Next-Later Roadmap
The real change is learning to communicate confidence instead of dates.
Once the roadmap reflects confidence instead of promises, it becomes easier to keep current, easier to explain, and far more useful for making product decisions.
You’ve got the method. The fastest way to make it stick is to build it in a tool designed for it. Start a free ProdPad trial and convert your roadmap for real.