I Wrote My First PRD This Year

There is a folder in my repository from last week with seven documents in it. All seven describe the same piece of work.

It was not a complicated feature. One component had grown too large and needed to be broken into smaller pieces. I wrote the document, the agent did the work, and the result was correct and also not finished. So I wrote the next document. Then the one after that. Across four days I re-specified that one refactor seven times, and by the end the component had gone from a thousand lines to eight hundred and the thing kept coming back.

The code was never the problem. Not once. Every single time, the problem was the document.

Somewhere in the middle of that I noticed something that I have not been able to put down since. I have sat in almost every product seat there is, product owner, head of product, CPO, and I had never written a real PRD in any of them. Not one. Nobody ever asked me for one either. And now I write them most weeks, and the reader is a machine.

The Document Was Never for the Engineers

Ask a product manager who the spec is for and you get the answer I would have given without thinking. Engineering. They need to know what to build.

Where I worked, that was never really true. The developers who built my features got their understanding from being in the same rooms I was in. They heard the customer say the thing, in the customer's own words. They watched me be confidently wrong about something and walk it back twenty minutes later. By the time anything was written down, the shared picture already existed in four or five heads, and the document mostly existed so people who had not been in that room could follow along.

That has a consequence nobody names. It means the spec could be radically incomplete and nothing bad would happen.

Every spec I ever wrote was incomplete, and it did not matter, because the reader could turn around and ask me.

Incompleteness was not a defect in that system. It was the efficient choice. Writing down every edge case, every implicit rule, every "obviously not like that" would have taken days, and the alternative cost about ninety seconds of somebody leaning over a desk. Any reasonable team takes the ninety seconds.

So a whole generation of us built a product management process on top of an artifact that was never load bearing, and then congratulated ourselves for being lean about documentation.

The Room Was Doing More Work Than the Document

What actually carried the build was a slow, invisible drip of context that never appeared in any tool.

The developer who guessed right about the empty state, because she remembered a support call from three weeks earlier. The quick question at four in the afternoon that saved a day of work. The standup where somebody said "wait, does that apply to trial accounts too" and the room went quiet for a second. The designer who never asked, because she had been in the interview and already knew.

None of that was written anywhere, and it was not lost either. It lived in the room, and the room stayed available.

Then I started building with agents, and the room was gone.

An Agent Cannot Lean Over the Desk

For the first weeks I was sure my problem was prompting. It was not prompting. It was that I had spent a career producing a kind of specification that only works when a human can interrogate it, and I now had a reader that will not interrogate anything. It reads what I wrote, decides what I probably meant, and builds that. Confidently.

Two things from the last two weeks, both my fault.

I had built a chat surface where the agent links to the things it is talking about. Feedback themes, capabilities, changes, strategy pillars, bets, experiments. My spec described how a link to a feedback theme should behave, in detail, because that was the case I had in front of me at the time. The other eight types were, in my head, obviously the same idea. So every link the agent produced resolved as if it were a feedback theme, and had done for weeks. A human developer would have asked me about the second type. The agent had no reason to.

The other one is smaller and it still bothers me. I ended up writing an explicit requirement that malformed payloads and invalid statuses have to fail visibly instead of looking successful. Read that back as a sentence in a product document. I had to specify that failure should look like failure. No colleague in my career has ever needed that written down, and no colleague ever quietly returned green either.

If you give a person a fuzzy success criterion they usually ask a clarifying question, or at least look uncomfortable. Give the same sentence to an agent and it satisfies the words you actually wrote.

The Spec Became the Thing Worth Keeping

Here is the reversal, and it is the reason I now spend real time on documents I spent a whole career not writing.

The code got cheap. Two or three hours of work, deleted, no meeting, no team to console, nobody's hopes attached to it. In every previous version of my career, throwing away weeks of developer work was almost impossible, and not for rational reasons. You thought about how the team would feel. Sales had already shown it to a customer. So teams sat in a mediocre solution for quarters, because climbing out of it was expensive in a way no spreadsheet showed.

That cost has largely gone on the build side. Which means the expensive artifact is no longer the implementation. It is the accumulated understanding of what we are trying to do and what we already learned does not work.

Which is, more or less, what a PRD would have been if any of us had ever written one properly.

So the documents I write now hold the decision, the reason behind it, the approaches already burned and why they failed, and the boundaries the agent may not cross. When an attempt dies, the learning goes back into the document and only the code gets deleted. By the seventh version of that refactor spec, the document was worth more than anything in the branch.

That is also where a document stops being a document. It has to sit next to the evidence that produced it and the work that came out of it, and it has to move when the product moves. A spec in a folder starts decaying the moment nobody reads it. This is the layer of a product operating system that we all skipped, because there was always a room to fall back on.

The First Reader That Takes Us Literally

The story going around is that AI is forcing product people to write more, and that framing annoys me slightly. Nobody is writing more because a process demanded it. We are writing more because there is finally a reader that takes our words at face value, does not fill the gaps out of politeness, and cannot be asked a follow up question.

Every senior product person I know has a gap between what they know about their product and what exists in writing about it. Mine was enormous, and I never thought of it as a gap. I thought of it as experience.

So the question I would sit with, if I were still running a product org. Take the last spec your team shipped from, and imagine the person building it had no access to anyone who wrote it. No standup, no quick question, no shoulder to tap.

What would they have built instead?