Living PRDs

A stale "approved" doc is worse than none. People will implement last month's comments as if they were decisions. Mark status, pick one home, and append what you learned after ship.

Mark status: Draft / In review / Approved / Building / Shipped. Update the PRD when decisions change. Link the PRD from the epic; do not duplicate it across Confluence, Notion and Google Docs forever (pick one home).

Living documents fail when every comment becomes a new requirement without a decision. After review, publish a short changelog at the top: "Mar 12: non-goals clarified — no cross-project views in v1." That prevents zombie scope from old comments sneaking back in mid-build.

Keep PRDs searchable: title, status, owner, and link from the epic. When onboarding a new engineer mid-feature, the PRD plus design doc should be enough to understand why without a tribal walkthrough. Archive shipped PRDs rather than deleting them — they become institutional memory for why a constraint exists.

After ship, append a short "what we learned" so the next PRD starts smarter — see iteration.

How engineering design docs relate

Sequence that works:

1. Discovery produces evidence the problem is real.
2. PRD / PR/FAQ locks problem, users, goals, non-goals, P0 behavior.
3. Eng design doc proposes architecture, APIs, data model, failure modes, rollout.
4. Tickets slice the approved design.

The design doc should not restate the problem. The PRD should not list API fields.

Common mistakes

• Every comment becomes a requirement. Changelog the decisions; park the rest.
• Three copies of the doc. Pick one home. Link from the epic.
• Deleting shipped PRDs. You will re-litigate why a constraint exists.

Check yourself

An old comment says "add cross-project views" and a new engineer starts it. What failed? No changelog of decisions. Non-goals were not republished after review.

Where does the storage schema live? The eng design doc, not the PRD. The PRD owns problem and P0 behavior.

Key takeaways

• Right-size the doc to the bet; mark Draft / In review / Approved / Building / Shipped.
• One home, a short changelog of decisions, archive rather than delete.
• Pair with an eng design doc for the how. After ship, write what you learned.

Further learning

Lenny's NewsletterDeeply researched product, growth, and career advice for product leaders, founders, and ambitious builders. Click to read Lenny's Newsletter, a Substack publication with millions of subscribers.lennysnewsletter.com SVPG articlesA partnership dedicated to teaching best practices to product teams and product leadersSilicon Valley Product Group

Map: PRDs and specs.