The Quality Owner

The Story

In 2012, MD Anderson Cancer Center partnered with IBM to build Watson for Oncology — an AI system that would help doctors recommend cancer treatments. The partnership had everything: a world-class hospital, a marquee technology partner, elite oncology specialists training the system, and significant institutional commitment.

Five years and roughly $62 million later, the contract expired. Watson for Oncology was never used on actual patients at MD Anderson. Separately, reporting based on internal IBM documents revealed the system recommending unsafe treatments — including prescribing a chemotherapy drug with a severe bleeding warning to a patient who was already bleeding.

The team had research expertise. They had clinical champions. They had vendor support. They had executive sponsorship. What they didn't have was an empowered deployment owner who could ask the questions that would have changed everything.

Every stakeholder owned a piece of the project. Nobody owned the operational truth of whether this system was fit for purpose.

The Core Idea

There's a question that surfaces early in every AI product — usually as a vague discomfort rather than an explicit conversation: "Who decides what 'good enough' looks like?"

In traditional software, acceptance criteria are functional and observable. The checkout flow processes the payment or it doesn't. Quality is binary and rarely subjective. In AI products, quality is almost always subjective, contextual, and multi-dimensional. Someone has to define what "good" means across all of these dimensions. And that definition isn't a technical decision — it's a product decision.

This isn't just good practice. It's increasingly a regulatory requirement. Four frameworks are converging on the same conclusion: NIST AI RMF says AI risk roles should be "documented and clear." The EU AI Act requires deployers of high-risk systems to assign human oversight to people with "competence, training, and authority." SR 11-7 requires "sound governance" and "effective challenge." Microsoft's Responsible AI Standard requires impact assessment, release criteria, evaluation plans, and approvals.

The PM is the natural quality owner because they're the only person who holds all three circles simultaneously. Engineering can build the eval system — the infrastructure, the pipeline, the automated judges. But they can't write the criteria. They don't know whether the financial advisor should prioritize tax implications over portfolio diversity for high-net-worth users.

Domain experts can define what a correct answer looks like. But they can't tell you what the business can afford. Business leaders set the risk tolerance and cost constraints. But they can't tell you which response patterns frustrate users versus delight them.

There's a practical discipline that makes ownership concrete: the PM reads raw outputs personally. Not a dashboard summary. Not an aggregate metric. The actual AI responses that users see. A minimum of 100 outputs before writing any evaluation rubric, and at least 20 outputs per week after that to keep calibration fresh.

When reviewers disagree about whether a response passes or fails — when Legal says one thing and Sales says another — one person with the full context makes the call. That call becomes ground truth. This is the "benevolent dictator" pattern: not a committee, not a vote, but one person who holds customer, domain, and business context making a binary decision.

Where This Hits in Production

In regulated industries, ownership must be split — not vague. The EU AI Act requires human oversight by people with competence, training, authority, and support. SR 11-7 requires "effective challenge" by objective, informed parties. In practice: one accountable surface owner (the PM) plus independent validators (model risk office, compliance, legal).

Multi-tenant systems turn one owner into a federation. In enterprise B2B, one product often serves multiple customers with different contracts, compliance requirements, and risk tolerances. The golden dataset must carry tenant metadata so evals can be sliced by customer.

Connecting the Dots

Here's the reframe that hit hardest while working through this material: the eval scoring function IS the modern PRD. Think about a traditional PRD from 2015. An unstructured document. The engineering team reads it, half follows it, the final product never matches. Now think about an eval: a dataset of inputs, a task function, and a scoring function that quantifies whether the software works. When the eval passes and the product still feels wrong, that's on the PM — the scoring function doesn't capture what matters.

The best PRD in 2026 is not a document. It's a dataset, a task function, and a scoring function the whole team can run.

Remember This

1. If nobody in the org can say "I own the pass/fail bar for this AI surface, I own the eval suite, and I can stop the launch" — nobody owns quality. It's not a shared responsibility problem. It's a missing accountability problem.

2. The PM is the natural quality owner because they're the only person holding all three circles: what users need, what the domain requires, and what the business can afford.

3. Read 100 raw AI outputs before writing any rubric. You can't define quality you haven't experienced firsthand.

In Practice: The Ownership Manifest

Here's what quality ownership looks like when it's operationalized — not as a process document but as infrastructure. The PM defines three things that nobody else can.