Pitch doc vs. execution doc: stop them bleeding into one mess

Two PMs, the same structural problem. One needs a high-level "brief" for VP sign-off that keeps getting padded until it's a 3-to-5-pager — too much for execs, not enough for execution. Another was asked for a "product release document" by a new manager who wanted it detailed, narrative, and "for everyone, all purposes, as exhaustive as possible," and couldn't tell if that was a PRD or something else.

Both are colliding with the same truth: a document for getting approval and a document for guiding execution are different artifacts with different audiences, and trying to make one do both jobs produces something that does neither.

Why "for everyone" is the failure mode

When a manager says "make it exhaustive, for all audiences," they're asking for a document that's simultaneously a two-minute exec skim and a complete engineering reference. Those are opposites. Execs need the problem, the opportunity, and the ask, fast. Engineering needs the boundary behavior and the edge cases, in depth. A single doc that serves both is too long for the first reader and too shallow for the second — which is exactly the 3-to-5-page mush the first PM described.

The two documents, kept distinct

• The pitch / buy-in doc. One to two pages. Problem or opportunity, why now, what we want to do, what success looks like, the ask. Its only job is a yes. It does not contain requirements. The moment requirements creep in, it stops being skimmable and the exec stops reading.
• The execution spec. Written after the yes. Context, yes, but mostly the detailed behavior engineering needs. Its job is to be buildable, not persuasive.

How to share content without duplicating it

The first PM's real pain was duplication and drift — the same problem, written twice, diverging. The fix isn't copying the pitch into the spec. It's treating the pitch's problem statement and goals as the same underlying decision that both documents reference, so when it changes, it changes once. The pitch is the lightweight view for approval; the execution spec is the detailed view for building; they share a spine instead of being two copies that drift.

So: is the "exhaustive document for everyone" a PRD? No — it's two documents wearing one filename. Split them by audience and job, keep them sharing one source for the parts that overlap, and both get shorter and clearer at once.