A system can work. A process can follow every control. A dashboard can light up green across the board.
And still—the customer can walk away frustrated.
That’s the danger of designing transformation from the inside out. You tick all the internal boxes, but you fail to deliver what matters on the outside: experience, clarity, insight, ease.
In the programmes I’ve led, one principle has consistently shaped our success:
We design from the customer inwards.And when we do, everything—from the data model to the platform architecture—starts to align.
Here’s what that looks like in practice.
Lesson 1: Start with the Experience, Not the Org Chart
One of the most common design mistakes I’ve seen is building transformation around the organisation’s structure. You get systems that mirror divisions, workflows that preserve historical silos, and touchpoints that frustrate users who just want a simple outcome.
Customers don’t care who owns the system. They care that it works.
In our onboarding transformation, we didn’t start with process maps—we started with pain points. Why were customers being asked for the same document multiple times? Why were onboarding journeys duplicative, unclear, or slow?
The answer was simple: the experience wasn’t designed with them in mind. It was designed to fit internal swim lanes.
We flipped the script. We asked: What does a great onboarding experience look like? What would the customer see, feel, expect? And then we built backwards from that. The systems, data, and processes all followed the experience blueprint, not the other way around.
Lesson 2: Design the Data to Reflect the Customer, Not the Product
In one large-scale onboarding transformation I led, the symptoms looked familiar: delayed activations, frustrated customers, repeated document requests, and internal teams blaming the process.
But the root issue wasn’t the process. It was the data model.
We didn’t have an onboarding problem. We had a data model design problem. What we needed was a customer-centric data model.
Every product line had its own definition of a customer. Each system stored them differently. The result? Fragmented identities, duplicated effort, and inconsistent service.
We couldn’t fix the customer experience until we redesigned the data model to represent the customer—not the products they held, nor the internal systems that managed them.
Meanwhile, during the Finance & Data Transformation Programme across 12 countries, we were redesigning the Chart of Accounts (CoA) as part of a broader effort to enable consolidated insights.
“You can’t compare apples with pineapples. You need to compare apples with apples—with apples.”
That was a phrase I used often. Because standardisation across subsidiaries and business lines wasn’t just about harmonisation—it was about creating a data foundation for truth and insight.
Every country had the same CoA. Every transaction flowed into a shared data lake. And because of that, we weren’t just processing data—we were building enterprise-level insight pipelines.
Whether the goal is onboarding or enterprise finance visibility, the same rule applies:
You can’t get to intelligent outcomes if you don’t design intelligent inputs.
Lesson 3: Architecture Is Not Just Systems—It’s How You Move
We’ve all seen organisations that confuse architecture with technology stacks. But true architecture isn’t just what you build—it’s how everything connects, flows, and operates at scale.
It’s about governance, orchestration, and intentional movement.
In the programmes I’ve led, we didn’t just implement tools. We designed:
Integration hubs to streamline end-to-end transactions
MIMO (Money-In-Money-Out) automation to remove manual bottlenecks
Data lakes that served as shared intelligence hubs
Real-time pipelines from source to insight
ERP-aligned financial and operational structures to ensure scale, traceability, and control
Architecture must be designed with motion and accountability in mind.Because when systems are connected properly, the organisation can move quickly, intelligently, and without the noise.
Lesson 4: Simplicity Is Built for the User—Powered by Complexity Behind the Scenes
Simplicity is one of the most misunderstood principles in transformation. Too often, it’s mistaken for minimalism. Fewer systems. Fewer options. Fewer layers.
But real simplicity? It’s about clarity for the user—and that often requires serious complexity behind the scenes.
Take onboarding, for example.
To make it easier for customers, we designed a front-end journey that felt seamless. But under the hood, it was connected to multiple systems—sometimes even government databases—to pull through the right data at the right time, reduce duplication, and shorten decisioning cycles.
The result? A journey that felt simple, even though it was architecturally sophisticated.
That’s the essence of good design:
Make it feel easy for the user, no matter how hard it was to build.
This applied across finance, reporting, and operations too. Wherever complexity was forced onto users—manual reconciliation, duplicate entries, unclear approvals—we absorbed that into the design.
Our rule was simple:
If someone’s struggling with the process, the process is broken—not the person.
Simplicity is not what you take away. It’s what you build in—to make clarity effortless.
Lesson 5: Design to Empower, Not Just to Control
Great design doesn’t just centralise—it empowers. It gives local teams, subsidiaries, and users ownership without chaos.
That was our approach across the 12-country footprint at Old Mutual. We weren’t rolling out a solution to countries—we were building a platform with them.
Through matrix delivery, we made sure every country had:
Local input into requirements
Shared visibility on progress
Ownership of performance
Tools to operate and adjust without escalating every issue
When people feel like co-creators, not recipients, they engage with pride. They don’t resist—they contribute. And that’s when platforms move from project mode to business reality.
Design isn’t about locking people down. It’s about giving them the tools and trust to deliver well.
Final Reflection
Design isn’t just an early phase in the project plan. It’s a philosophy that echoes all the way through to operations, insight, and experience.
If you design for departments, you’ll get silos.If you design for compliance, you’ll get process without performance.But if you design for experience, insight, and empowerment, you’ll build something that serves—and lasts.
We didn’t just design to digitise.We designed for insight, for integrity, and for action.
Because that’s what the customer experiences. That’s what the business needs.And that’s what great architecture makes possible.