Stop writing PRDs for AI features
By Ian Low
Traditional PRD-first workflows break on AI products because the behavior is probabilistic and the spec can't precede the code. The fix is to flip the order — ship the POC first, let the PM define product against running behavior, and treat the prototype itself as the spec.
Every AI product post on LinkedIn talks about how things have changed. Almost none say what to actually do differently.
Here’s mine: the PRD before the POC is a fiction. For agent products, the prototype is the spec.
In traditional software, the flow is settled: PM defines requirements, engineer builds to spec, QA verifies against the spec, ship. The PRD is the contract. Everyone aligns to it before code exists. This works because the system is deterministic. Given input X, you can specify output Y, and “done” is when output Y reliably appears.
Agent software breaks this at every step.
The PM can’t fully specify behavior because the behavior is probabilistic. They can write “the agent should help users find the right product” — and then have no way to define what “right” means across thousands of inputs. Acceptance criteria becomes subjective, and “feels right” changes day to day, person to person.
The engineer can’t build to spec because there’s no spec to build to. They’re tuning system prompts, picking tools, designing the agent’s reasoning surface — and none of that maps cleanly to “implement these requirements.” The work is closer to interaction design than to feature implementation.
The QA scope goes infinite. A response that looks correct to one reviewer looks wrong to another. There’s no oracle.
Most teams respond to this by writing more detailed PRDs. Longer documents, more edge cases, tighter acceptance criteria. This is the wrong direction. You can’t specify your way out of probabilistic behavior. The document gets longer, the team works harder, and the agent still does things nobody expected.
Here’s what works instead.
Align on a direction, then scout in parallel. PM and engineer agree on a problem area worth investigating — not a feature, a direction. “We think agents could change how users do X.” PM looks at the market: what users are doing, what competitors are trying, what the rough shape of the experience could be. Engineer looks at the technical surface: what tools the agent needs, what reasoning steps make sense, what infrastructure is missing. Both come back with sketches. That’s the entire upfront alignment.
Engineer ships a POC first. Not a polished feature. A working agent that does the thing, badly, in a sandbox. The POC is not a prototype of the spec. The POC is the spec. It’s the first concrete artifact anyone can react to.
PM defines product against running code. Now the PRD writes itself, because there’s actual behavior to evaluate. This response is too verbose. This tool selection is wrong. This recovery path needs work. These are decisions you can only make against a working system. You couldn’t have written them upfront because you didn’t know what the agent would do.
Iterate against reality, not against documents.
This is not “engineering replaces product management.” It’s the opposite. The PM role gets harder and more interesting. They stop being an architect drawing on paper and become an editor working on a live system, making product decisions in response to actual model behavior. That’s a higher-skill job, not a lower one.
The engineer role also shifts. They stop being implementers and become first-draft authors of product behavior. The first version of any agent feature is a proposal from engineering, not a delivery against a spec. That requires product judgment. Engineers who can’t develop it will get filtered out.
The teams I’ve seen move fastest on agent work all do some version of this, even if they don’t say so out loud. The teams that are stuck are usually stuck on the same thing: trying to apply PRD-first workflows to a problem that doesn’t behave the same way twice.
One ask if you’re a tech leader reading this:
This week, look at the agent feature your team is currently scoping. If you’re waiting for a PRD before the POC starts, flip it. Ship the POC first. Use the working agent as the artifact your PM reacts to. See what changes.
The PRD will still get written. It’ll just be the right PRD, written about behavior you’ve actually seen, instead of behavior you imagined.
The prototype is the spec. Build accordingly.