Running a bank's legacy data estate and a modern GCP build — in parallel, without breaking either.

The Chief Data Office serves six global divisions — CDO, Risk, Finance, Treasury, Corporate Bank, Private Bank, and Compliance. Each has its own regulatory exposure, its own appetite for change, and its own definition of "good data". The legacy platform was running BCBS 239 submissions live in production; the GCP build had to land alongside it, not after it.

Adding to the complexity: multiple development and operations partners, scrum teams distributed across three continents, and a regulator that does not accept "we were mid-migration" as an answer. The product role here is less about feature shipping and more about sequencing — what to build, in what order, with what risk, and against which divisional priority.

• Defined the data product strategy across the entire platform — balancing transformation investment (cloud, catalog, lineage) with legacy stability and regulatory obligations. Strategy grounded in business value, risk, and delivery feasibility — not technology preference.
• Owned end-to-end product lifecycle — roadmap, backlog prioritisation, acceptance criteria, release governance, and decommission planning — across BigQuery, Dataplex, Cloud Composer, Vertex AI, and the legacy on-premise estate.
• Embedded regulatory expectations into the product itself. BCBS 239 lineage requirements became platform acceptance criteria; GDPR controls became default capabilities, not downstream checks. This single shift removed an entire category of late-cycle audit findings.
• Ran demand management across six divisions — translating divisional priorities into a single platform backlog, brokering trade-offs between Risk and Finance, between Corporate Bank and Private Bank, between regulatory deadlines and architectural soundness.
• Led product capability uplift — coached BAs and POs into a unified product-owner discipline; introduced shared acceptance frameworks, dependency mapping, and quarterly OKR governance.
• Reported quarterly to executive stakeholders — defined and tracked KPIs for data product health, adoption, quality, and divisional satisfaction. Built the cadence that the executive committee now uses to govern the programme.

The instinct in a programme this size is to draw a target architecture and march toward it. That doesn't survive contact with six divisional roadmaps and an active regulator. So I worked from the other direction: start with the smallest unit of business value the platform can deliver, and sequence the architecture around it.

Practically, that meant treating each data product as a vertical slice — a divisional use case, a regulatory obligation, or a measurable cost reduction — and building the legacy and cloud capabilities only as far as the slice required. Migration happened in increments tied to outcomes, not big-bang cutovers tied to dates. The cloud architecture grew in the shape of the demand that paid for it.

It's a slower-looking strategy on a slide. In delivery, it's the only one that doesn't break the bank's reporting on a Monday morning.

The platform now serves six divisions on a hybrid architecture, with regulatory submissions, executive reporting, and divisional use cases all running against a single product roadmap.

Beyond the numbers, the work changed how the bank governs data products. Compliance is now an acceptance criterion, not an audit. Migration is treated as a sequence of business outcomes, not an IT project. And six divisions read the same roadmap.