Your Prototype Made Decisions Nobody Made. Who Owns the Spec Now?

Ravi Mehta asked AI for a PRD this week and got about twenty pages back. He thought he was nearly done. Then he read it.

"Features I hadn't chosen. Assumptions I hadn't made. Decisions I hadn't reviewed." That's from his post on October 16. If he had handed the document back to AI to build, he writes, those would have become the product.

He sees the same thing with prototypes. Each one gives the team something concrete to react to. A week or two later the direction changes, and his question is the one I'd put on the wall of every product team right now: what had they actually agreed to build?

That's the PM and design question in a paragraph. When the prototype is free, who owns the spec?

This is part 2 of The Design Transition. Part 1 argued that design's job moved from the screen to the spec. This part is about the person sitting next to the designer, the PM, who can now generate the prototype before design has opened a file.

The short version

When a PM can generate a working prototype in an afternoon, the old single spec splits into two, with two owners. The PM owns the question spec: the problem, who has it, the outcome, and the one question this prototype exists to answer. Design owns the behavior spec: what the surface must never do, the acceptable range of output, the rubric, and the wrong path. The prototype is evidence for both and belongs to neither, whoever built it. The real risk is a third category, which Ravi Mehta named this week in his AI-generated PRD: choices nobody made. A generated prototype is full of them, in copy, defaults, empty states, and what it says when it's unsure, and they ship unless someone stops them. The fix is a decision ledger, not a review meeting. After every prototype, sort its decisions into three columns, and nothing in the "made by the model" column ships until an owner moves it.

I have to correct my own rule

In May I wrote Kill the PRD. The Prototype Is the Spec. The package was a prototype built in four to six hours, a one-page rubric with three to five criteria and at least twenty test cases, and a one-page README. Done is when the rubric passes, not when the doc is approved.

I still run it. But Ravi's twenty pages show me where it leaks.

The prototype is the spec only for the choices someone made on purpose. A generated prototype also carries dozens of choices nobody made. The button label. What the empty state says. Whether the summary hedges or commits. The default sort. What happens on the third retry. The model picked all of those, quickly and plausibly, and plausible is the problem. They look finished. Nobody in the room argues with a choice that looks finished, so it ships.

In the old process those choices were forced into the open, because a designer had to draw each state and a PM had to write each requirement. Slow, but every decision had a fingerprint on it. Now the fingerprints are gone and the decisions are still there.

Jakob Nielsen put the pressure behind this in his roundup on October 16: "AI can produce work faster than people can judge it." He suggests measuring the total time spent on generation, review, and repair, not generation alone. I'd add one thing. Review isn't only slow. It's aimed at the wrong thing. Teams review the prototype as a whole, react to how it feels, and never list what's actually inside it.

Two specs, two owners

So here is how I split it now.

The PM owns the question spec. What problem, for whom, toward which outcome, and the one question this particular prototype exists to answer. Uditi Sharma has the cleanest version of the boundary I've read, in her post on October 11: the PM's prototype stops when it has answered its one question. She has the PM fill in a planning card before building: the question, the result that would change the plan, the smallest build that answers it, who tests it, and a time box. Her line on the second field is sharp. If you can't fill it in, you're building a demo, not a prototype.

Design owns the behavior spec. The four sections from part 1: what the surface must never do, the acceptable range from best case to floor, the rubric dimensions, and the wrong path. That's the half that has to hold across every output the system will ever generate, not just the five the PM looked at. It's why you cannot mock a distribution, and why the rubric is the spec.

The prototype is evidence for both specs. It answers the PM's question, and it gives design real output to score. It's owned by neither.

That last part matters more than it sounds. It doesn't matter who built the prototype. A PM-built prototype isn't a PM spec, and a designer-built one isn't a design spec. Building it is just the cheapest way to find out what you don't know yet. The argument about whose prototype it is, which I've watched eat whole weeks between good PMs and good designers, goes away once nobody treats the prototype as the decision.

The ledger

The question spec and the behavior spec cover the choices people made. They don't cover the third category. That needs a separate artifact, and it's small.

After every prototype that the team is going to react to, someone lists its decisions. Not its features. Its decisions. Then sorts each one into three columns.

Answered the question. Choices that bear on the problem and the outcome. The PM ratifies these or kills them.

Behavior. Choices about what the surface does, says, refuses, and does when it's wrong. Design ratifies each one or turns it into a line in the behavior spec.

Made by the model. Everything nobody chose. This column is the point of the exercise.

The rule is one sentence. Nothing in the third column ships until an owner moves it to one of the other two.

Two things happen the first time a team does this. The third column is longer than anyone expected. And most of it is behavior, which tells you the design half of the spec was thinner than it looked.

This is also how the ledger connects to the gate. On Monday I argued, against Nielsen's advice to make designers the quality gate for PM prototypes, that the gate is the rubric, not the designer. The ledger is how unreviewed choices get to the rubric at all. A rubric scores what's on the page. The ledger makes sure the page includes the decisions nobody noticed making.

The system prompt is where this breaks

Uditi lists a few questions she hasn't settled. One of them is who owns the system prompt after handoff.

That's the right place to look, because it's where model-made choices turn into product. The prompt the PM wrote in an afternoon to get the prototype working is now carrying the product's tone, its refusals, and what it says when it doesn't know. Nobody decided those. They were good enough for a demo.

My answer is to split it by line, not by file. The lines that say what the feature is for belong to the PM. The lines that set behavior, meaning what it must never do, how it sounds, what it says when it's unsure or when it refuses, belong to design. How the prompt is implemented, versioned, and tested belongs to engineering. Every line has one owner. Contribution can be shared. The tie-break can't.

A prompt with no line-level owner is a spec written by whoever was closest to the code that night. I'd rather know who that was.

One thing to try this week

Take the last prototype your team reacted to. The one from a demo, a review, or a Slack thread full of fire emojis.

Spend thirty minutes listing every decision in it. Copy, defaults, empty states, error text, what it does with bad input, what it says when it's unsure. Sort each into the three columns: answered the question, behavior, made by the model.

Count the third column. Anything in it a user would notice gets a named owner by Friday, PM or design, and the owner either ratifies it or writes the line that replaces it.

Sources: Ravi Mehta, "Your AI wrote the PRD. Who made the product decisions?," Top 1% Builder with Ravi, October 16, 2026 (read to the paywall). Uditi Sharma, "Where does a PM's prototype stop?," Product With Uditi, October 11, 2026. Jakob Nielsen, "UX Roundup: Skewed AI Use | Reviewing AI Results | Writing & Design," section "AI Output Outruns Human Review," UX Tigers, October 16, 2026.

Part of the running argument on AI Product Management: AI collapsed the cost of the parts product teams were trained to be good at, and between the PM and design that means the prototype got free while deciding who owns each choice inside it became the work.

Related answer: Who signs off on the decisions inside an AI-generated prototype?