Product roadmaps / Product management / Planning
Now–Next–Later roadmap: a practical example and template
Build a Now–Next–Later roadmap with clear horizons, a worked example, a reusable template, and honest handling of deadlines and changing priorities.
At a glance
A Now–Next–Later roadmap groups product priorities by how ready they are for action. Define the horizons, describe the problems and intended outcomes, and record the evidence needed for the next decision. Keep actual deadlines explicit and connect selected work to a separate delivery plan.
A Now–Next–Later roadmap helps a product team explain its current priorities without pretending every possible improvement already has a delivery date. The useful output is a shared decision about where to focus, what to investigate, and what can wait.
In ProdPad’s definition, Janna Bastow describes the columns as confidence horizons: active work, problems under investigation, and less certain strategic possibilities. Her account of the format’s development also emphasizes prioritizing problems and keeping genuine time constraints visible. Those principles leave room for the team to change a solution when it learns something important.
The examples below are an original, hypothetical plan for a small software team improving customer onboarding. They are not Leera customer results or promised improvements.
Give each horizon an explicit meaning
Write a short explanation above the roadmap. Otherwise, one stakeholder may read Next as next month while another reads it as an uncommitted idea. The ambiguity survives even when the columns look tidy.
Use these definitions as a starting agreement:
| Horizon | What belongs here | What the team should know |
|---|---|---|
| Now | Problems receiving active delivery or focused discovery effort | Owner, intended outcome, current approach, and next decision |
| Next | Strong candidates for attention after current priorities | Why they matter, supporting evidence, and unresolved questions |
| Later | Relevant opportunities without enough priority or understanding to pursue yet | Strategic relevance and the signal that would justify revisiting them |
These are suggested operating definitions, not mandatory stages. A high-risk problem may need active discovery in Now even while its solution is unknown. Next should not mean that somebody has secretly approved implementation.
Set a practical limit on active priorities. If one small team has twelve initiatives in Now, identify who is actually moving each one forward. Work without capacity belongs in a different horizon or needs a more honest status.
Write the problem before selecting the feature
“Build an onboarding checklist” is a proposed solution. “Help new administrators reach their first useful workspace” leaves room to investigate what prevents progress. The eventual answer could be clearer setup, better invitation recovery, a sample project, or a change to the product’s defaults.
Use an initiative statement with three parts: the people affected, the difficulty they experience, and the change the team wants to observe. For example: “New administrators cannot tell whether their first invitation succeeded; help them complete setup without asking support to investigate.”
Record candidate solutions underneath that statement. This preserves useful ideas while keeping them replaceable. If evidence shows email delivery is the problem, the team can change direction without pretending the original checklist idea succeeded.
The outcome-based roadmap guide explains how to define the measure behind that desired change. You do not need to settle every measurement detail for Later items, but active priorities need a way to judge progress beyond ticket completion.
Use a small worked roadmap
Imagine a team that has observed new administrators leaving setup after inviting colleagues. It has support examples and incomplete event data, so its first task includes checking the evidence itself.
| Horizon | Initiative | Current evidence | Next decision |
|---|---|---|---|
| Now | Make invitation status understandable | Support conversations describe confusion after Send | Compare a status explanation with a recoverable error message |
| Next | Help a new member find the first assigned task | Session observations suggest an unclear landing page | Observe invited members before selecting a layout |
| Later | Reduce repeated setup for returning administrators | A few requests mention reusing project structure | Revisit if the same difficulty appears across more eligible accounts |
This roadmap deliberately avoids presenting three predetermined features. Each row makes the next useful action visible. It also records different kinds of evidence without treating a handful of requests as a population estimate.
Suppose the first investigation finds that invitations arrive correctly but members cannot recognize the sender. The Now initiative can continue with a revised approach. The team might pause the status redesign and test clearer invitation wording. Record the reason so stakeholders see a considered change rather than unexplained movement.
Copy a template that supports decisions
Keep each entry short enough to review without opening a second presentation. Link the supporting material when someone needs detail.
| Field | What to write |
|---|---|
| Initiative | A recognizable customer or operational problem |
| Horizon | Now, Next, or Later, using the agreed definitions |
| Intended outcome | The behavior or condition you want to improve |
| Evidence | Observations, data source, date, and relevant limitations |
| Candidate approaches | More than one possibility when the solution is uncertain |
| Owner | The person coordinating the next decision |
| Open question | The most consequential uncertainty |
| Next action | A specific investigation, decision, or delivery step |
| Constraint | Any real deadline, dependency, or fixed obligation |
| Review trigger | A date or event that makes another review useful |
For the invitation example, the open question could be whether administrators understand the message they see after sending an invitation. The next action is to observe the task with relevant participants. “Do more discovery” would leave the work less clear.
Avoid requiring every field at the same depth in Later. A distant opportunity needs enough context to remember why it matters. Fully estimating and specifying all possible work uses time that could improve today’s decision.
Keep deadlines attached to their reasons
A contract or coordinated launch can create a real date constraint. Record the date, who depends on it, and what must be true by then. Distinguish a minimum obligation from optional enhancements.
For example, a customer may need an agreed export format before a migration window. That constraint belongs beside the relevant initiative and in the delivery plan. It does not justify adding arbitrary dates to unrelated discovery work.
When someone asks for a forecast, explain the current scope, dependencies, and uncertainty. A date can be useful without being unconditional. If the forecast changes, show which assumption changed and what options remain.
For committed work that needs sequencing, use a dated delivery plan alongside the roadmap. The two views answer different questions and should link to the same underlying work.
Review movement with a short decision record
Choose a review rhythm that matches how quickly evidence and priorities change. A weekly team check and a less frequent stakeholder discussion can work as a starting point; adjust them when they produce either stale decisions or repetitive meetings.
Ask four questions during a review:
- What did we learn that changes the importance or approach of an initiative?
- What has become possible because capacity or a dependency changed?
- Which entry should move, split, stop, or leave the roadmap?
- What needs to be communicated to people who rely on the previous plan?
Moving from Next to Now should include an owner and the next concrete step. Moving back should include the reason. Removing an item can be a useful decision when the evidence weakens or the strategy changes.
Keep a brief history: previous choice, new evidence, decision, and consequence. This helps a sales or support colleague explain a change without guessing or accidentally promising a replacement date.
Connect the roadmap to everyday work in Leera
Maintain the horizon table in Leera Documents, with the agreed definitions and decision history nearby. Link an initiative to its relevant Planner epic or issues so the team can follow the reasoning into delivery.
Use Planner for selected issues, owners, priorities, backlog refinement, and sprint or kanban work. Leera’s native roadmap shows epics and child issues against dates; it is not a dedicated Now–Next–Later view. Keep the conceptual horizons in the document and use the timeline when the selected work needs dates.
When an initiative enters delivery, link acceptance criteria and relevant QA coverage. A completed issue demonstrates that the team finished specified work. Review the agreed product measure separately to learn whether the initiative helped.
Start by converting a handful of real priorities. Agree on the meaning of the three horizons, identify one unresolved decision per active initiative, and arrange the next review. The template becomes useful when it changes a decision the team would otherwise have left implicit.
Frequently asked questions
What is a Now–Next–Later roadmap?
It is a product roadmap organized into three horizons rather than a calendar of promised feature dates. Now describes active priorities, Next identifies likely priorities that need further learning, and Later keeps relevant but less understood opportunities visible. Define what each horizon means for your team.
Does Next mean the next quarter?
Not inherently. Assigning quarters to all three columns turns them into a dated plan. If your organization needs quarterly commitments, show those explicitly and explain how they relate to the priorities in the roadmap.
Can a Now–Next–Later roadmap include deadlines?
Yes. Attach a real deadline and its reason to the relevant item. A contract, external event, or dependency can constrain a particular decision without turning every opportunity in the roadmap into a dated commitment.
How is this different from a kanban board?
A roadmap explains product priorities and the problems worth addressing. A delivery kanban board tracks the status of selected work. An initiative in Now can contain several issues at different delivery stages; moving a ticket to Done does not automatically demonstrate the intended outcome.
Does Leera have a native Now–Next–Later roadmap view?
Leera’s native roadmap shows epics and child issues on a date-based timeline. You can maintain the three-horizon template in a Leera document and link it to Planner issues. The document is a team-maintained planning format, not an automatic horizon or outcome-management feature.