When building gets cheaper, judgement gets more expensive

One of the most obvious effects of AI coding tools is that it is becoming cheaper to turn an idea into working software.

One of the least useful conclusions is that this makes prioritisation less important.

I think the opposite is happening.

When building becomes cheaper, an organisation can entertain many more plausible ideas. The scarce resource shifts from implementation capacity towards judgement: deciding which problem deserves attention, how far to take an experiment, and when the correct decision is to stop.

I have seen the opposite constraint

Earlier in my career, I worked on product and portfolio strategy at BT. One piece of work involved creating a group-wide view across roughly £24bn of products. I mapped 140 products, built a fully loaded shadow profitability model and combined the economics with lifecycle analysis to inform decisions around investment, continuation and closure.

Another project simplified the strategic broadband product set from 465 variants to 26 as the business moved towards FTTP and PSTN closure.

These were not exercises in making the organisation build more.

They were exercises in making trade-offs visible.

Large organisations accumulate products, variants, processes and local optimisations because each decision can make sense in isolation. The portfolio becomes incoherent gradually. Complexity has no single owner, so it grows until someone creates a reason to remove it.

The underlying lesson stayed with me: the value of a portfolio model is not the model. It is the quality of the decisions it forces.

AI creates an option explosion

FundRobin gives me the other side of the problem.

Using AI-assisted delivery, a well-scoped idea can move from problem definition through architecture, implementation, testing and a working feature in roughly a week. The product is operated across several workstreams with extensive use of coding and operational agents, while I retain product direction, architecture, trade-offs and final validation.

That changes the economics of experimentation.

Features that would once have required a long queue, a larger team or a meaningful external budget can now be explored much more quickly. You can test an onboarding variation, a new internal workflow, a content process or a product capability before the organisational energy required to discuss it would previously have been justified.

This is powerful.

It is also dangerous because feasibility starts masquerading as priority.

The question “could we build this?” has lost some of its filtering power.

The budget generator we chose not to build

One FundRobin example made this concrete for me.

A grant-budget generator would be easy to build with AI. Give a model some organisational context, the funding opportunity and a set of assumptions and it can produce a plausible budget in seconds. Technically, we could have shipped a first version quickly.

We chose not to.

The problem was not whether the model could generate numbers in a table. The problem was that a generic budget would undermine the reason for using contextual AI in the first place.

Different organisations build budgets differently. They use different templates, terminology, cost categories and reporting structures. The budget may need to align with how Finance already works, how trustees review spend, how a funder expects costs to be presented and how the organisation later reports against the award.

Without understanding those workflows, a generated budget can look professional and still be useless.

The next step is customer research, not a more elaborate prompt. We need workshops that show us how organisations create budgets today, where the pain actually sits, what they need to preserve and what a materially better workflow would look like.

That decision captures the distinction I care about. AI made the implementation cheap. It did not make the product judgement cheap.

Every cheap feature creates a long tail

The implementation of a feature may be cheap. Its existence is not free.

Every new capability can create:

• another user expectation;
• another state to support;
• another data dependency;
• another place for permissions to matter;
• another surface to test when upstream systems change;
• another metric that needs interpretation;
• another support path;
• another thing that future agents and humans need to understand.

This is the part that rapid prototyping culture can hide.

A demo can be deleted. A feature that users rely on becomes part of the operating system.

The lifetime cost of a decision therefore matters more than the first implementation cost.

I now try to separate three questions that can otherwise collapse into one:

1. Can this be built? Technical feasibility.
2. Can this be operated? Reliability, support, data, controls and maintenance.
3. Should this exist? User value, strategic fit and opportunity cost.

AI is making the first question easier at extraordinary speed. It does much less to answer the third one for you.

A faster test should produce a faster kill decision

Lower build cost does create a genuine strategic advantage when it changes how evidence is gathered.

If a question can be tested cheaply, the organisation should not need the same level of confidence before the test. That is a good thing. It reduces the pressure to make a perfect prediction in a slide deck.

But cheaper experiments only improve decision quality if the team is willing to kill ideas after the evidence arrives.

Otherwise “test more” becomes “accumulate more”.

For me, a useful experiment should begin with a decision boundary:

• What are we trying to learn?
• What would make the idea worth taking further?
• What would make us stop?
• Which parts of the implementation are deliberately temporary?
• What would have to change before this becomes a production commitment?

Those questions make experimentation cheaper and more disciplined.

Without them, AI can accelerate an organisation’s ability to create technical debt and product clutter.

Acceptance criteria protect against enthusiastic building

I have also become more explicit about acceptance criteria before implementation starts.

This is partly an engineering habit, but I use it as a product-management tool.

If the objective is “make onboarding better”, almost any polished change can be rationalised as progress. If the objective is “reduce the path from a qualified user to a first useful outcome without losing the profile information or control points the system depends on”, there is something to test against.

Clear acceptance criteria do two things.

First, they give agents and implementers a sharper target.

Second, they give the product owner a reason to reject attractive work that does not solve the intended problem.

That second function matters more when the cost of generating another implementation is low. The ability to say “this works technically, but it does not satisfy the product decision” becomes a core operating skill.

Product judgement is not taste

“Judgement” can sound vague, as if the answer is simply to have better instincts.

I mean something more concrete.

Good product judgement combines several forms of evidence:

• user pain and behaviour;
• strategic relevance;
• economics;
• technical and operational consequences;
• reversibility;
• opportunity cost;
• the organisation’s ability to support the resulting complexity.

My strategy background makes me particularly sensitive to the economic and portfolio dimensions. Building FundRobin has added a much more immediate understanding of operational consequence. A decision that looks small on a roadmap can touch database state, payments, customer communications, automation, measurement and support.

That changes how I evaluate “small” features.

The strongest use of AI may be tighter decision loops

The conversation about AI-assisted software often centres on output: more code, faster code, more features per engineer.

I think the more strategic opportunity is a tighter loop between hypothesis and evidence.

A team can move from:

idea → lengthy prioritisation → business case → queue → build → learn much later

closer to:

problem → bounded hypothesis → cheap test → evidence → commit, change or kill

That is not a licence to bypass governance or good architecture. The degree of production discipline should increase as the experiment creates external consequences.

But it can reduce the amount of strategy that is forced to operate as prediction.

When the test is cheap and reversible, learn from reality earlier.

Scarcity has moved, not disappeared

Technology repeatedly moves the bottleneck.

Cloud reduced the need to own physical infrastructure. Modern software platforms lowered the cost of many standard capabilities. AI is reducing the cost of producing analysis, content and increasingly implementation.

None of those changes abolish scarcity. They move it.

In AI-native product delivery, I see the scarce resources becoming clearer:

attention, coherent context, decision quality, trust and the willingness to remove what no longer deserves to exist.

That brings me back to portfolio strategy.

When build cost was high, prioritisation decided where scarce implementation capacity went.

When build cost falls, prioritisation decides which of an exploding number of possible systems should be allowed to become part of the organisation at all.

Product judgement becomes more valuable as implementation gets cheaper. More people can build; the harder responsibility is still deciding what deserves to exist and what should be left alone.