In product, it's easy to jump from one opportunity to the next.

A customer raises an interesting request. A salesperson spots a possible market. Support identifies a recurring pain point. A Mixpanel analysis opens up a lead. A SQL query tells a different story. Someone runs a benchmark. Someone else opens a Miro board. All of this is useful, sometimes. But in the end, the company finds itself with a lot of material, a lot of discussions, a lot of spent energy, and one question that keeps coming back:

When are we going to do this?

The problem isn't just a lack of time. The problem is a lack of readable direction.

A product team can have worked seriously — piling up studies, workshops, analyses, and hypotheses — without the company really knowing what's a priority. And when nothing is clearly decided, everything stays mentally open. The topics aren't done, but they aren't abandoned either. They just sit there. They keep coming back in meetings. They rot. They wear you down.

That fatigue is intellectual, but also moral. Working on topics that no one knows will ever actually be done drains the intensity. You tell yourself: "Anyway, this may never get prioritized." The work loses its force because it's no longer tied to a clear decision.

The Now / Next / Later roadmap answers this problem.

But only if you understand clearly what it is.

An NNL Roadmap Is Not a Schedule

The Now / Next / Later roadmap, or NNL, doesn't try to say precisely what will ship on such a day, such a week, such a month.

It replaces a logic of dates with a logic of certainty horizons.

• Now: what the team is doing now.
• Next: what the team is preparing or seriously considering.
• Later: what remains within the field of possibilities, but isn't a priority.

This structure looks simple. It is. That's actually the point.

But the simplicity of the format shouldn't obscure its real function. An NNL roadmap is not a decision matrix. It doesn't decide in the Product Manager's place. It doesn't replace product strategy. It doesn't replace the trade-offs. It serves to make those trade-offs visible, debatable, and communicable.

A good NNL roadmap can fit on a single page. Ideally, it should be understandable without reading a twenty-page document. It's not a product database, nor a ticket-management tool, nor an inventory of everything the company could possibly do.

It's a map of direction.

Now, Next, Later: What Each Column Means

The column already carries a decision. The card explains the value.

This is an important point. You shouldn't fill cards with information that just repeats the column's status. If a card is in Now, we already know it's committed. If it's in Next, we already know it's a candidate. If it's in Later, we already know it's not a priority.

So the card has to answer a different question: why does this topic deserve a place here?

Now: What We're Doing

Now is committed work.

At this stage, you should be past the vague discussion. You know which problem you're tackling, what value you want to create, for whom, within what limits, and how you'll know whether the topic is working.

A Now card must therefore be concrete. It may carry a feature, a product evolution, a structural improvement, but above all it must carry a clear promise of value.

You should be able to find in it:

• the value promise;
• the target;
• the current problem;
• what's going to change;
• what's included and what isn't;
• the expected benefits;
• the success metrics;
• what you can tell customers;
• what you must not promise.

Now is also the most constrained column. It's limited by the team's real capacity to deliver right now. If a team can handle three major topics, it shouldn't display eight. Otherwise the roadmap no longer clarifies anything: it manufactures an illusion of commitment.

Next: What We're Preparing

Next is the level of serious topics.

They aren't committed yet like Now, but they aren't mere ideas either. They may still be in the problem space. They may already be leaning toward a solution. But at a minimum they must have signals, an envisioned value, and a clear reason to be looked at now.

A Next card may contain:

• the problem or opportunity;
• the envisioned value;
• the available signals;
• the questions to settle;
• the conditions for moving to Now;
• the potential business impact;
• what can be said internally;
• what must not be said to customers.

Next must stay limited. If too many topics are in Next, nothing can really move forward. The column becomes a political pre-backlog: everyone drops their topic in to keep it visible, but no one owns the constraint.

Later: The Field of Possibilities

Later is the universe the company agrees to keep visible without committing to it.

This column is useful because it avoids needless brutality. Not every non-priority topic is absurd. Some are interesting. Some will become important if the market shifts, if a big customer signs, if a regulatory constraint appears, if a technical dependency disappears, or if a technological leap suddenly makes possible what wasn't.

But Later is not a promise.

A Later card must explain:

• the possible value;
• the target;
• why the topic stays visible;
• why it isn't a priority;
• the available signals;
• the triggers for reassessment.

Here again, the column must stay limited. If Later becomes an endless list, the roadmap turns back into an inventory.

The No: What We Won't Do

In NNL, the most important thing isn't always what's written.

The most important thing is sometimes what isn't there.

The No isn't a formal column. But it's the central effect of the roadmap: anything that's neither Now, nor Next, nor Later is out of scope for the current horizon.

This doesn't mean the topic is dumb. It doesn't mean we can never bring it up again. It means: for now, barring a major disruption, we won't do it.

This is essential, because what we do and what we don't do are two sides of the same decision.

If the company says it wants to move forward on automation, onboarding, and reducing support load, it's also saying it won't — for now — do the full interface overhaul, the integrations marketplace, the accountant module, and the specific requests of a small customer segment.

This renunciation isn't collateral damage. It's the mechanism that protects focus.

A roadmap that doesn't let you say no doesn't serve to align. It only serves to defer conflicts.

The Capacity Constraint Is the First Safeguard

An NNL roadmap must be physically constrained.

Now is set by the team's capacity to deliver at a given moment. Not by management's ambition. Not by sales pressure. Not by the number of interesting topics.

If the team has the capacity to do two major topics well, Now must contain two major topics. Maybe three if the topics are smaller. Not ten.

The same logic applies to Next and Later.

An overloaded Next blocks circulation. Later topics can no longer move up. Next topics stay candidates for too long. The system gives an impression of movement, but there's no longer any real decision.

The constraint on numbers forces you to justify.

It forces you to ask:

• why this topic rather than another?
• which problem does it serve?
• which business objective does it support?
• which risk does it reduce?
• what value does it bring?
• what are we turning down by giving it this place?

A simple rule: the roadmap must stay readable on a single page. If it overflows, it no longer clarifies. It turns back into a stockpile.

Strategy Before the List

An NNL roadmap isn't a list of topics filed into three columns.

If it isn't tied to a product vision and a company strategy, it becomes nothing more than a prettier presentation of the existing mess.

So before filling the columns, you have to know what the company is trying to accomplish. Growth? Retention? Expansion into a segment? Reducing support load? Differentiation? Regulatory safety? Moving upmarket? Removing a critical friction?

The topics must then be assessed through clear risks.

We can borrow here the major product risks popularized by Marty Cagan:

• is it good for the business?
• does the customer want to buy it?
• does the user want to use it?
• is it technically feasible?

These questions keep you from filling the roadmap with the loudest topics. An important sales request may be legitimate. A support pain may be critical. A market opportunity may be real. But the roadmap must not be the sum of the incoming pressures.

It must be the visible translation of a strategy.

How to Fill a Card Without Doing Paperwork

The classic trap is turning the roadmap into a form.

In product, we sometimes love creating fields, statuses, tags, workflows, sub-categories, validation rules. It gives an impression of seriousness. But if the information helps neither to decide, nor to understand, nor to communicate, it just weighs the system down.

The good rule is simple: the column carries the decision, the card explains the value.

So there's no need to put in every card:

• its horizon;
• its level of commitment;
• its role;
• its administrative nature;
• a repeat of the status.

The card should instead make the topic understandable.

For a Now card, you should be able to understand what's going to change and how you'll measure success.

For a Next card, you should be able to understand why the topic is serious, what's left to settle, and what would move it to Now.

For a Later card, you should be able to understand why the topic stays visible and why it isn't a priority.

Everything else should stay light. Sometimes a tag is enough.

NNL Roadmap and Backlog: Two Different Objects

The NNL roadmap is not a backlog.

The roadmap selects the major topics worthy of attention. The backlog organizes the work to be done on the selected topics.

The difference matters.

In the roadmap, you might have an initiative like:

Automate the entry of paper documents.

In the backlog, this initiative will be broken down into problems, features, technical tasks, design tickets, stories, acceptance criteria, dependencies, tests, fixes, iterations.

The backlog is finer. It's operational. It's there to deliver.

The roadmap, for its part, is there to align.

The risk is turning the backlog into the roadmap's dumping ground. A topic isn't in Now, isn't in Next, isn't in Later, but you don't really want to kill it. So you drop it in the backlog. It'll stay there. It'll age. Someone will find it again six months later. It'll have to be re-discussed. The mental load will return.

If a topic isn't in the NNL, it shouldn't automatically go into the backlog.

Otherwise the backlog absorbs all the renunciations the roadmap failed to own.

Internal Roadmap and Customer Roadmap

You probably need two roadmaps.

An internal roadmap and a customer roadmap.

The internal roadmap can be more complete, more strategic, more nuanced. It can contain hypotheses, trade-offs, limits, reasons for non-priority, sensitive topics, still-open debates.

The customer roadmap must be a translation.

Not an automatic extraction. Not a filtered copy. A manual, careful, product-and-sales translation.

This work is too subtle to be automated well. What you can tell a customer depends on the real level of commitment, the risk of implicit promise, the sales context, the segment, the maturity of the topic, and the company's ability to hold the message.

A Now topic can often be communicated, with clear limits.

A Next topic can sometimes be raised as a direction of thinking, but it must not be sold as a commitment.

A Later topic must be handled with care. The mere act of showing it can create an expectation.

Here again, what you don't do counts as much as what you do. Customer communication changes according to the choices the roadmap owns.

Governance: Who Decides, and at What Cadence?

An NNL roadmap needs an owner.

Everyone can propose. Everyone can challenge. Sales must be able to raise what they see. Support must be able to carry the recurring pain points. Developers must be able to flag technical risks. Executives must be able to remind everyone of the strategy. Customers must be able to have influence through their real problems.

But in the end, there has to be a decision-maker.

In most product organizations, that decision-maker must be the Product Manager, or the person who truly owns the product trade-offs. They must listen to everyone, but they must also make the call. Otherwise the roadmap becomes a soft compromise between power games.

The review cadence must be slow enough to avoid permanent discussion, but regular enough to stay connected to reality.

A quarterly cadence is often a good baseline.

Too short, and you risk turning the roadmap into a political debate or bar-stool banter. Too long, and you risk keeping topics that are no longer aligned with the strategy, the market, or actual capacity.

Monthly check-ins can exist with sales and stakeholders, as long as they don't turn into a power game. Their role should be to surface signals, not to overturn the roadmap with every new opportunity.

The entry and exit rules must stay simple.

A topic enters the NNL if it has enough value, signals, strategic tie-in, and available capacity to deserve a place.

A topic exits if a stronger topic enters, if the strategy changes, if the signals disappear, if feasibility collapses, or if a major disruption redistributes the priorities.

No need to create too much paperwork. A short note or a tag can be enough to explain why a topic left.

A Roadmap's Weakness: It Fixes Things in Place

A roadmap serves to set a direction.

That's its strength.

But it's also its limit.

Even a good NNL roadmap can create a lock-in effect. It protects against scatter, but it can also keep you from tackling small, obvious improvements — very useful, very much awaited, but too small or too opportunistic to become roadmap topics.

That's where a commando mode can make sense.

Not as an extra column. Not as a permanent exception. Not as a way to bypass the trade-offs.

As a controlled breath of air outside the roadmap.

For example: a protected block of time on Friday, a minimal team, direct dialogue, little bureaucracy, a topic chosen at the Product Manager's discretion, a strong conviction of value, a limited effort, and a cutoff from the usual interruptions.

The point is to handle those small things that move the product and show customers the company is making progress. Not the big uncertain projects. Not the strategic bets. The topics where you already know there's value — because the pain comes up often, because support sees it, because customers put it into words, because the team knows the product.

A simple example: a customer needs to produce an administrative document and pull data from ten different screens. The ideal solution might be a full module. But a text or Markdown export, even imperfect, can already save them several hours.

That's not the roadmap.

It's a breath of air around the roadmap.

And What About Bugs?

The theory is clean. Reality is less so.

In real life there are bugs, maintenance, regressions, emergencies, pain points, technical debt.

The NNL roadmap doesn't replace the operational management of the product.

Bugs are often handled day to day, according to their severity, their customer impact, their frequency, their risk, and their visibility. Not every bug belongs in the roadmap. If they all go in, the roadmap stops being a tool of direction.

Technical debt calls for different treatment. A debt is only truly a debt when you decide to pay it down. Before that, it's often a discomfort, a latent risk, a complexity, an architectural weakness, sometimes known for a long time. It becomes a product topic when the company decides its cost is now higher than the cost of dealing with it.

Some technical topics can therefore enter the NNL. For example if they block a strategy, sharply slow the team down, expose the company to a risk, degrade customer quality, or prevent an important product change.

But here again, you have to be clear: the roadmap carries a direction. It must coexist with day-to-day bug management and an explicit strategy for handling technical debt.

These two subjects deserve their own articles.

Example: A Simple NNL Roadmap

Let's take a B2B SaaS for administrative management.

The company serves customers who need to produce documents regularly, centralize information, and reduce manual work. The product team is limited: it can't run five major projects in parallel. The strategy for the quarter is to reduce user friction and strengthen perceived value on recurring use cases.

An NNL roadmap might look like this.

Now

Simplified tax export

Promise: let the user quickly generate a file containing the information needed for an administrative procedure.

Value: avoid several hours of searching and copy-pasting across different screens.

Limit: this isn't a full tax module yet. It's a useful, reliable, understandable export.

Metrics: number of exports, drop in support requests tied to this procedure, qualitative feedback from the customers concerned.

Reducing an onboarding pain point

Promise: reduce the time needed to complete the first setup successfully.

Value: improve activation and reduce early blockers.

Limit: we're not overhauling all of onboarding, we're tackling the main blocking point.

Metrics: activation rate, time to first value, support tickets on the step concerned.

Next

Document-entry automation

Envisioned value: reduce manual work on paper or PDF documents.

Signals: recurring customer requests, high support time, opportunity for differentiation.

Questions to settle: realistic level of automation, expected quality, technical feasibility, acceptable cost of error.

Condition for moving to Now: reduced scope, clear value, technically manageable solution.

Improved activity reporting

Envisioned value: give customers a clearer view of their activity and their blocking points.

Signals: sales requests, customer feedback, frequent use of existing exports.

Questions to settle: which metrics are truly actionable, for which profiles, at what usage frequency?

Later

Advanced AI module

Possible value: further automate the analysis and preparation of documents.

Why visible: possibly strategic topic, fast-moving market.

Why not a priority: strong technical dependencies, risk of over-promising, value still insufficiently framed.

Trigger: a technological leap, strong demand from a priority segment, proof of usage on a narrow case.

Integrations marketplace

Possible value: connect the product to more of the customers' tools.

Why visible: could support expansion.

Why not a priority: high cost, likely scatter, customer need still too heterogeneous.

Trigger: a clear concentration of requests around a few critical integrations.

Accountant portal

Possible value: create a dedicated experience for an important external player.

Why visible: an interesting topic for certain segments.

Why not a priority: still uncertain impact, risk of complicating the core product.

Trigger: the signing of a big customer, or an explicit strategy on this segment.

Outside the NNL

Some topics aren't on the roadmap.

For example:

• a full interface overhaul;
• specific requests from a small customer;
• advanced features for a non-priority segment;
• isolated integrations with no market signal;
• an AI experiment that's too general.

These topics may be interesting. They're simply not in the current direction.

And that's precisely what makes the roadmap useful.

Conclusion

A successful NNL roadmap doesn't create the illusion that everything is possible.

It gives the company the strength to do few things, but to do them for real.

It clarifies what's committed, what's being prepared, what remains possible, and what's out of scope. It reduces scatter. It protects the backlog. It makes the renunciations debatable instead of hiding them. It gives the Product Manager a framework to listen, arbitrate, and communicate.

NNL isn't perfect. It doesn't handle bugs, technical debt, emergencies, or small high-value opportunities. But it gives one rare thing: a direction clear enough that the company can move forward without reopening everything all the time.

And in many product organizations, that's already huge.

Further Reading

The Tools of Organizational Coherence The Backlog Is Not a Dumping Ground: It's a Tool for Action Why Organizations Prefer Soft Decisions