The product roadmap when building is no longer the constraint
Stefan-Iulian Tesoi · · 8 min read
A product roadmap, once coding agents make building cheap, is the record of what not to build and in which order to learn. Engineering capacity used to ration it, so the limit did half the prioritising. With agents almost anything fits, so the roadmap has to name the outcomes worth pursuing, the bets still open and what has been ruled out.
Dates belong on it only where a decision has already been made. Everything else is a guess presented as a plan.
What is a product roadmap for when building is cheap?
It turns a small number of decisions about outcomes into a large number of things nobody needs to build. That is a different job from the one it was designed for, and most roadmaps are still doing the old one.
The classic roadmap was a sequence of features laid against a calendar. It answered a resourcing question: given the people we have, what lands this quarter and what waits. The calendar was the point, because engineering time was the binding constraint and every stakeholder wanted to know where their request sat in the queue.
A coding agent removes most of that queue. A feature that took a developer a week can come back as a pull request the same afternoon, so a list ordered by when things can be built stops carrying information. What still carries information is the reasoning above the list: which outcome each piece of work serves, which bets are being tested, and which requests have been declined. An outcome-based roadmap writes exactly that down.
| Feature roadmap | Outcome-based roadmap | |
|---|---|---|
| Unit | A feature with a target date | An outcome with the bets that serve it |
| What limits it | Engineering capacity | Attention, review time, product coherence |
| What a date means | When it will be built | When a decision is due |
| What a "no" looks like | Silence, or "not this quarter" | A written exclusion with a reason |
| How it fails | Slips | Fills up |
The last row is the important one. A capacity-bound roadmap fails by slipping, which everyone notices. A roadmap without that bound fails by filling up, which nobody notices until the product is twice the size and half as clear.
Capacity used to do half the prioritising
When a team of six engineers could ship perhaps twenty meaningful features a quarter, that ceiling ranked everything below it without anyone having to argue. Request number twenty-one did not get a refusal. It got a quarter that was already full.
That made product prioritisation look easier than it was. The hard conversations happened at the boundary, a handful of items fighting for the last slots, and everything further down was declined by arithmetic. Opportunity cost was visible because it was literal: building the reporting module meant not building the integration, and both sides could see the trade.
Take the ceiling away and the arithmetic stops declining anything. Teams a few weeks into agent adoption describe the same pattern. The backlog that used to stretch three quarters is cleared in six weeks, and the next six weeks are spent building the requests that had been waiting at the bottom, which were at the bottom for a reason. Nothing in roadmap planning objected, because the only objection it knew how to raise was "we do not have the time".
When capacity rationed the roadmap, every yes cost a no. When it does not, the no has to be written down, or it never happens.
What is scarce once agents do the building?
Decisions, review and the product's coherence are scarce: the time to decide what to build, the time to check what came back, and the room in the product for one more thing. None of the three got cheaper when the code did.
- Specification. A coding agent executes what it is given. Someone has to state the outcome, the acceptance criteria and the boundaries, and that work scales with the number of items, not with how fast they are built. Who carries it is the subject of who owns the backlog when agents write the code.
- Review. Every returned change needs a person to accept it against its criteria. At ten to twenty minutes an item, forty items a week is seven to thirteen hours of someone's attention, which caps throughput well before the agents do. The arithmetic is worked through in how many coding agents one team can run.
- Coherence. Each feature adds a screen to learn, a path to support, a question in onboarding and a branch in the code. Technical debt accrues per feature shipped, not per hour spent shipping it, so cheap features accumulate it at the old rate or faster.
- Users' attention. Customers absorb change at a fixed pace. A product that changes weekly faster than its users learn it gets worse while every individual change is an improvement.
A real case makes the point better than the list does. When Laimonade's roadmap generator was tried on a deliberately simple project, a URL shortener, its first draft included an observability epic, a story for an automated release pipeline with a rollback plan, and stories for hosting infrastructure. Each was reasonable on its own and cheap to build. Together they tripled the surface of a product whose whole value was "paste a long link, get a short one". The correction was not a better estimate. It was a rule: a simple project's roadmap carries the essentials of a first version, and infrastructure stays off it until someone asks.
Which prioritisation frameworks still hold up?
The frameworks that price value and delay still work. The ones that divide by effort mostly stop working, because effort is the term agents shrank.
| Framework | What it ranks by | What changes with agents |
|---|---|---|
| RICE | Reach × impact × confidence ÷ effort | Effort near zero inflates every score; the ranking becomes noise |
| WSJF and CD3 | Cost of delay ÷ duration | Duration shrinks for everything, so cost of delay decides alone |
| Kano | Basic, performance and delight features | Unchanged; it never looked at effort |
| MoSCoW | Must, should, could, won't | "Won't" becomes the column that matters |
| Value-effort matrix | Two axes | One axis collapses and the matrix becomes a line |
RICE, as Intercom first described it, divides by person-months. When the honest effort figure for most items is an afternoon, the denominator stops discriminating, and the score rewards whatever has the largest reach claim. The fix is to replace building effort with what the feature costs to keep: review, support, documentation and the maintenance it adds.
Cost of delay holds up best of the set, because it measures what waiting loses rather than what building costs. A prioritisation framework that asks what a week of not having something costs the business keeps working whether that something takes a week or an hour to build.
The practical answer to how to prioritise features with agents in the loop is therefore two questions per item. What does delaying this cost, and what does keeping it cost? Building cost has dropped out of the comparison, and a framework that still leans on it is ranking by the one number that no longer separates the options.
How do you keep cheap work off the roadmap?
By writing the "no" down, with a reason and a date to revisit it, and keeping that list as visible as the roadmap itself. A request that is merely absent from the plan comes back every week; a request that was declined in writing comes back only when the reason has changed.
Five mechanisms do most of the work:
- A not-doing list. Every declined request gets one line: what was asked, why not, and when it will be reconsidered.
- An outcome for every item. An item that serves no stated outcome is cut, however small. Small is precisely the argument agents made free.
- A ceiling on scope. Laimonade's roadmap generator, for example, plans a new project as two to five milestones with one to five stories each, as few as the project needs. A ceiling turns "could we also" into a trade again.
- The week test. Ask whether the item would be built if it still took a week. If the only argument for it is that it is now fast, speed is the argument, and speed is not a reason to own something.
- Maintenance in the price. Each item carries a line saying who supports it and what it adds to the product's surface.
Technical debt is the one place cheap building argues for doing more rather than less. Refactoring, test coverage and dependency upgrades used to lose every prioritisation argument to features; at agent speed they cost little enough to schedule continuously. A roadmap that keeps features scarce and maintenance routine is using cheap building in the direction that compounds.
The role that holds all of this together is product ownership, and it does not shrink when the building does. What it looks like day to day is set out in what an AI product owner actually does, and how the same shift reshapes the weekly cadence is in how sprint planning changes when agents do the building. Laimonade drafts milestones and stories from an intake conversation and the repository, and keeps each story tied to the outcome it serves; deciding which outcomes are worth pursuing stays with the people who answer for them.
Frequently asked questions
Should a roadmap still carry dates?
Only where a decision or a commitment exists. A date for a customer contract, a regulatory deadline or a launch event is real and belongs on the roadmap. A date attached to a feature because the template had a column for it is a guess, and with agents doing the building it is usually a pessimistic one. Dates for when the next decision is due are more useful than dates for delivery.
Who decides priority when an agent could build everything on the list?
The person accountable for the product's outcomes, exactly as before. A coding agent can execute any item it is handed, which is why handing it items is the decision that matters. Agents and assistants can draft options, estimate cost of delay and flag conflicts, but choosing which outcome the product pursues is a judgement about the business, and it stays with someone who answers for it.
How often should the roadmap change when work ships daily?
The outcomes should change quarterly at most; the bets beneath them can change weekly. When every item ships within days, the list of bets turns over quickly, and that is healthy. What should stay stable is the layer above: the two or three outcomes the product is pursuing and the exclusions written against them. A roadmap whose outcomes move every week is not adaptive, it is undecided.