BlogJune 2026

Your Roadmap Is a Set of Bets About Survival

Two years ago my team shipped an agentic product into a category that was moving quickly. It had six major subsystems. Every one of them existed to cover a limitation in the models available at the time. None of them existed because a customer had asked for it.

That was not a mistake. In 2024 it was the only way to ship something that actually worked. But it did mean a large part of our product was standing on ground we did not control, and I did not think about it in those terms until much later than I should have.

The feature we kept iterating on

Our flagship let each account train a private style model on its own approved assets. Four quarters of iteration went into it, two engineers part time plus most of an ML engineer.

The data looked reasonable. Seventy percent of accounts opened it monthly. Looking more carefully, that was one user per account, and most sessions ended without a change being saved. Nobody caught that for a while, partly because you do not go hunting for bad news inside a metric that is already green.

Then a base model release matched our tuned output with no setup time at all. The reason the feature existed had quietly gone away. Usage held steady for another two quarters, which I now read as habit rather than value. That lag is the uncomfortable part. By the time the chart moves, the year is already spent.

Removing it turned out to be a pricing problem more than an engineering one. Our onboarding fee had been justified by the training work, so cutting the feature meant reopening the commercial conversation with eleven accounts. That took considerably longer than the code removal.

I had always thought of sunk cost as an engineering problem, or an ego problem. In our case the stickiest thing holding a dying feature in place was that part of our revenue model was resting on it.

The feature we should have thought about differently

Nine months went into a custom typography and compositing engine, because the models of the day could not render legible type. It worked well. Customers noticed.

What I would question now is not the quality of the work but its durability. It closed a capability gap rather than solving something specific to our customers, and capability gaps tend to close on somebody else's roadmap. One commodity release eventually brought that same output within reach of anyone in the category.

The asset that did compound got much less attention, largely because it looked like plumbing. Fourteen months of brand rejection decisions. The unwritten rules that never make it into a guidelines document. It was specific to each account, hard for anyone else to reconstruct, and it improved every month without us shipping a thing.

Heavy investment where the advantage was temporary. Light investment where it accumulated. Both allocations felt sensible on the day we made them, which is what makes this pattern worth watching for rather than something you can simply resolve to avoid.

The two mistakes are related

Both are really about which parts of a product deserve to persist. In one direction you keep funding something that has stopped earning its place. In the other you underfund something that is quietly compounding. Iteration and deprecation look like opposites, but they are the same judgement pointed in two directions.

Three things I pay closer attention to now:

Capability drift. If a feature exists to cover a model or vendor limitation, an upgrade somewhere else can remove its reason for existing well before your usage numbers reflect it.

Accrual or depreciation. If each new unit of work makes the next one cheaper, that tends to be worth funding. If the cost stays flat forever, it is worth asking what you are building toward.

Substitution cost. If a competitor could match it by upgrading a dependency, it may be a feature rather than a moat.

None of this is an argument for shipping less. It is an argument for knowing which parts of your product are meant to survive the next model release, and being willing to say it plainly when the honest answer is that some of them are not.