Sep 14, 2026 · 6 min read
Stop writing PRDs from memory
Most specs get written long after the conversations that justified them. Here’s how to write one where every requirement points back to its evidence, and how to keep it accurate after sign-off.
The spec comes after the memory fades
You probably know how this goes. A PM runs a batch of customer calls, swaps a few Slack threads with sales, checks a dashboard, and then gets pulled into a launch. By the time they sit down to write the PRD, the calls are weeks old. What’s left is a handful of notes, a strong impression, and a deadline.
The doc gets written anyway, and it reads cleanly. But it’s a reconstruction, and reconstructions drift.
Atlassian’s PRD guidance points at the problem. It suggests bringing a designer and an engineer to customer interviews so they hear from customers directly instead of relying on the product owner’s notes. That advice exists because notes lose detail.
How drift shows up
Specs written from memory tend to fail in the same few ways:
• The “why” disappears. The problem statement turns into a summary of the solution. Engineers get a list of what to build without the customer situation that made it matter.
• Assumptions harden into requirements. “Admins probably want bulk export” was a hunch on one call. Three weeks later it’s requirement 4.2.
• Scope creeps quietly. With no record of what customers actually asked for, every reasonable-sounding addition is hard to push back on.
• Nothing is traceable. When an engineer asks who needs this, the honest answer is “I remember someone saying it.”
• The doc goes stale at approval. Once everyone signs off, nobody owns keeping it current, and the spec slowly stops matching what the team is actually building.
Marty Cagan was making a related critique back in 2006. He argued that most specs take too long to write, are seldom read, and don’t address the difficult questions, and he pushed teams toward prototypes tested with real users. You don’t have to give up written specs to take the point. A document that isn’t grounded in real evidence doesn’t do much work.
What the best templates agree on
The widely shared templates look different, but they converge on a few ideas:
• Problem before solution. Basecamp’s Shape Up insists that a pitch pair the problem with the solution, because without a specific problem there’s no way to judge whether a solution is any good.
• A way to measure success. A spec should say what will be different if it works, so the team can check later instead of arguing from memory.
• Explicit boundaries. Kevin Yien’s widely shared PRD template includes a non-goals section, which Lenny Rachitsky singled out as a favorite. Shape Up pitches go further, calling out “rabbit holes” and “no-gos,” plus an appetite that sets how much time the problem is worth.
• Customer-first framing. In Amazon’s Working Backwards process, as described by former Amazon executives Colin Bryar and Bill Carr, teams write a press release and FAQ before development begins. The press release has to describe the customer’s problem and how the product solves it.
• Change is expected. A spec that never changes after sign-off isn’t stable, it’s stale. Good specs treat updates as part of the process, not a sign the first draft was wrong.
What these templates rarely spell out is the mechanics: how to tie each requirement to its evidence, and how to keep the doc current without it becoming a second job.
A template for an evidence-backed spec
Use this as a starting structure and rename sections to fit your team.
1. Header. Owner, contributors, status, last updated date, and a link to the changelog.
2. Problem statement. One or two sentences about the customer’s situation, not your solution. Link your strongest evidence directly beneath it.
3. Evidence. A short list of sources: call recordings or notes, support tickets, analytics queries, research findings. Give each an ID (E1, E2, and so on) and a one-line summary of what it shows.
4. Success metric. The number that should move, its current baseline, and when you’ll check it. If there’s no baseline yet, say so.
5. Assumptions. Everything you believe but haven’t validated. Each gets an ID, an owner, and a plan to test it.
6. Requirements. Each requirement cites the evidence or assumption it depends on.
7. Non-goals. What you’re deliberately not doing, and why.
8. Open questions. Decisions still to be made, each with an owner and a date.
9. Changelog. Dated entries describing what changed and which new input caused it.
How to cite evidence inline
Keep citations light enough that people actually add them. A tag at the end of the line works:
• “Admins can export all member activity as a CSV. [E3, E7]”
• “Exports finish without timing out for our largest workspaces. [A2]”
A few rules of thumb:
• Link to the source itself, ideally the timestamp or the row, not someone’s summary of it.
• Use customers’ own words in the problem statement when you can.
• If a requirement has no citation, it’s either an assumption (move it to that list) or a decision (label it and say who made it).
• Note when evidence comes from a single customer. One loud account is not a pattern.
How to mark assumptions
Separate what you know from what you believe. A simple convention:
• Validated: backed by evidence you can link.
• Assumption: plausible but untested, tagged A1, A2, and so on.
• Decision: a call the team made without full evidence, with the name of whoever made it.
Review the assumptions list at each milestone. When one is confirmed, promote it and attach the evidence. When one is disproven, revisit every requirement that cites it. This is where the tags pay off: search the doc for “A2” and you’ll find everything affected.
How to keep it current
A spec rots when updating it depends on someone remembering to. Tie updates to routines you already have:
1. After each relevant customer conversation, add what you learned to the evidence list within a day, while it’s fresh.
2. At your weekly sync or sprint planning, skim open questions and assumptions, and close what’s resolved.
3. When scope changes, write the changelog entry first, then update the requirement and tell contributors.
4. Link tickets both ways. Link each requirement to its ticket in your tracker, and the ticket back to the spec, so status is visible from either side.
5. After launch, record the actual result against the success metric. That becomes evidence for the next spec.
None of this requires a new tool. Write the problem first, link the evidence, label your assumptions, and treat the changelog as part of the spec. A doc that shows its work is easier to trust, easier to challenge, and harder to let go stale.
Where Fijord fits
We’re building Fijord because this upkeep is exactly the kind of work that crowds out time for building great product. Fijord connects the tools teams already use, including notetakers and recordings from Granola, Gong, Zoom, and Google Meet, plus Slack, Linear, Jira, Notion, GitHub, and Mixpanel. It turns those scattered inputs into signals you can trace back to the conversations and data behind them.
From that evidence, Fijord drafts briefs, tickets, and specs, and keeps PRDs updated as new input arrives. Every insight, recommendation, brief, and ticket links back to the conversations, documents, analytics, and research that produced it, so the citation habit above happens by default. Fijord works alongside Jira, Linear, and Notion rather than replacing them, and after release it closes the loop by measuring outcomes.
Fijord is in early access. If your specs keep drifting away from the evidence, we’d love to hear how your team works today.