Your AI Feature Has No DRI: Why It's Drifting Without a Quarterly Goal Owner

Walk into a quarterly business review and ask whose name is on the AI feature. Watch what happens. The PM points at the platform team. The platform team points at the research engineer who wrote the eval harness. The research engineer points at the FinOps analyst who keeps emailing about the cost graph. The FinOps analyst points back at the PM. Four people, one feature, zero owners. The eval score has been drifting downward for six weeks and nobody has triaged it because the dashboard lives in a Notion page that was last edited the day after launch.

This is the most predictable outcome of how organizations actually ship AI features in 2026. The feature was launched by a tiger team that got disbanded the moment the launch press release went out. The instrumentation was bolted on by an infra group that has no product mandate. The prompt is a prompts/v3.txt file in the repo whose blame is split across nine engineers, none of whom remember why line 47 says what it does. The user-facing tile has a PM whose OKRs moved on to the next launch two quarters ago. The feature is technically in production, technically owned, and structurally orphaned.

Every other product surface in the org has a directly responsible individual whose promotion case rests on it. The checkout flow has a name. The notification system has a name. The search ranking model — even the one that predates the LLM era — has a name. The AI feature has an org chart. That's the difference, and that's why one set of features gets better quarter over quarter while the other set drifts.

Symptoms of an Orphaned AI Feature

The drift is rarely loud. It looks like nothing for a while, then it looks like a series of small awkward facts that nobody connects until an incident review forces the connection.

A pattern I see repeatedly: the eval suite catches a regression on Tuesday. The Slack alert fires into a channel called #ai-quality that 23 people are in and none of them are paged. The alert sits for nine days. Someone finally notices in a stand-up, pings the prompt repo, and learns that an unrelated dependency bump changed the JSON-mode behavior of the model client. The fix is two lines. The latency on the fix was nine days because nobody's calendar said "if #ai-quality fires, you respond."

A second pattern: prompts accumulate TODO comments. // TODO: figure out why this still hallucinates on the medical disclaimer case. // TODO: add a fallback when the tool call returns []. The TODOs pile up because no one has the merge authority — or more accurately, no one has the responsibility — to make a call. Every change to a prompt is a low-grade product decision masquerading as a config edit, and product decisions without an owner default to "leave it as-is and add a comment."

A third pattern: an incident retro names "the AI team" as the action owner. There is no AI team. There is a platform group, a research group, a product group, and a feature flag the on-call SRE wishes someone would explain. The action item gets re-assigned three times over the next month and eventually closed as "deferred."

A fourth pattern: leadership asks for the AI feature's adoption number and three groups send three different dashboards. Product reports weekly active users of the parent feature (the one the AI tile lives inside). Platform reports raw API call volume. FinOps reports unique billing accounts that touched a model endpoint. None of these numbers measure the same thing. None of them are wrong. None of them answer the question.

If two or more of these are happening, the feature has no DRI. The org chart has been substituted for a person, and the org chart cannot make decisions, cannot be paged, cannot have a promotion case.

Why AI Features Are Especially Prone to This

Traditional product surfaces fit cleanly into one team's scope. The checkout PM owns conversion; the checkout EM owns reliability; the checkout designer owns the form. There's still cross-team work — payments infra, fraud, taxes — but the feature has a center of gravity.

AI features don't have a center of gravity by default. They straddle four functions and require all four to function at all:

• Product owns whether the feature solves a user problem.
• Engineering owns whether the feature works.
• Research / ML owns whether the model and eval harness reflect reality.
• Finance / FinOps owns whether the unit economics make sense.

Each of these functions has its own backlog, its own metrics, and its own quarterly review. If the AI feature isn't on any of their top-line OKRs, it lives in the seams. The seams are where features go to drift.

There's also a launch dynamic that makes this worse. AI features get shipped through tiger teams — small cross-functional groups assembled to push a high-stakes initiative across the line. Tiger teams are great for shipping. They're terrible for ownership transition, because the moment the launch is done, the team disbands and nobody planned the handoff. The Tempo guidance on tiger teams is explicit: define who owns the output once they disband, otherwise you've created a handoff nightmare. Most launches skip that step. The "handoff doc" is a Notion page nobody opens after week two.

The Reforge analysis of AI-native product teams puts it bluntly: organizations are still measuring people for jobs that no longer exist in their original form. The PM who shipped the AI tile is still being measured on shipping the next tile. There's no incentive structure that rewards them for the slow, unglamorous work of keeping the existing tile from rotting. So they ship the next tile, and the rot happens anyway.

The Four Numbers a Real DRI Owns

The fix is mechanical. Name a single AI-feature DRI and put four numbers on their OKR sheet. If you can't agree on a name, you don't have a DRI; you have an org chart with optimistic labels.

Loading…