What goes wrong when the same work lives in 3 documents, why blurred roles in a builder model make it worse, and the one-table PRD I’d put in their place.
You order one latte, and 3 people hand you one. They look identical: same cup, same foam, same name on the side. But one has oat milk and one has an extra shot, and the only way to find out which one you actually ordered is to taste all 3. That’s what happens to a team when the same work lives in 3 documents.
Most product orgs I’ve seen already have this problem, and the builder model is about to make it a lot worse. Most PRD templates were built to solve one function’s problem. Some lean heavily on the “why,” because the go-to-market side needs a narrative to sell with, and the “what” ends up buried at the bottom. Others are mostly the “what,” written by engineers who needed a spec and couldn’t wait for one. Experienced PMs skip both and write their own requirements doc on the side. Add a design brief, and now 3 or 4 documents describe the same feature, each one written for a different reader.
When roles were fixed, that was only annoying, because each document had one owner and a limited reach. Now the lines are blurring on purpose. Designers ship PRs, PMs build prototypes, and engineers write requirements when a squad has no PM. Everyone can produce the spec, and with AI a polished one takes minutes, so the copies multiply faster than anyone can reconcile them. The engineer builds from the requirements doc, the designer from the brief, and the agent from whatever ticket it was pointed at. An agent has no way of knowing a document is stale, so it builds from it with full confidence. The gaps show up in review or QA, the conversation turns into which document is right instead of what the product should do, and an exec reading a fourth summary makes the call.
In a builder model, it matters less who writes the doc and more that there’s only one.
Years ago at Spotify I helped rebuild how my business unit (Advertising) went from idea to build, and the part people remember is that we got rid of the design brief. The question came up again this week, when a partner asked whether design should write a brief for a fast-moving AI effort. My answer hasn’t changed, and the builder model gives it more urgency.
Here’s the shape I’d push for. The PRD is a table of capabilities, one row per thing the product will let someone do. Under each capability is a link to a click-by-click prototype of that capability only, one specific flow. Those prototypes are the first version of what we’ll build, so there’s no design brief, because the table already answers what a brief would. Any function, marketing or engineering or support, can open that table and understand why we’re building the thing, what it looks like, and the value it brings to clinicians.
The fair pushback, and I got it this week, is that a prototype alone doesn’t explain itself to someone new to the product. My answer is to write the words, just not in a written document. The designer records a walkthrough, face on camera, and it sits at the top of the table: here’s where you get to this, it’s in the header because it’s a global pattern, the clinician clicks here and it opens the side panel. Execs don’t spend time in the product the way we do, so the walkthrough is how they get what we get without a second document to drift. The table also needs one section most templates don’t have yet: data needs. It shows the flow of data each capability depends on, so data science and applied AI can build the hooks before handoff. It can live under success criteria. It just can’t be missing.
The best example of blurred roles working in our favor came from an engineering leader this week. He took a vision doc our group had written and restructured it into a problem-first PRD, because he knew an executive outside the group wouldn’t follow the original. Design embraced it, we agreed to treat it as vision and principles v1, and nobody wrote a competing version. Who wrote it mattered a lot less than the fact that there was only one.
If you try this, be clear about it. Tell people, “Here’s what we need from you,” and hold the format as written, because if you leave any room for the old way of working, the old way keeps going. Nobody has to give anything up except the extra cups.