AI Development Starts with Discovery

AI Development Starts with Discovery

Why this matters

The lifecycle diagram assumes building is the expensive part. AI flipped that, so discovery moves to the front and a gate goes before build.

AI inverted the economics of product development: demos got cheap, verification stayed expensive. A case for moving discovery to the front and putting an evaluation gate before build.

Every product organization keeps a lifecycle diagram somewhere, usually in a slide nobody remembers approving. Strategy feeds discovery, discovery feeds build, and the arrows connect the boxes with the confidence of a subway map. I have drawn several of these myself, so I say this with the tenderness of a fellow offender.

The diagram encodes an economic assumption: building is expensive and knowing what to build is cheap. That held for decades. Strategy went first because engineering time was scarce, and the whole apparatus existed to ration it. Discovery’s job was to protect the build phase from bad ideas.

AI-powered features flip the economics, and the diagram hasn’t noticed. A designer paired with an applied AI partner can stand up a genuinely impressive demo before lunch. Scarcity has moved. Demos are abundant now, and the slow, hard work is knowing whether a demo is any good.

If AI demos are cheap and evals are hard, the real question is what has to be true before a prototype earns a place on the roadmap.

That question sits in discovery, so discovery goes first. In this model, discovery belongs to a small pairing: a designer and an applied AI practitioner building rapidly against real model behavior, testing directional feasibility in the actual medium. The requirements document changes personality too. It carries rubrics, acceptance criteria, failure modes, and example outputs, all pre-validated by someone who knows what the model can and cannot do. The old document said “the system shall.” This one says here is what good looks like, and here is how we will tell.

Flow diagram, “One SDLC, AI baked in”: the standard software lifecycle — Strategy, Discover, Define, Build, Launch, Improve — with an early “Does this need AI?” decision. No routes to the traditional build; Yes drops into a narrow AI DLC band (Discover, Define, Improve — the Triple Diamond, gated by offline evals and drift review) that rejoins the standard flow for rollout. A side panel lists how the route gets decided.

Then comes a define phase, where the heavier hitters arrive: evaluation strategy, golden datasets, thresholds for quality, safety, and latency written as numbers instead of adjectives. That phase is the gate. A prototype that cannot articulate its own evaluation plan hasn’t finished discovery, it’s finished a demo. Only past the gate does the standard lifecycle take over, with the considerable advantage that everyone upstream already agreed on what success measures.

Structurally, picture the standard software development lifecycle as a broad band with one early question inside it: is this an AI-powered feature? If yes, you drop into a narrow band that runs beneath the broad one and hooks back in after the gate. One system, one document. The moment this framework gets its own meetings and its own priesthood, you’ve built a second bureaucracy and solved nothing.

Diagram, “The New Triple Diamond”: three linked diamonds — Problem space (Discover), Solution space (Define), Production space (Improve) — over six numbered phases, from Applied-AI-embedded prototyping and eval-strategy definition through eval-gated sign-off to drift-triggered human review, each phase noting which roles lead and which support.

On rollout, I hold a view that makes some people flinch: ship it as a mandate. The people closest to the work built it together over months. Opening it to broad contribution now means a workshop sands every sharp edge into porridge. What the wider organization needs from a framework is clarity, and clarity is a gift you deliver whole.

The teachable part

When demos are cheap and verification is expensive, discovery earns the front of the lifecycle and evaluation becomes the gate. Run it as a lane inside your existing process, and roll it out finished.

Filed under TR The Reframe — Assumptions, examined.