What building a live AI product changed about transformation

Before FundRobin, I tended to think about transformation in a programme shape: diagnose the problem, design the target state, mobilise the change, implement it and track the benefits.

One BT workplace strategy made the limits of that neat sequence obvious. We modelled more than £120m of efficiencies and a reduction in the office footprint from 750 locations to 50, but the financial case was only part of the work. We also had to understand where colleagues lived, travel-time impacts, expected leavers and what the transition would do to people. The target state and the path to it had to be designed together.

Building and operating FundRobin has pushed that idea further. A live product keeps producing evidence after the decision: user behaviour, failed workflows, unexpected costs, confusing states and cases where an agent follows the instruction but still does the wrong thing for the product.

It has also changed what I mean by automation. Five years ago, much of the automation I had worked with was deterministic. My BT robotics experience was built around repeatable actions driven by known data and process parameters. The system did what the process designer had explicitly taught it to do.

An AI agent can now retrieve new information, choose among tools, reason about an unfamiliar state and perform useful work inside a set of boundaries. That expands the execution layer of transformation, but it also makes the human decisions around tools, trusted knowledge, outcomes and stop conditions more important.

Running a product made the feedback loop impossible to ignore

FundRobin is different because the system is always telling me something.

A workflow fails in a way I did not anticipate. A user asks for something that exposes a missing assumption. A background job is more expensive than expected. A feature that looks elegant in design creates confusing lifecycle state. An agent performs a task correctly but crosses an authority boundary I had not defined clearly enough.

I no longer treat those as defects to clear before returning to the transformation plan. They are evidence about the plan itself, which makes the operating system a source of strategic feedback.

That has pushed me towards a more iterative mental model:

strategy → system → behaviour → evidence → revised strategy

rather than:

strategy → implementation → adoption → benefits

The second model is still useful for governance. The first is closer to how I now experience change.

The unit of transformation is the workflow

AI has also made me much more suspicious of technology-led transformation language.

When I worked on robotics automation at BT, the useful outcome was not “we deployed RPA”. The work translated a back-office process into an automated operating model and achieved 92% efficiency across the affected offshore teams.

The same principle is stronger with AI.

Statements such as “deploy copilots”, “give everyone agents” or “automate the function” start with the capability rather than the work.

I now prefer to ask what happens to the workflow.

What information enters? Which judgement is expensive or slow today? Which steps are rules? Which require interpretation? What can happen asynchronously? What evidence should the system retain? Which exception deserves a human? What becomes the new operational metric?

Only after that do I care whether the answer involves an LLM, deterministic software, retrieval, an agent, an integration or no AI at all.

AI transformation leaders need enough systems literacy to reason below the level of the use-case slide. The strategic opportunity is in redesigning work rather than allocating AI features to departments.

Adoption is partly an architecture problem

Earlier transformation programmes taught me to think about adoption through stakeholders, incentives, communication, training and governance.

Operating AI products added another layer: sometimes people do not trust or adopt the system because the architecture gives them no reason to.

If the user cannot see why a recommendation was made, that is an adoption problem.

If a long-running job disappears behind a spinner and silently fails, that is an adoption problem.

If an AI-generated draft mixes evidence with invention and the reviewer cannot distinguish them, that is an adoption problem.

If a human is asked to “approve” an action without seeing the material facts, that is an adoption problem.

These are technical and product-design choices, but they determine whether the operating model feels trustworthy.

This has changed how I think about change management. Communication cannot compensate for a system that allocates control badly. Training cannot make opaque state feel reliable. The product itself has to embody the operating model you want people to adopt.

Governance should be designed into the flow

My enterprise work made me comfortable with governance: boards, financial reporting, portfolio cadence, approvals, decision forums.

AI-native operation made me think harder about the granularity of governance.

Traditional governance often operates periodically. A portfolio board meets monthly or quarterly. A steering committee approves a stage. A programme reports red, amber or green.

Agents can move between decision and action in seconds.

That means some governance has to become executable too.

Permissions, stop conditions, review gates, scoped approvals, budgets and audit events can be represented inside the workflow. The system should not depend on a person remembering that a policy exists in a slide deck.

This does not replace senior governance. It connects it to execution.

A leader decides the boundaries. The operating system enforces them at the point where work happens.

Faster delivery changes the economics of transformation

One of the biggest practical changes is the cost of learning.

FundRobin’s AI-assisted delivery model lets a well-scoped idea move to a working feature in roughly a week. A Showcase Trial journey, for example, required much more than a page or prompt: proposition and pricing, qualification, lifecycle state, payments, website and application changes, customer-management workflow, booking, communications, value reporting, validation and controlled release.

The speed came from combining clear product decisions with reusable architecture, AI coding agents, grounded organisational context, automated test/review loops and human release gates. It did not come from removing validation.

That makes a different kind of transformation portfolio possible.

Some questions no longer need months of analysis before the organisation can gather real evidence. A reversible idea can be tested earlier. A workflow can be prototyped with enough fidelity to expose operational consequences. The business case can evolve with production evidence rather than relying entirely on forecasts.

But faster delivery also raises the bar for prioritisation. The organisation can now create more change than it can absorb.

The constraint becomes coherence.

I now separate transformation into three systems

A framing I find useful is to think of transformation as three connected systems.

1. The decision system

This is the familiar strategic layer: problem definition, economics, priorities, target outcomes, investment and executive decisions.

2. The execution system

This is how the decision becomes work: workflows, products, agents, deterministic services, data, roles, integrations, controls and release mechanisms.

3. The learning system

This is how operations challenge the original decision: telemetry, user behaviour, exceptions, costs, failures, human overrides and realised outcomes.

Weak transformations often optimise one layer in isolation.

A strong business case with a weak execution system becomes a programme that cannot deliver its assumptions.

A strong technical implementation with a weak decision system becomes impressive work without enough business value.

A transformation without a learning system can hit its launch milestone and then slowly drift away from the outcome it was supposed to create.

AI increases the leverage available in the execution layer. That makes the quality of the other two layers more important, not less.

The leadership role is becoming more integrative

The seams between strategy, product, architecture and operations matter more when execution can move this quickly.

Someone still has to connect the economics to the workflow, the workflow to the architecture, the architecture to the control model, and the operating evidence back to the next strategic decision. That has become a larger part of how I think about transformation leadership.

Owning an AI strategy document is not enough. The job is to design the decision, execution and learning systems so that AI capability changes how the organisation actually works in a controlled and measurable way.