The Practitioner's Pivot: From Regulatory Leader to AI Product Builder

The Moment the Question Changed

For most of a twenty-year career inside tier-1 financial institutions — leading regulatory transformation programmes, managing multi-million-dollar change portfolios, building governance frameworks for global banks — the relationship with technology was well-defined: technology was commissioned, not built. Leaders provided the problem definition, the business context, the stakeholder alignment. Engineers built the solution.

Then generative AI arrived and made it genuinely possible for a non-engineer to build production-grade software. The question stopped being "What should we build?" — which had always been a leadership question — and became something more uncomfortable: "Can you build it yourself?"

The honest answer, at the time, was no.

The Decision

The transition wasn't an accident. It was a deliberate programme of work, designed the same way any enterprise initiative would be: with a clear problem statement, defined scope, success criteria, and a non-negotiable delivery cadence.

Problem statement: The most valuable AI practitioners in the next decade will not be those who advise on AI from the outside — they will be those who have shipped real products, encountered real constraints, and learned from real failures. Advisory credentials age quickly. Deployed products don't.

Scope: Build seven commercial-grade AI applications, each solving a documented workflow problem, each brought to production. Not prototypes. Not demos. Products that a real user could open in a browser and get value from today.

Success criteria: Live deployments. Real users. Documented workflow impact.

What Enterprise Experience Transfers

What became clear within the first weeks of building was that the skills that seemed least relevant to product development were, in fact, the ones that mattered most.

Requirements Engineering as Product Definition

Two decades of translating complex regulatory mandates into delivery programmes is, at its core, requirements engineering. The discipline of asking: What is the actual problem? Who has it? What does a solved state look like? What are the constraints? — this is identical whether the output is a regulatory control framework or a software product.

Every product in this portfolio began with a one-page problem brief — not a feature list, not a technology choice, but a brief: who is struggling with what, why existing solutions fall short, and what a minimum valuable outcome looks like. Products built without this discipline collapse on contact with real users. Products built with it don't.

Governance Discipline as Product Management

Programme governance — RAID logs, escalation frameworks, milestone cadences, stakeholder communication — maps directly to product management. Sprint planning is milestone tracking. A backlog is a risk register for unbuilt features. The discipline of making prioritisation decisions explicit, keeping stakeholders aligned, and communicating status with precision: these are governance skills, and they transfer without translation.

Risk Thinking as Quality Engineering

Twenty years of enterprise risk management develops a specific instinct: the habit of asking "What could go wrong, and when would we know?" before committing to a path. Applied to AI product development, this instinct produces a materially different class of product — one that handles edge cases, communicates uncertainty clearly, fails gracefully, and doesn't promise what it cannot deliver.

Most AI products fail not because the underlying model is wrong. They fail because the product design doesn't account for when the model is wrong. Enterprise risk thinking closes that gap before the first line of code is written.

What Had to Be Learned

Intellectual honesty requires acknowledging what was genuinely new territory.

Frontend engineering. Building interfaces from scratch — component architecture, state management, responsive design — had no prior foundation. Early products were rough. Later products were considerably more refined.

LLM orchestration. Knowing that language models are powerful is different from knowing how to prompt them reliably at scale, manage context windows under real-world conditions, and build systems that don't degrade when the model behaves unexpectedly. This required production failures and iteration.

Infrastructure and operations. Deployment pipelines, environment management, API security, rate limiting, cost management — the operational layer of a product is invisible until it breaks. Learning this in production, with real users, is an education no course or certification replicates.

The Products Shipped

Seven products were built and deployed to production:

• MedConsult AI — Clinical decision support for healthcare practitioners: synthesises medical literature, surfaces differential diagnoses, and structures treatment pathway analysis for complex cases.
• Business Idea Validator — 13-agent AI platform that stress-tests startup ideas against market viability, competitive dynamics, and execution risk in minutes rather than weeks.
• ERIS Pro — Enterprise regulatory intelligence system that monitors regulatory developments, surfaces relevant changes, and translates them into operational implications for risk and compliance teams.
• RegTwin AI — A regulatory digital twin: an AI-powered conversational interface holding full context of an organisation's regulatory obligations, answering practitioner questions in natural language.
• Resume Builder — AI-assisted resume construction that translates career history into tailored, role-optimised documents for professionals navigating competitive job markets.
• AgentPMO — Autonomous AI project management office: monitors delivery health, generates status intelligence, surfaces risks, and flags decisions requiring human intervention.
• BISO — Business intelligence and strategic operations platform combining market intelligence, competitor tracking, and executive briefing generation.

What the Portfolio Proved

Each product validated a specific hypothesis. The aggregate validated something larger: the most useful AI products are not built by people who love technology — they are built by people who understand problems deeply enough to know exactly what the technology needs to do.

Enterprise experience is not a handicap when building AI products. In the right hands, it is an unfair advantage.

What This Changes

The practitioner who can lead enterprise transformation and build the tools to enable it occupies a position that did not exist five years ago. The advisor who has never shipped a product is losing credibility with every cycle. The engineer who has never sat in a regulatory review is building solutions for problems they don't fully understand.

The future belongs to practitioners who build — and builders who have navigated real enterprise complexity. This portfolio is the proof of concept.

More case studies