The New Bottleneck

Ask anyone who has shipped software recently what got easier, and you get the same answer: starting. The first working version — the thing that used to take a team a quarter — can now exist in a few days. Not a mockup. Something people can actually use.

That’s a real change, and it’s easy to mistake for the whole story. When one part of a process gets dramatically faster, the pressure doesn’t go away. It moves to whatever is still slow.

The slow part is everything after launch

Here’s the shape of it. You launch. Within a week you know things you couldn’t have known before: which screen people abandon, which feature nobody found, which question support keeps answering by hand. Your software has started producing information about itself, and that information is the most valuable thing you own, because nobody else has it.

And then, mostly, nothing happens with it. Someone writes it down. It becomes a ticket, or a line in a document, or a message in a channel where good observations go to wait. It has to compete with everything else that’s also true and also urgent. Some of it gets built months later, by which point the thing it was answering has moved.

That isn’t a failure of care or competence. It’s a queue. A live product produces useful information far faster than any team can act on it, and making the first build quicker does nothing about that. If anything it makes it worse: more software in the world, producing more of what nobody has time to answer.

What a backlog actually is

A backlog looks like a plan. Read one honestly and it’s closer to an archive:

• —Things that were true when they were written, and might not be now.
• —Things everyone agrees are worth doing, and has agreed for a year.
• —Things that got in because someone senior asked, not because the evidence was strongest.
• —Things that would take a day to build and have never once reached the top of the list.

The items aren’t wrong. The queue is. A backlog is a record of what your product told you and what you didn’t have the capacity to do about it — a list of improvements your customers aren’t getting.

Building faster doesn’t fix it

The obvious answer is to build faster: use the tools, halve the ticket time, get further down the list. That helps. It doesn’t solve the problem, because the expensive part was never the typing. The expensive part is the distance between something happening in your product and someone deciding what to do about it — noticing, agreeing it matters, ranking it against everything else, writing it up properly, scheduling it, and only then building. Faster generation speeds up the last step in a chain whose delay lives in the earlier ones.

The advantage used to belong to whoever could build it. Now it belongs to whoever can work out what to build next, and act while it’s still true.

What changes when the loop is automatic

Now put the noticing and the acting in the same system. Software that watches how it’s being used, works out what should change, builds the change, puts it live once you’ve said yes, and then checks whether it did what it was supposed to do.

The interesting part isn’t the speed. It’s what stops being a decision. When answering something you’ve learned costs almost nothing, you no longer have to be selective about which observations deserve an answer — and the small ones finally get handled. The confusing label. The field nobody fills in. The step that takes four seconds longer than it should. None of those survive a prioritization meeting, and together they’re most of what makes a product feel good or bad to use.

There’s a second effect, and over time it matters more. Every pass leaves something behind: what your customers responded to, what they ignored, what turned out not to matter. The next pass starts from there instead of from zero. That’s the difference between software that improves and software that gets better at improving.

The first build stopped being the hard part. Treating it as the finish line is the expensive mistake now — not because building doesn’t matter, but because the version you launch is the least informed version your product will ever be. Everything you need in order to make it better arrives afterwards.