When Building Gets Cheaper, Check What Is Still Expensive

Updated September 26, 2026: This revision corrects my earlier claim that capacity was never the constraint. Cheaper building can remove a real obstacle; the next step is to identify what still holds the product back.

I've argued that teams often ask for more capacity when what they need is a decision. I still think that diagnosis is useful. “Capacity was never the constraint” takes it too far.

Sometimes a team knows exactly what needs fixing and cannot get to it. Sometimes a founder understands a problem and cannot afford the first version. Getting the work done is a real obstacle. Making it cheaper changes what is possible.

That deserves more than a passing acknowledgment before returning to the importance of strategy.

The question is what becomes possible for this product, and what still stands in its way.

A gain worth keeping

Consider a team with a well-understood onboarding problem. Users repeatedly get stuck at the same step. The team has observed it, agreed on a change, and knows how it will check the result. The work has simply been waiting behind other commitments.

If AI helps them deliver that change sooner, the capacity gain matters. Another workshop might add nothing.

It can also change the economics of learning. A small experiment that once needed a budget discussion may become cheap enough to try. That can produce evidence the team could not get by discussing the idea for another week.

A useful product practice has to make room for both.

What building faster cannot establish on its own

Now consider a team whose stakeholders disagree about the problem. Sales wants one customer segment. Marketing is attracting another. The roadmap contains promises to both.

Faster implementation gives that team more choices. It does not, by itself, settle which customers the business intends to serve.

AI can help investigate the disagreement, compare evidence, and challenge a proposed direction. The team still needs a decision it will act on, along with a reason to revisit it if the evidence changes.

Those two teams can look equally busy. They need different help.

Look at the work waiting to happen

Before changing the team or the process, inspect one important piece of work that is stuck.

• The problem and response are clear, but nobody can get to it. Examine capacity, missing skills, and the cost of interrupting current work.
• Several responses look plausible and the evidence is thin. Find a small test that could distinguish them.
• The evidence is available, but the decision keeps reopening. Clarify who decides, what they are optimizing for, and what would justify a change.
• Work reaches users, but the result does not improve. Check the original hypothesis and actual behavior before adding another feature.

These can overlap. Start with the one currently preventing progress rather than diagnosing the whole company from a busy backlog.

Count the costs that remain

Implementation is one part of a product's cost. People still have to review it, understand it, support it, and decide what happens when it fails. A customer still has to learn the workflow.

Some additions deserve those costs. A feature that looks inexpensive to generate may still be expensive to keep. Equally, rejecting a useful addition because “we need focus” can become a way to avoid doing necessary work.

Ask what the change will improve, how you will find out, and what it will require after launch. Then compare that with doing nothing.

The answer might be a smaller scope. It might be another engineer. It might be a short experiment or a decision somebody has been avoiding.

If the obstacle really is capacity, add capacity. The discipline is being able to explain why that is the thing to change now.