The Backlog Trap
Why more pilots won’t get you to scale, and what a genuine transformation programme looks like instead.
Some of it worked. Some of it didn’t. What is left is a patchwork of pilots at different stages, a backlog of good ideas nobody has capacity to build, and no clear path from any of it to something running properly at scale. The instinct, understandably, is to try harder. Run another pilot. Prove the next idea works too. That instinct is the trap.
The firms who actually get to scale are rarely the ones who ran the most pilots. They are the ones who stopped running pilots at the moment it became clear the real gap was not proof, it was architecture. This guide sets out why that gap exists, why another trial will not close it, and what a genuine transformation programme looks like instead, with foundation models playing a specific, practical role rather than a buzzword one.
Why the pilot graveyard happens to good firms
A pilot is designed to answer one narrow question: can this specific idea work, for this specific case, under conditions someone has quietly made favourable. That is a legitimate and useful question. It is also a considerably easier question than the one scale actually asks, which is whether this holds up across every exception, every system, every jurisdiction and every member of staff who will ever touch it.
A firm can run twenty successful pilots and still have no path to scale, because success at pilot scale was never designed to predict success at firm scale. Each pilot proves its own narrow point. None of them, individually or collectively, proves the firm has solved the harder underlying problem.
A pilot proves an idea can work once, under conditions somebody controlled. Scale asks whether it works every time, under conditions nobody controls.
Activity is not the same as progress
A firm running several pilots at once can feel like it is moving quickly. Meetings happen, demonstrations impress, budgets get approved. It is worth asking a harder question underneath that activity: is the backlog of unscaled ideas getting smaller, or is it quietly getting longer, one promising new pilot at a time?
For many firms in this position, the honest answer is that the backlog only grows. Every successful pilot adds another idea worth scaling to a list that already had more good ideas on it than the firm had capacity to build. The pilots are not the progress. They are, increasingly, the problem.
Why one more pilot feels safe, and rarely is
Running another pilot is a comfortable decision. It requires a smaller budget, a shorter commitment, and a familiar process the firm has already run several times. None of that comfort addresses the actual gap, which is that the firm has no shared architecture capable of taking any of these proven ideas from a controlled trial into daily use across the business.
Each additional pilot, run without that architecture in place, adds one more narrow, isolated proof of concept to a pile that already has plenty. The marginal value of proving idea number twenty one is small. The cost of continuing to avoid the architecture question keeps compounding regardless.
Why nobody stops, even when everyone privately knows
It is rare for a firm stuck in this pattern to be unaware of it. Ask around privately and most people involved will admit the backlog keeps growing and the pilots keep coming anyway. The reason has less to do with the technology and more to do with how large organisations reward visible activity over patient investment.
A new pilot is an easier budget conversation than an architecture
It is considerably simpler to get approval for a contained trial with a clear end date than for a foundational investment whose benefit will not be fully visible for a year or more. Pilots are the path of least organisational resistance, which is precisely why they keep getting chosen even after their limits are well understood.
Being seen to deliver something new outweighs investing in something unglamorous
A successful pilot is a visible, presentable win for the team that ran it. Investing in shared architecture rarely belongs to one team, and its benefit shows up in other people’s future projects, which makes it a strangely hard thing for any individual leader to be personally credited for, even when it is exactly the right call for the firm as a whole.
Firms rarely lack the insight to see this pattern. They lack a structure that rewards fixing it over repeating it.
Signs you are already caught in the backlog trap
Worth an honest answer, at leadership level:
- You could list more successfully proven pilots than capabilities actually running in daily use across the firm
- Nobody can say, with confidence, how many ideas are currently sitting in the backlog waiting for capacity
- Each new pilot has been built largely from scratch, with little reused from the ones before it
- The business case for the next pilot was easier to approve than the business case for the architecture underneath all of them
- The same few, informally recognised ideas keep resurfacing in planning conversations, year after year, without ever quite being built properly
None of these signs, on their own, mean a transformation programme has to start tomorrow. Together, they describe a firm that has been proving the same underlying point repeatedly, without ever investing in the one thing that would let it stop proving and start scaling.
What actually separates a pilot from a transformation programme
| Dimension | Another pilot | A transformation programme |
|---|---|---|
| Sponsorship | A single team or department, often below executive level | Executive sponsorship with authority across every business unit affected |
| Success criteria | Did this specific case work, under conditions we controlled | Does this hold up across the real exceptions, systems and scale we actually operate at |
| Investment | A narrow point solution, built for one use case alone | A shared architecture, built to serve many current and future use cases |
| View of the backlog | Each idea treated as its own separate project and business case | The whole backlog treated as a single portfolio, sequenced deliberately |
| Governance | Informal, often added after the pilot proves promising | Built in from the outset, covering every idea the architecture will eventually serve |
None of this means pilots are wrong to run. It means a pilot answers a narrower question than the one a firm stuck in this pattern actually needs answered, and mistaking one for the other is exactly how a firm ends up with twenty successful trials and no clear route to scale.
Why foundation models change the underlying maths
The previous generation of automation, built tool by tool and task by task, made this problem worse by design. Every new idea in the backlog needed its own bespoke logic, built largely from scratch, because each point solution had almost nothing in common with the one before it. Twenty backlog ideas meant something close to twenty separate builds.
Foundation models change that arithmetic in a specific, practical way. A single foundation model provides a general reasoning capability that can be pointed at many different tasks, once it sits inside the right architecture. The heavy lifting, understanding language, reasoning through a problem, is shared across every use case rather than rebuilt for each one. What differs from idea to idea is a much smaller, lighter layer on top, the specific skill, the specific data connection, the specific context for that task alone.
Once the shared architecture exists, the cost of serving the next idea on the list drops sharply, because most of what it needs is already built. The backlog stops being twenty separate projects and starts being twenty variations on the same underlying capability.
One architecture turns a backlog into a roadmap
This is the same underlying principle behind replacing a patchwork of two hundred disconnected tools with one architecture, applied here to a patchwork of pilots instead of a patchwork of systems. Complexity, in either case, does not get solved with more complexity. It gets solved by building one thing properly beneath everything else.
With a foundation model, an agent harness, proper data and integration, real context about how your firm works, and governance built in from the start, the backlog of proven ideas stops being a list of separate projects competing for scarce attention. It becomes a prioritised roadmap of skills to add to something that already exists, each one considerably faster to deliver than the last, because the foundation underneath them is already done.
A backlog of good ideas is not a failure of imagination. It is a sign the firm has been proving value faster than it has been building the architecture to deliver it.
Sequencing the backlog once the architecture exists
Not every backlog idea deserves to be built next simply because it was proven first. Once the architecture exists, sequencing deserves the same deliberate thought as building it did.
Start with the idea that proves the architecture, not just the concept
The first capability built on the new foundation should ideally touch a real system, a real exception, and a real volume of work, so it tests the architecture itself, not just the narrowest possible version of the idea.
Weigh reuse alongside value
An idea that shares data connections or context with something already built will typically arrive faster and more cheaply than one that requires an entirely new integration, even if the second idea looks more valuable on paper in isolation.
Keep the sequence visible to everyone who contributed an idea
Much of the frustration behind a long standing backlog comes from ideas disappearing from view. A visible, honestly maintained sequence, even one that places a good idea several months out, tends to rebuild trust that pilots alone never could.
What a genuine transformation programme requires
- Name an executive sponsor with real authority. Someone able to commit resource across business units, not just within the team that happened to run the most recent pilot.
- Treat the backlog as one portfolio, not twenty proposals. Review every proven idea together, and sequence them deliberately against the architecture, rather than case by case in isolation.
- Invest in the architecture before the next skill. Build the shared foundation properly first, even though it delivers less visible progress in month one than another quick pilot would.
- Define scale success criteria before you start, not after. Agree what holding up across real exceptions and real volume actually looks like, so success is measured against that, not against the pilot’s easier bar.
- Build governance in from the first skill, not the fifth. Apply the same oversight, review and audit trail expectations to the first capability the architecture delivers as to the fiftieth.
What it looks like once the backlog starts moving
Firms who make this shift describe the same change. The backlog stops being a source of quiet frustration and starts being a genuine roadmap, each new capability landing faster than the one before it because the foundation is already in place. Pilots still happen, but as a deliberate way to explore genuinely new territory, not as the firm’s only mechanism for getting anything built at all. And the question asked of any new idea changes, from can we prove this works once, to how quickly can our existing architecture take this all the way to scale.
None of that requires abandoning everything already tried. It requires recognising that the ideas were rarely the problem. The absence of one architecture to carry them was.
