Strategy is becoming executable

At BT, I worked on a B2B 5G opportunity that began with a familiar strategy problem: there were many plausible use cases and no obvious place to bet. I ran workshops with more than 60 colleagues, built a prioritisation framework, narrowed the field to six use cases, developed the propositions with a small cross-functional team and built the business case with Finance. The resulting opportunity was estimated at about £800m over five years.

The useful part of that work was turning a broad technology possibility into a small number of decisions with economics and a path to execution.

For much of my career, there was still a clear seam after that point. Strategy made the decision; delivery turned it into a working system.

Building FundRobin has narrowed that seam. A well-scoped idea can now move from problem definition through architecture, implementation and testing to a production feature in roughly a week. AI coding agents do much of the implementation under my direction, while I retain the product choices, architecture, trade-offs, validation and release decision.

What has surprised me is where the compression stops. With good documentation and foundations, AI can be very capable at implementation and can contribute to architecture and security review. It is much less useful at deciding what the customer actually needs, which information should be trusted, what trade-off is sensible, or what “good enough” means in practice.

That makes the strategic specification more important. When execution gets cheaper, vague decisions can become vague systems much faster.

The strategic artifact is changing

I increasingly think a useful AI-era strategy needs to contain more than a target state and a roadmap. It should make the operating logic explicit enough that the next layer can execute without re-litigating the core decisions.

For a product or transformation initiative, I want to know:

• What problem are we actually solving?
• Which user or business outcome matters?
• What evidence supports the priority?
• What is deliberately out of scope?
• Which decisions are rules and which require judgement?
• What data or organisational context is authoritative?
• Which tool or system is appropriate for this part of the work?
• What can an agent or automated workflow do without asking?
• Where is human approval required?
• What constitutes completion, and who decides what is good enough?
• What evidence would cause us to change course?

Those questions look partly like product requirements, partly like operating-model design and partly like governance. That is the point.

As agents become capable of acting on a decision, ambiguity that used to be absorbed by layers of meetings and interpretation can turn directly into execution risk.

Strategy needs acceptance criteria

One of the habits I have borrowed from software delivery is the idea of acceptance criteria.

A strategic recommendation often says what the organisation should do and why. An executable recommendation also needs to describe what “done” means clearly enough that an implementer, human or agent, can test whether the outcome exists.

Consider a simple instruction: “improve the onboarding journey.”

That could produce almost anything.

A more executable form might say: shorten the path from qualified signup to first useful match; preserve the required profile information; make the lifecycle state observable; prevent matching before the required readiness conditions are met; keep commercial activation explicit; validate the complete journey in staging before production.

Now there are boundaries. There are conditions. There are things that should fail rather than silently proceed.

That level of specificity does not mean a strategist should dictate code or remove discretion from the implementation team. It means the decision has enough structure to survive translation.

I find this particularly important with AI agents because they can execute a poorly framed instruction with remarkable speed and competence. Human teams often slow down when something is ambiguous. An agent may confidently fill the gaps.

The result can be high-quality work on the wrong problem.

Governance has to move with the work

If strategic instructions can move directly into execution, governance cannot remain a distant review ceremony.

The authority to recommend is different from the authority to change a website, update a database, publish content or submit something externally. In FundRobin’s AI-assisted operating model, I have become much more explicit about those boundaries.

A plan is not permission.

An agent can have enough capability to perform an action without having the authority to perform it. Approval should be scoped to the action being authorised, the system it can affect and the evidence required afterwards.

This resembles conventional organisational governance more than it resembles science fiction. Good companies already separate decision rights, delegated authority, controls and audit. Agentic systems make the same questions more concrete because the gap between instruction and action can become seconds rather than weeks.

The strategic operating model therefore has to answer two questions: what should happen? and who or what is allowed to make it happen?

Faster execution increases the value of saying no

There is a seductive interpretation of AI-native delivery: because more can be built, more should be built.

My earlier portfolio work makes me sceptical of that conclusion.

When I worked on BT’s product portfolio, much of the value came from making trade-offs visible. A portfolio is full of locally sensible investments that are collectively incoherent. The job is to decide where capital and attention create the most value and where complexity should be removed.

AI does not remove that problem. It intensifies it.

If implementation becomes cheaper, the organisation acquires more options. Options are useful, but they create a larger prioritisation problem. Every new workflow still creates maintenance, user expectation, data dependencies, controls and operational surface area.

“We can build it quickly” is not a business case.

The scarce capability becomes judgement about which changes deserve to exist.

Strategy can become a learning loop

The most significant change for me is that strategy and operation can now sit in a tighter loop.

The old mental model is roughly:

analyse → recommend → hand over → implement → measure

The model I increasingly work with is:

observe → decide → specify → execute → validate → measure → decide again

The difference is not cosmetic. The strategist can remain much closer to the evidence produced by the system.

A production workflow tells you where users struggle, where jobs fail, what costs more than expected, where humans override the automation and which assumptions were wrong. Those signals are strategic inputs, not just operational telemetry.

This is where building FundRobin has changed how I think about transformation. I used to see implementation primarily as the stage where a strategy had to survive reality. I now see implementation as a continuous source of evidence that should reshape the strategy.

Leaders can stay closer to execution

Complex systems still need deep engineering, design, security, legal, commercial and domain expertise. In my Capgemini work, a large part of the job is bringing specialists together around a coherent client problem. FundRobin has changed how close I can stay to the implementation without pretending to be the deepest specialist in every layer.

I can spend more time shaping the architecture, reviewing evidence, testing trade-offs and seeing where the system fails. That shortens the feedback loop between intent and outcome.

For me, that is what strategy becoming executable means: the distance between a decision and evidence of whether it works is getting much shorter. Leaders should change how they make decisions when they can learn from the implementation this quickly.