The ADLC Guide for Product Managers: Owning AI Projects Phase by Phase

If you manage product for a team shipping AI features, you have probably noticed that your usual toolkit — user stories, acceptance criteria, sprint-sized tickets — keeps producing arguments instead of software. The engineer asks what "the AI should summarize accurately" means. QA asks how to test something that never gives the same answer twice. Your VP asks whether it's ready, and you realize you don't have a defensible way to say yes.

The AI Development Lifecycle (ADLC) exists to fix that. It has six phases — Discovery, Framing, Architecture, Build, Eval, Production — and the uncomfortable news for PMs is that you own more of it than anyone told you.

## Which ADLC phases does a product manager own?

**Discovery is yours entirely.** Before anyone writes a prompt, someone has to answer: is this actually an AI problem? What does the current process look like? Where does it break? A useful Discovery output is a 3-lane process map: what the AI can handle confidently, what it should escalate to a human, and what it must never touch. Most failed AI projects trace back to a Discovery phase that never happened — engineering started building while the problem was still a vibe.

**Framing is where your requirements change shape.** A user story says what a user wants. An AI feature needs a behavioral contract: what the system is obligated to do, what it must never do, when it hands off to a human, what evaluation score it must clear, and what happens when it fails. Five fields. This document — call it a Specify document, an AI spec, a behavioral contract — replaces the acceptance-criteria section of every AI ticket you'll ever write. Your engineering team builds from it, and your eval suite tests against it.

**Eval is the phase your sprint plan forgot.** Traditional QA verifies behavior; eval measures a distribution of outcomes against a threshold you set *before* the results come back. As the PM, you own the threshold and the go/no-go call. If you didn't define what passing looks like before the eval ran, you'll define it after — which means you'll rationalize whatever score you got.

**Production is a shared phase, but the metrics review is yours.** Three numbers in your weekly review beat thirty in a dashboard nobody opens: task success rate, escalation rate, and whatever business KPI justified the project.

## Where PM instincts go wrong

The instinct to ship an MVP and iterate is dangerous with AI because failures are silent. A broken button is obvious; a model that started mis-routing 8% of cases three weeks ago is not. The instinct to trust a demo is worse — a demo is one point from a distribution, and the distribution is the product.

The instinct that will save you: you already know how to say no. A NO-GO verdict backed by an eval score is the most credible thing a PM can bring to a stakeholder meeting. It proves your GO verdicts mean something.

## What to do next

Write a behavioral contract for one AI feature currently on your roadmap — obligation, guardrails, handoff trigger, eval threshold, fallback. Share it with an engineer and ask one question: "Could you build from this?" Their answer will tell you exactly where your requirements practice stands.