Craft
Who Writes the PRD?
The PM owns it, which is not the same as writing all of it. Who writes which section, the four to never delegate, and co-writing without contradictions.
The short answer is that the product manager owns it. The useful answer is that owning a document and writing a document are different jobs, and most of the dysfunction around PRDs comes from treating them as the same one.
Ownership versus authorship
The owner is accountable for the spec being correct, complete and decided. One person. Always one — the moment there are two, ambiguity has nowhere to go.
The authors are whoever holds the knowledge for a given section. Frequently several people, and that is healthy.
Two failure modes come from collapsing these:
The PM who writes everything. Becomes a bottleneck, and produces worse technical constraints than the engineer sitting next to them would have written in ten minutes. The document waits on one person's calendar.
The PM who "delegates the PRD". Sections arrive from four people, each internally reasonable, and the document contradicts itself. Nobody is accountable, so nothing gets decided — it gets described.
Who writes which section
| Section | Drafted by | Decided by |
|---|---|---|
| Problem, users, why now | PM | PM |
| Success metrics | PM, with data | PM |
| Scope and out-of-scope | PM | PM |
| Functional requirements | PM, reviewed by engineering | PM |
| Technical constraints | Engineering | Engineering |
| Flows and states | PM with design | PM |
| Non-functional requirements | Engineering proposes | PM decides which are requirements |
| Rollout and phasing | PM with engineering | PM |
| Legal, privacy, compliance | The specialist | PM incorporates |
The pattern in the right-hand column is the point. The PM decides in almost every row, including the ones they did not write. An engineer proposing a 400ms latency target is supplying expertise; whether 400ms is a requirement or an aspiration is a product call, and it belongs to the owner.
The exception is technical constraints, which are genuinely engineering's to decide — a PM overruling an engineer on what the system can do is not ownership, it is writing the how.
The four you never delegate
Problem framing. What is wrong, for whom, and why it matters now. Hand this over and the product is being designed by whoever had time, not by whoever understands the user.
Success metrics. Which number moves, from what baseline. Delegating this usually produces a metric that is easy to measure rather than one that means something.
The scope boundary. What is in, and specifically what is not. This is the section that gets argued about after approval, and the owner is the only person positioned to defend it.
Prioritisation of requirements. Which of these is a must and which is a should. Every author believes their section is essential; deciding between them is the job.
Everything else can be drafted by somebody better placed to draft it.
When there is no PM
A real situation, and common in early startups: the honest answer is that somebody still has to own it.
"The team owns it" is not ownership, it is an absence phrased optimistically — and the symptom shows up within a sprint, when two people have different ideas of what was agreed and there is no tiebreaker.
In practice it falls to a founder or a tech lead. The title does not matter. What matters is that one named person is the answer to "who do I ask if this is ambiguous?", and that the same person does the final consistency pass.
Co-writing without a mess
Four rules, and the last one is the one teams skip:
One document, not four. Separate drafts that get merged later produce contradictions nobody notices, because the merge is mechanical and nobody re-reads the whole thing afterwards.
Named author per section. Not for credit — so the person with the question knows who to ask.
Comments, not parallel edits. Simultaneous editing on a spec that is still being decided produces a document where two sentences disagree and both have been "agreed."
A final consistency pass by the owner. Read the whole thing end to end, in one sitting, looking for places where sections contradict each other. This is where multi-author specs fail — not in any individual section, but in the seams between them, which nobody has read together because everyone read only their own part.
When the owner and the author disagree
Ownership means nothing until this happens, and it will. Engineering says the 400ms target is not achievable this quarter. Design says the flow needs a step the PM wanted to cut. Legal says the retention period has to be longer than the feature assumes.
The resolution depends on which kind of disagreement it is, and the two get confused constantly.
A disagreement about facts belongs to the expert. "Can the system do this?" is not a product question. If an engineer says the latency target is not reachable with the current architecture, the PM does not get to decide otherwise — they get to decide what happens next, which is a different call: ship slower, cut scope, spend the quarter on architecture, or accept the worse number.
A disagreement about priority belongs to the owner. "Is this worth doing?" is the job. An engineer can say a requirement will cost three weeks; whether three weeks is worth it is not their call, and deferring to them on it is how a PM quietly stops owning the product.
The useful move when these tangle is to separate them out loud: "So the constraint is real — 400ms needs a caching layer we don't have. That's your call and I'll take it. What I need to decide is whether we ship at 900ms now or wait a quarter." Most stuck disagreements are one of each, glued together, and they come apart cleanly once named.
What does not work is consensus. A spec where every disagreement was resolved by finding the option nobody objected to is a spec optimised for comfort — and it usually shows up later as a feature that does a bit of everything and none of it well.
The signature question
One test for whether a document has an owner:
Who do I ask if this is ambiguous?
If the answer is one name, you have an owner. If the answer is "depends which section", you have a collection of contributions — and the questions that will arrive at handoff have nowhere to land.
That is the whole distinction. Authorship spreads. Accountability does not.
FAQ
Who is responsible for the PRD? The PM owns it — accountable for it being correct, complete and decided. Not the same as authoring every section.
Can engineers write it? They should write parts, especially technical constraints and NFRs. Handing over the whole document is where it goes wrong.
What if there is no PM? Someone still owns it — usually a founder or tech lead. "The team" is not an owner.
How do co-authors avoid contradicting each other? One document, named section authors, comments over parallel edits, and a final consistency pass by the owner.