It's 2026. And yet the word "modernisation" still gets used in board decks the same way it did in 2000 — as a euphemism for "our systems are old, we need budget, and we'd like a clean story to tell the audit committee." At the frontier where humans, AI, and technology foundations converge, this is one of the places where the gap between known and unknown is entirely self-inflicted. We know exactly what's broken. We just keep funding it the wrong way.
The tell is in the paperwork
Walk into almost any "technology modernisation" initiative and you'll find the same artefact set: a business case, a budget ask, a fixed timeline, a named set of resources, and a steering committee whose job is to supervise the project to its end date. That structure isn't neutral — it encodes an assumption: that the problem is finite, fully understood today, and solvable by a defined date. In technology, that assumption is almost never true. It was barely true in 2000. It is certainly not true now, when the underlying platforms, the regulatory environment, and customer expectations are all moving faster than any project charter can be re-baselined.
So what actually happens? The project delivers — on time, on budget, ticking every box the business case specified — and it is, by every internal metric, a success. And yet the customer experience hasn't meaningfully moved, because the business case was drafted against a snapshot of customer need that was already stale by the time funding was approved, and further stale by the time delivery landed eighteen months later. The project satisfied its own internal definition of done. It just didn't satisfy the market it was meant to serve.
Whose incentives is this actually serving?
This is the part worth saying plainly: most modernisation projects are internally incentivised, not customer incentivised. The steering committee's job is to keep the project inside its triangle — scope, time, cost — not to keep it aligned to a customer need that keeps moving. The people accountable for the project are accountable for hitting the plan, not for the outcome the plan was supposed to produce. Those are not the same thing, and the gap between them is where most of the value leaks out.
I've watched this play out in lending platforms, in digital onboarding rebuilds, in "core modernisation" programmes generally: the business case gets written once, heavily caveated, deliberately conservative so it survives investment committee scrutiny — and then it becomes gospel. Eighteen months later, the market has moved, competitor products have shipped, customer expectations have shifted again — and the newly "modernised" platform is greeted not with delight but with a shrug, because it was built to satisfy a version of the customer that no longer exists. The natural response, predictably, is to fund another project to catch up. And so the cycle repeats — each cycle further apart from the customer, never closer.
The iceberg beneath the waterline
Layer technical debt on top of this and the picture gets worse. Every project-funded modernisation tends to solve the visible 10% — the part above the waterline that a business case can point to and a demo can show. What's underneath — the accumulated shortcuts, the deferred refactors, the "we'll fix that properly next time" decisions made under project deadline pressure — doesn't go away. It compounds, quietly, until the next modernisation project inherits an iceberg it didn't budget for and doesn't fully understand. Architecture and engineering teams end up fighting the same debt repeatedly, project after project, because no project ever owned the debt long enough to actually pay it down — only long enough to work around it one more time.
Product, not Project
This is why I advocate, without much ambiguity, for a Product mindset over a Project approach — and it's worth being precise about what that actually means, because "product mindset" itself has become a slogan almost as overused as "modernisation."
A Project has a start date and an end date. Full stop. Once it ends, accountability for the outcome effectively ends with it — the team disbands, the steering committee is stood down, and whatever drift happens afterward is nobody's mandate to fix. That structure is appropriate for genuinely bounded work: migrating a data centre, decommissioning a system, a regulatory deadline with a hard compliance date. It is the wrong structure for anything that is meant to keep serving a customer.
A Product has a start date and, by design, no end date — until the product itself is retired. It has a permanent owner, not a temporary steering committee. It is funded as an ongoing capability with a roadmap, not a one-off business case with a budget envelope. Its success metric is customer and business outcome over time — adoption, satisfaction, retention, unit economics — not "delivered scope on the date agreed two years ago." Critically, it treats technical debt as a first-class, continuously funded line item, not a deferred cost that becomes the next generation's emergency. And it evolves with the customer, iterating in small increments against live feedback, instead of guessing once, upfront, and defending that guess for the next eighteen months of delivery.
What changes if you actually do this
Moving to Product doesn't mean abandoning discipline — it means relocating it. You still need governance, still need funding gates, still need measurable outcomes. What changes is the shape of the commitment: instead of committing to a fixed scope by a fixed date, you commit to a durable team, a durable roadmap, and a durable ownership of both the customer outcome and the debt that accumulates in pursuit of it. The steering committee's question changes from "did we hit the plan?" to "is this still the right thing to be building, given what we now know?" — asked continuously, not once at kickoff and once at go-live.
That's a harder sell to a budget committee that wants a start date, an end date, and a number. But it's the only structure honest about how technology, customer expectation, and competitive pressure actually move in 2026. Modernisation-as-project will keep producing beautifully executed programmes that miss the market they were built for. Modernisation-as-product is slower to sell and slower to start — and it's the only version that actually catches up, and then stays caught up.