AI Can Make the Wrong Problem More Efficient

AI is collapsing the distance between an idea and something technically functional. Teams can analyse information, prototype products, generate software, and automate workflows faster than before.

That creates enormous opportunity, but it also creates a mismatch that is easy to overlook. Technical execution can accelerate faster than trust, behaviour, governance, and organisational learning can adapt.

A prototype is not an implementation.

People still have to change how they work. Managers have to trust new systems. Responsibilities shift, incentives collide, and information moves imperfectly between departments. AI can compress the technical layer without automatically compressing the organisational conditions required to make a solution work in practice.

Organisations can therefore become much faster at producing solutions without becoming equally better at deciding which problems those solutions should address. A technically excellent AI implementation can still be a very expensive way of avoiding the real problem.

Consider a company where customer service costs are rising. The business case seems straightforward: automate incoming requests, reduce workload, and improve response times.

The technology may perform exactly as expected. But before committing to customer service as the optimisation target, Nick Takkenberg of Beacy seeks to understand why those requests exist. Perhaps service employees are repeatedly correcting incomplete information created earlier in the customer journey.

Automating those requests may lower service workload while making the upstream defect less visible.

Automation could still be right. But proving that the technology works is not the same as proving that customer service was the right target for optimisation.

The moment optimisation becomes the starting point, a boundary has already been drawn around what counts as the problem. If those boundaries remain invisible, an organisation can optimise something extremely well without questioning whether it selected the right target.

Make the Environment Explicit

One of the first things Takkenberg wants to understand in a complex organisation is whether people in different functions give similar answers to the same basic questions: What is the problem? What does success look like? Where does the information behind that view come from? Who owns the outcome? He prefers to ask those questions independently.

“The differences between the answers are data,” says Takkenberg.

Different answers do not prove which view is right. They show where the organisation’s shared understanding of the situation begins to break down, and therefore where further investigation may be useful. Then comes a second question: What happens if the intervention works exactly as intended?

Organisations rarely behave like isolated processes. Removing a task can remove an informal control. Improving one department can reduce information available to another. Making a symptom easier to manage can reduce pressure to fix what is producing it upstream. A local optimisation can therefore succeed while the wider system deteriorates.

The purpose is not to predict every possible consequence before acting. It is to make the relevant actors, environmental factors, assumptions, and ripple effects explicit enough that ignoring them does not silently determine the decision.

Doing that comes before committing to what deserves optimisation. It does not mean research and building have to happen sequentially.

Use Execution Speed to Reduce Uncertainty

Innovation already has language for part of this uncertainty: the fuzzy front end, the period in which the problem, opportunity, and relevant context are still being explored before a solution becomes fixed. AI does not make that phase obsolete. It changes its economics.

“As the cost of producing possible answers falls, the relative value of determining which question deserves an answer rises,” Takkenberg says.

Technical execution can now move exceptionally fast, while organisational adoption often depends on factors that do not accelerate at the same rate. A team may produce a functioning system quickly while the organisation still has to understand changing responsibilities, redesign workflows, and establish enough trust for people to use it properly. The answer is not to slow development down. It is to use that speed differently.

“Speed is useful when it accelerates learning before it accelerates commitment,” he states.

Suppose a director requests a feature while early customer interviews suggest users may not actually need it. Takkenberg would neither stop building automatically nor treat the request as validated.

The smallest intervention capable of testing the assumption whose failure would most change the direction should be built, while customer research continues in parallel. Before seeing the results, the evidence thresholds should be agreed in advance: what justifies continued investment, what stops it, and what forces the underlying assumption back into question.

Those thresholds matter because criteria become easier to reinterpret once money, reputation, and executive sponsorship accumulate around an idea. Past investment changes the environment around a decision; it does not add evidence that the original assumption was correct. “Past investment is context, not proof,” Takkenberg adds.

The thing being built is therefore not simply a smaller version of the final product. Its job is to reduce enough uncertainty to improve the next decision. Building can reveal behaviour that interviews cannot. Interviews can reveal context that usage data cannot. Both can happen in parallel and inform each other.

This gives organisations one important form of speed: speed to learn. AI can help teams create prototypes, simulations, and other probes faster, allowing assumptions to be challenged before the organisation commits heavily to implementing them.

The second form is speed to execute. That becomes valuable when the evidence is strong enough to justify the next commitment.

The mistake is not moving fast. It is using execution speed before learning speed has done enough work.

Automation Versus Augmentation Is Already Too Narrow

The same logic changes how Takkenberg looks at the debate between automation and augmentation. Both are already interventions. The question that comes before them is broader: What is actually constraining the outcome? The answer may be repetitive human effort. In that case, automation may be right. It may be poor information flow, conflicting incentives, weak governance, or a process that should not exist in its current form.

None of those problems are automatically solved by adding AI. Sometimes the constraint is a human capability that AI can meaningfully extend. That is where augmentation becomes strategically interesting. Consider a manager preparing to make a major investment. Using AI to reduce hours of preparation work is useful. Using AI to help that manager surface contradictory evidence, challenge an assumption, or recognise an important downstream consequence may create substantially more value.

The first improves efficiency. The second improves what that person can do within the decision context. Augmentation should not be treated as a less ambitious alternative to automation. If judgement, interpretation, or access to context is genuinely constraining the outcome, augmentation may be the better intervention.

But that conclusion should come after diagnosing the constraint, not before it.

Sometimes the answer will be automation. Sometimes augmentation. Sometimes redesign, better information, or removing the work altogether.

And sometimes AI was never the main problem.

Decision Architecture Before Optimisation

What Takkenberg means here by decision architecture is making the actors, environment, assumptions, ripple effects, and evidence thresholds around an important decision explicit before deciding what deserves optimisation.

The purpose is not to add another bureaucratic stage before action. It is to prevent invisible assumptions from choosing the direction on behalf of the organisation. AI gives organisations both speed to learn and speed to execute.

Those two forms of speed should not be confused. Before commitment, speed can be used to probe assumptions, compare alternatives, and reduce uncertainty.

Once the evidence is strong enough to justify the next commitment, speed can shift toward execution, implementation, and scale. That distinction becomes more important as AI improves. Technical capacity can scale rapidly; the organisational conditions required for successful adoption often cannot.

The advantage may therefore belong not to the organisations that automate the greatest number of tasks, but to those that become better at deciding what deserves optimisation before choosing whether to automate, augment, redesign, or walk away.

Takkenberg remarks, “AI can accelerate execution. The responsibility for deciding what deserves execution remains ours.”