The Constraint Was Never Capacity

A Claim I Can Finally Check

For two years, most of what I've written here has been one argument in different clothes. Adding capacity does not fix a product problem, because capacity was never the thing holding the product back.

That is an easy claim to make and a hard one to check. Every time a team added people and got slower, I could point at something else. Every time a roadmap doubled in length and shipped less, same move. None of those were clean tests. There was always something else in motion: a bad quarter, a reorg, a departure, a market shift.

A clean test needs capacity to change and nothing else to change with it.

That test now exists. It arrived faster than I expected, in a form I did not predict, and it is sitting in front of everyone reading this. Whether you run a product org that is deciding between more headcount and more contractors, or you are one person shipping real software on your own, you are running the same experiment right now.

What the Argument Was

Briefly, because relitigating it is not the point.

Adding people to a struggling team made it slower. Not slower for a week. Slower for months. Meetings multiplied, the strongest engineers stopped shipping in order to onboard, and a system that was already producing confused output produced more of it.

Adding voices made decisions worse. Eight people in a room produced a product with every feature somebody wanted and no shape at all. Everyone owned it, which meant nobody did.

Adding contractors relocated the work without touching the problem. More hands on unclear requirements is more rework, delivered on schedule.

Adding roadmap length subtracted from shipping. Twenty committed items felt like ambition and read like avoidance. If everything is committed, nothing was chosen.

The shape repeated. Those teams were not short of capacity. They were short of a decision, and capacity was the acceptable thing to ask for instead.

Then the Test Arrived

AI coding tools are capacity in the purest form I have seen anyone offered.

No hiring. No lead time. No onboarding. No budget conversation, no headcount approval, no business case, no interview loop, no ramp. One person alone can now produce what used to take a small team, at a cost that rounds to nothing and a speed I still find unreasonable.

Every practical limit on how much you can build has been removed. Not reduced. Removed.

If capacity was the binding constraint, that is the cure. Unlimited capacity, instantly available, no strings attached. Products should be improving quickly and broadly.

What Actually Happened, at Both Ends

Two scales. I want to give them equal weight, because most of what gets written about this only looks at one.

One person, building alone

The solo case is the more dramatic one, so it gets noticed first.

Someone who used to ship a small tool a year now ships continuously. Forty features where there used to be three. Every one of them works.

What they have at the end is a product that does forty things and stands for none of them. The features are individually fine. Several are genuinely good. None of them add up to a spine. Ask what the product is for and the answer runs to a paragraph, which is another way of saying there isn't one.

Nothing in that loop ever said stop. Not because the builder lacks judgment. Because judgment was never what the cost of building had been supplying. Cost supplied refusal, automatically, without anyone needing to be disciplined about it.

One company, with a team

The org case is quieter, and I think far more common.

Output goes up. Really does. The team closes more per sprint than it did a year ago. Engineers spend less time on the mechanical parts. On any dashboard you care to build, the line moves the right way.

And the roadmap is still not a set of choices. It is still the list of everything everyone wanted. The same three features are contested in the same meeting they were contested in last quarter. The decision that was open in March is open in August. What changed is that the team now delivers more of an undecided plan, faster.

Different scale, identical shape: output went up and deciding did not.

Where I Was Wrong

The conclusion held. The explanation I attached to it did not, and that bothers me more than it probably should.

For years, when I said more people makes it worse, I reached for coordination cost. Communication overhead. Meetings, handoffs, context loss, the n-squared problem. That is a real effect and I leaned on it heavily.

But a person building alone with AI has almost no coordination cost. No handoffs, no standup, no onboarding, one head holding the whole context. If coordination overhead was the mechanism, that setup should come out clean. It does not. It produces the same shapeless product the eight-person committee produced, faster, with better commit messages.

So coordination cost was a symptom. I had been describing what the failure looked like and calling it the cause.

Two other things I did not see coming. I assumed this test would take a decade and would land on companies first, since companies are where capacity normally gets purchased. It took about two years and landed hardest on individuals, who never had a procurement process slowing them down. And I assumed the failure would announce itself. It mostly doesn't. Shipping a lot feels like health, right up until someone asks what the product is.

The Constraint Was Doing Work Nobody Credited It For

Underneath both versions is the same thing, and I think this is the part that matters.

Each of these readers had a constraint quietly performing a job nobody had named.

For the company, it was budget cycles, hiring lead time, and the argument you had to win to get a team at all. Before you could build the thing, you had to convince someone it mattered more than the other thing. That argument was the prioritization. It happened in a room labeled finance, which is why nobody filed it under product.

For the person building alone, it was the raw cost of building anything. A month of evenings per feature is a brutal filter. You only spent that on things you were reasonably sure about.

Neither of those was a good mechanism, and I am not being nostalgic here. Budget gatekeeping is arbitrary and political, and it funds the loudest sponsor rather than the best idea more often than anyone admits. The cost of building has kept enormous numbers of people from making anything at all, and its collapse is a genuinely good thing that I would not reverse if I could.

They were bad mechanisms performing an essential function. They forced a choice.

Remove a bad mechanism and the function it was quietly serving does not move somewhere else. It just stops. Nothing announces the gap. You feel faster, because you are, and the thing that used to make you choose is simply no longer in the room.

What Has to Exist Instead

Not a role. A function, and it has to live somewhere specific.

The part of product work that survives all of this is the part that says no in January and still means it in June. Not refusing once, in a planning session, with a framework. Refusing again when the idea comes back with a better argument and your own enthusiasm behind it.

That function can take a few forms:

• A person with the standing to decide and enough at stake to care about being wrong.
• A process that makes cutting something the price of adding something, so the list cannot only grow.
• A rule you hold yourself to, which is the hardest version, because you are also the one arguing against it.

The form matters much less than whether it exists at all.

Both readers have the same work here, and neither has the easier job. The company has more people who could hold that line and more reasons that nobody does. The person building alone has complete authority and nobody to hold it against. The failure looks different from the outside and is identical underneath.

The absence of this function is invisible for a long time. You find out when someone asks what your product is for and you need a paragraph.

---

The bottom line: I spent two years arguing that capacity was never the constraint on good products. AI has now removed capacity as a constraint almost entirely, for large teams and for people working alone, and products are not improving at anything close to the rate output is. The problem was never how much you could build. It was always what you were willing not to.