Complex healthcare products, without making the complexity everyone else's problem.
Clinical software has a lot of people to keep happy: clinicians, registry teams, clients, administrators, analysts, developers, governance teams and, ultimately, patients.
I led product across a portfolio of clinical registry products deployed across Ireland and international markets, translating different clinical and operational needs into software that could remain controlled, supportable and useful.
At a glance
The problem
In registry software, 'the client needs one small change' is rarely one small change.
Different programmes collect different data, run different workflows and operate under different governance requirements. If every request becomes bespoke functionality, the platform becomes harder to maintain with every client you win.
The product problem was balancing configuration with consistency: giving registries what they genuinely needed without quietly building twenty separate products.
Understanding the real workflow
Healthcare requirements often arrive in the language of the current process: a form, a spreadsheet, a field somebody has always collected.
I worked with clients and internal teams to get underneath the requested feature and understand the actual workflow, user, data requirement and consequence of getting it wrong.
That distinction matters. Rebuilding a bad manual process in software just gives you a faster bad process.
From client request to product requirement
A big part of my role was translation.
Clients knew the clinical or operational problem. Developers knew the system. I sat between them and turned the requirement into something both sides could interrogate.
For each change, that meant getting clear on:
- who needs it and why;
- what data is captured or changed;
- what the user should be able to do;
- what happens in the awkward cases;
- what is configurable versus product-wide;
- what existing behaviour could be affected; and
- what 'done' actually means.
One platform, different realities
The strongest product decisions weren't usually about adding another feature. They were about finding the reusable pattern underneath several requests.
Where possible, I pushed the product toward configurable building blocks rather than client-specific branches. That let different registries behave differently while keeping the underlying product coherent.
It also meant being comfortable telling a client that the solution they asked for wasn't necessarily the solution we should build.
Delivery where details matter
In regulated healthcare, 'we'll fix it after launch' has limits.
I owned the path from backlog through release: requirements, sprint planning, clarification, dependencies, QA, UAT, stakeholder rollout and post-release adoption.
I also worked across support, service desk, sales and client teams, because a feature isn't successfully delivered if engineering shipped it but nobody knows how to use, support or explain it.
The result
The portfolio supported clinical data products across Ireland, the EU, UK and US, including systems used in national healthcare environments.
The work reinforced the thing I now bring to almost every complex product: don't solve each request independently. Find the model underneath them.
What this project taught me
Enterprise product management is largely the art of respecting complexity without surrendering to it.
The client can be right about the problem and wrong about the feature. Engineering can be right about the technical constraint and still need to understand the business consequence. Good product work gets both into the same room, even when the room is metaphorical.