← Back to Portfolio

⚠️ Specifics such as internal metrics, customer names, architecture details, and unreleased features are omitted in line with my employment agreement. What follows focuses entirely on my decision-making process, frameworks, and approach as a PM.

PM Case Study · Oncology AI

CancerAI | Building Clinical Decision Support from Zero

How I led the 0→1 product build of an AI-powered tool for oncologists, from discovery through alpha launch.

0→1 Full lifecycle owned

Alpha Live with oncologists

Safety-First Clinical eval framework

The Problem

Oncologists managing complex cancer cases must simultaneously synthesize genomic sequencing reports, treatment history, published research, and clinical guidelines often across disconnected, legacy systems. The cognitive overhead is significant. Errors in this context aren't just expensive, they're life-threatening.

The core discovery insight: oncologists didn't need more information. They needed better synthesis, AI that could surface the right signal at the right moment in their workflow, without adding steps.

My Role

I owned the product function end-to-end for CancerAI from initial discovery through alpha launch. This spanned:

Conducting structured user research with oncologists to map clinical workflows and pinpoint high-friction decision moments
Defining product scope, the feature prioritization framework, and alpha launch criteria
Establishing a safety evaluation process for AI outputs, including hallucination thresholds and PHI compliance requirements
Driving cross-functional alignment across engineering, data science, and clinical stakeholders
Setting up the product analytics infrastructure to track activation, adoption, and session quality post-launch

Key Product Decisions

1. Safety before features

The single most important early call was establishing a formal Go/No-Go framework for alpha readiness, with explicit Hard Gates around clinical safety, hallucination rate thresholds, PHI compliance, and critical incident resolution. This was non-negotiable in a clinical setting and gave the entire team a shared, unambiguous definition of "ready."

2. Oncologist workflow, not AI showcase

Early prototypes were AI-first, impressive demos that didn't map to how oncologists actually work. I reoriented the product around the clinical decision moment: what question is the oncologist trying to answer right now, and how does this tool answer it without adding friction? This shifted us from a general assistant to a context-aware decision support tool.

3. Alpha scope discipline

With a small cohort of alpha users, the temptation was to ship broadly and iterate. Instead, I enforced strict scope, fewer features, higher confidence. The goal wasn't to impress. It was to generate usable signal about what was actually driving clinical value before scaling.

"Ship narrow, learn deep", the alpha wasn't about feature breadth. It was about getting enough real clinical interactions to validate the core value hypothesis before committing to a wider rollout.

Discovery Insights

User research with oncologists surfaced several non-obvious findings:

Time is the scarcest resource. Oncologists average 20+ patients per clinic day. Any tool that adds workflow steps even marginally gets abandoned. The product had to fit into existing moments, not create new ones.
Trust is earned incrementally. Clinicians don't adopt AI because it's impressive. They adopt it when it's consistently right on things they can verify. Starting with lower-stakes outputs and building credibility over time was the right sequencing strategy.
The casebook is the unit of work. Oncologists think in cases, not sessions. The product architecture needed to mirror this, persistent, case-organised, and built for collaboration across the care team.

AI Safety Framework

Clinical AI requires a different evaluation standard than consumer products. I built an evaluation framework that included:

Explicit hallucination rate thresholds as a Hard Gate, alpha could not progress until this was met
PHI compliance verification as a non-negotiable pre-launch requirement
Severity classification for incidents, with named owners and clear escalation paths
A human-in-the-loop design principle baked into the UX, AI surfaces options, the clinician makes decisions

Cross-Functional Execution

The science team was the most critical cross-functional dependency, and the most complex to manage. I worked to align on shared definitions of model performance, evaluation criteria, and what "good enough for clinical use" actually meant. Getting this alignment early prevented significant rework downstream.

Engineering, data science, and clinical stakeholders each had different definitions of readiness. My job was to hold a single standard across all of them without letting any one function's definition dominate.

What I'd Do Differently

Align the science team earlier. The cross-functional dependency on the science team became a blocker at a critical moment. I'd build shared working agreements, on timelines, evaluation criteria, and decision rights, much earlier in the process.
Fewer alpha users, more depth. More frequent touchpoints with a smaller cohort would have generated richer signal faster than a broader group with shallower engagement.
Instrument before you ship. Setting up analytics retroactively is painful and introduces gaps. I'd establish the full instrumentation plan before the first line of product code is written.

PM Takeaway

Building clinical AI is a different discipline from consumer product. The bar for safety, evidence, and trust is higher, and the timeline to earn adoption is longer. The PM's job is to hold that bar without letting it become an excuse for not shipping. Both things are true at once.