A roadmap is an input when it is agreed in advance and then defended, and an output when it is a rendering of what current evidence says should be built next. Input roadmaps buy predictability at the cost of accuracy. Output roadmaps invert that trade. Most teams need both, at different altitudes.

For most of the last decade this question had an obvious answer. Building was expensive, so committing early was rational: you planned carefully because getting it wrong cost you a quarter. The roadmap was the input, and everything downstream — discovery, design, engineering — executed against it.

That calculation has changed on one side only. The cost of building has dropped sharply. The cost of building the wrong thing has not moved at all. When those two costs diverge, the constraint moves from execution to selection, and a document whose main job was to protect execution capacity starts protecting the wrong thing.

This is not an argument that roadmaps are dead. It is an argument about which direction the arrow points, and about what has to exist before you can point it the other way.

What does it mean for a roadmap to be an "output"?

An input roadmap is authored. Someone writes it, stakeholders negotiate it, it gets locked, and the following months are spent delivering against it. Changes are exceptions requiring justification.

An output roadmap is rendered. It is the current best answer to "what should we build next," derived from evidence that already exists in the system, and it changes when the evidence changes. Nobody negotiates it into being. Someone reads it.

The practical difference shows up in what happens when new information arrives. Under an input roadmap, a strong new signal in week six is a threat to the plan, and the plan usually wins. Under an output roadmap, the same signal simply reorders the rendering, and nobody has to lose an argument for that to happen.

The critical thing this requires: something else has to become the input. A roadmap cannot be an output of nothing. If you remove the authored roadmap without putting a structured evidence layer underneath it, you do not get responsiveness. You get whoever spoke to a customer most recently setting the agenda, which is worse than the roadmap you deleted.

What replaces the roadmap as the starting point?

The weighted signal.

A signal, in the sense we use it in Lane, is a claim that a specific problem recurs across specific accounts — assembled from individual insights extracted from feedback, grouped by meaning rather than keyword, and weighted by who is affected, what they pay, and whether the pattern is accelerating. The mechanics of how feedback becomes a signal are covered in detail in how customer feedback becomes a product decision.

The reason this can serve as the input layer is that it has three properties an authored roadmap lacks.

It updates without a meeting. New feedback attaches to an existing signal or seeds a new one as it arrives. The state of the evidence at any moment is current by construction, not by someone remembering to update a document.

It carries its own justification. Every signal traces back through its insights to the original conversations and the accounts they came from. A rendered roadmap item is never an assertion, because the evidence is one click underneath it.

It degrades honestly. A signal that has gone quiet for two months looks quiet. An authored roadmap item that no longer matters looks exactly like one that does, because both are a rectangle on a slide.

That third property is the underrated one. The failure mode of authored roadmaps is not that they are wrong on day one. It is that they cannot tell you when they became wrong.

Why does this matter more now than it did three years ago?

Because the bottleneck moved, and organisational habits have not caught up.

When a feature took a quarter, the sequencing decision was made a small number of times per year and each one was consequential enough to justify weeks of deliberation. The roadmap's slowness was proportionate. It was slow because the thing it governed was slow.

When a capable team can ship something meaningful in days, the sequencing decision is made continuously. A governing document that regenerates quarterly is now the slowest component in a fast system. The team ships more, and the fraction of what they ship that matters goes down, because selection is running at the old cadence while delivery runs at the new one.

There is a second effect specific to agent-assisted development. Coding agents are extremely good at building what they are pointed at, and have no opinion about whether it should exist. Pointing them requires the same judgment it always did, exercised more often. The teams that will struggle in this period are not the ones shipping slowly — they are the ones shipping quickly in a direction nobody validated, and discovering it later than they used to, because volume hides the error.

What are the honest arguments against this?

Three, and they are not weak.

Sales needs something to promise. A rep on a call cannot say "our evidence layer will render a recommendation next week." They need dates and named capabilities. An output roadmap that reorders itself weekly is unusable as a sales artifact, and pretending otherwise is how product teams lose the trust of the revenue org.

Engineering needs stability to plan against. Hiring, architecture, and infrastructure decisions run on quarters, not on signals. A team that re-derives its priorities every week cannot make a six-month platform investment, and some of the highest-leverage work is exactly that kind of investment.

Some of the best work does not come from feedback at all. Signals describe problems inside the frame customers already understand. They will not tell you to build the thing nobody knew to ask for. A team that lets its evidence layer fully determine its direction will build a competent, incremental, unsurprising product.

The resolution to all three is altitude rather than compromise.

Strategy stays authored. What market you serve, what bet you are making, what you refuse to build — these are inputs, they should be stable for quarters, and no amount of feedback should reorder them weekly. Sequencing becomes rendered. Within an authored strategy, which problem gets solved next is a question the evidence can answer better than a committee can, and should be allowed to.

Put crudely: the destination is an input, the next turn is an output. Most roadmap dysfunction comes from managing both at the same cadence.

How would a team actually make this shift?

Not by deleting the roadmap. By changing what the roadmap review is for.

Today, most roadmap reviews are about defending or renegotiating commitments. The meeting's implicit question is "are we still doing what we said?" That question has a low information yield, because the answer is usually yes, and when it is no everyone already knew.

Under an output model, the review's question becomes "what does the evidence say now, and where does it disagree with what we planned?" Disagreement is the useful output. A review that surfaces three signals that have accelerated since the last cycle and one committed item whose supporting evidence has gone quiet is worth having. A review that walks a Gantt chart is not.

The sequence that works in practice:

1. Get the evidence layer working first, while the authored roadmap stays exactly as it is. Do not change the process yet.

2. Run both in parallel for a cycle. Note every place the rendering disagreed with the plan, and who turned out to be right.

3. Change the review question, not the artifact. Keep the roadmap document for sales and planning; change what the meeting is about.

4. Only then loosen the commitment horizon, and only for the near term. Next quarter can be rendered. Next year should still be authored.

Skipping step one is the common failure. Teams get convinced by the argument, loosen their commitments, and find they have replaced a flawed plan with no plan.

The two models, compared

When this doesn't apply

If you have a small number of customers and speak to all of them, you are already running an output model informally, and formalising it adds ceremony without adding information. Read everything yourself for as long as that is possible.

If you sell into enterprise with long procurement cycles and contractual roadmap commitments, the input model is not a habit you are failing to shed — it is a requirement of the deal structure. The most you can do is render internally and author externally, and be honest that the two will diverge.

If your product is genuinely novel, feedback will underdetermine your direction for a long time. Signals will tell you what your early users find confusing, which is valuable, but they will not tell you what to build next in any strategic sense. Weight them accordingly.

And if your organisation cannot currently trace a roadmap item back to the evidence behind it, this shift is premature. Traceability is the prerequisite, not the reward.

Frequently asked questions

1. Does an output roadmap mean no commitments? No. It means commitments are made deliberately and for a shorter horizon rather than by default for a long one. Most teams commit further out than they can actually see, then absorb the cost of being wrong quietly. Shortening the honest commitment horizon is the change, not abandoning commitment.

2. What has to exist before a roadmap can be an output? A structured evidence layer: feedback captured with account context, extracted into individual claims, grouped by underlying problem rather than by tag, and weighted by revenue and recency. Without that, removing the authored roadmap replaces a flawed plan with whoever talked to a customer most recently.

3. How is this different from just being agile? Agile changed how work is delivered once selected. This concerns how work is selected in the first place. A team can run flawless two-week sprints against a roadmap that was authored a year ago and has been wrong for eight months. The cadence of delivery and the cadence of selection are separate problems.

4. Doesn't this just mean building whatever customers ask for? The opposite. Requests are inputs to signals, not signals themselves, and a signal is weighted by who is affected rather than by how loudly it was requested. A rendered roadmap makes it easier to decline a loud request, because the ranking is visible and the reasoning is attached.

5. Who owns the roadmap if it is rendered rather than authored? Product still owns it, but the work shifts. Less time is spent assembling and defending the artifact and more is spent on the layer underneath it: what counts as evidence, how signals are weighted, which strategic bets constrain the ranking. The judgment does not move. Its point of application does.

Lane is the evidence layer this depends on — feedback becomes signals, signals become plans, and the roadmap becomes something you read rather than something you defend.