Approach

Method

Complex problems are rarely hard because of the technology. They are hard because several things are unknown at once, and nobody has separated them, ranked them and tied each one back to value for users, customers and the business.

My first move is to separate what is unknown from what is simply undecided. Undecided questions need a decision and an owner. Unknown questions need evidence, and the useful question is how quickly and cheaply we can get it: a prototype in front of real users, a retrospective analysis of existing data, an evaluation of an AI pipeline. All of that happens before anything is committed to a roadmap.

AI has made building faster and cheaper, and I use it to test ideas in days rather than quarters. But in health, cheap to build does not mean safe to ship. Experiments have to be safe for patients, trusted by clinicians and able to stand up to regulation.

The second move, and the more important one, is to agree how success will be measured before the work starts. In clinical settings this is not optional: every piece of work has to show a clear patient or clinical outcome. I have carried that discipline into consumer products, where it is just as useful and much less common.

At different scales

At System C Healthcare I was Product Director for three electronic health record products (Medway, CareFlow and Graphnet) serving more than 300,000 users. I led nine product managers and more than 200 engineers, held P&L for multi-million-pound product lines, and took the portfolio through a migration to Azure. At Simple I lead small cross-functional teams of 5-6 engineers, two designers, researcher and subject matter experts. I planned, ran and measured multiple A/B experiments weekly, using both quant and qual feedback to steer decisions. 

The scale is different; the method is the same. Teams are given problems to solve rather than features to build, they are measured on outcomes aligned to business goals and discovery and delivery run side by side.