Common PRD mistakes (and the check that catches each one)

The most common PRD mistakes aren't typos. They're the structural gaps that get a spec sent back: a solution written before the problem is framed, a success metric that can't fail, acceptance criteria too vague to build, edge cases nobody mapped, and a scope with no edges. Each one is predictable, which means each one is catchable, if you know what to look for.

Here are the seven I see most, in rough order of how much they cost. For each: why it sinks the spec, the fix, and the review check that catches it before your team does.

• Solution before problem, caught by the problem-framing read
• A success metric that can't fail, caught by the metrics check
• Vague or missing acceptance criteria, caught by the engineering-readiness pass
• Only the happy path, caught by the edge-case pass
• No non-functional requirements, caught by the engineering-readiness pass
• Scope with no edges, caught by the scope check
• Assumptions stated as facts, caught by the domain-gap read

1. You wrote the solution before you framed the problem

This is the expensive one because it hides. The PRD opens with a feature, the feature is reasonable, and everyone nods. Nobody notices that the problem it solves was never stated, so nobody can check whether it's the right problem. About half the specs I've reviewed solve a slightly different problem than the one in their own opening paragraph, and both halves read fine on their own.

The fix: write the problem, the user, and why-now first, then the solution, as an answer to them. If you can't state the problem without naming the feature, you don't have a problem statement yet. You have a solution looking for a justification.

Caught by: the problem-framing read, which checks that the problem is stated before the solution and that the two actually match.

2. Your success metric can't fail

"Increase engagement" is the most common non-metric in product. It names a direction and hides everything a reader needs to hold it accountable: which action, for which users, by how much, by when. A metric you can't be wrong about isn't measuring the feature. It's decorating the section.

The fix: rewrite every metric until someone could check it and catch you out. Lift activation from 22% to 30% for new workspaces within one quarter has a baseline, a target, and a clock. If the feature ships and the number doesn't move, you'll know, which is the whole point.

Caught by: the metrics check, which flags any success metric without a baseline, a target, and a timeframe.

3. The acceptance criteria are vague or missing

"Handle errors gracefully" feels like a requirement and specifies nothing. An engineer reads it, shrugs, and builds whatever's easiest, which is rarely what you pictured. Vague acceptance criteria are where the gap between "what I meant" and "what shipped" lives.

The fix: write criteria as conditions a tester could run. The Given-When-Then form leaves nothing to interpret: Given a user with a revoked invite, When they open the shared link, Then they see a request-access screen, not a 404. Three lines, zero ambiguity, and you've drafted the test as a side effect.

Caught by: the engineering-readiness pass, which checks that requirements are specific enough to estimate and test.

4. You only wrote the happy path

The happy path writes itself, and it's the one nobody files a bug against. The damage lives in the branches you skipped: the empty state, the expired session, the partial permission, the offline case. Those are the week-one bugs, and they're invisible in the draft because there's nothing on the page to catch your eye.

The fix: for each flow, walk the unhappy paths on purpose and write each as its own condition. If a flow has no error state in the spec, that's not because it has none. It's because you didn't write it.

Caught by: the edge-case pass, which maps every user flow to its failure states across user, system, data, and security.

5. There are no non-functional requirements

Most drafts cover what the feature does and go silent on how well it has to do it. That silence is where sprint estimates blow up. The engineer asks how many concurrent users this holds, the room turns to you, and you don't have a number.

The fix: borrow the engineer's quality vocabulary (performance, reliability, security, compatibility) from ISO/IEC 25010 and answer it. "Fast" isn't a requirement. p95 under 500ms at 1,000 concurrent users is one you can build against and be held to.

Caught by: the engineering-readiness pass, which checks for the non-functional half, not just the feature list.

6. Scope has no edges

A scope section that only says what's in is only half a scope. Without an explicit out-of-scope list, every reader fills the gap with their own assumption, and the feature quietly grows between the PRD and the demo. Scope creep usually isn't a decision. It's the absence of one.

The fix: write the non-goals next to the goals. "We are not doing X in this version, and here's why" prevents more rework than any amount of detail on what you are doing. It also forces you to admit the tradeoff you already made.

Caught by: the scope check, which flags an unbounded feature list and a missing set of non-goals.

7. Assumptions stated as facts

"Users will obviously want this." "The data is already there." "Legal signed off." Every PRD rests on assumptions, and the dangerous ones are the sentences written as facts — because a fact doesn't invite a check, and an unchecked assumption is what blows up after launch, not before.

The fix: mark your assumptions as assumptions. "We're assuming X; if that's wrong, the plan changes because Y." Naming them turns a silent risk into a question someone can answer before you build on top of it.

Caught by: the domain-gap read, which surfaces the assumptions and missing pieces specific to your domain — the things only someone in it would notice.

The pattern under all seven

Every mistake on this list is the same shape: something that should be on the page isn't, and its absence is invisible to the person who wrote it. You can't proofread a gap you didn't notice the first time. That's why a real review reads for what's missing, not what's wrong — the longer version of that argument is in the principles behind a rigorous critique, and the standing version of these checks is the PRD review checklist.

Running all seven by hand takes discipline, and discipline is the first thing to go at 6pm on the day the doc is due. That's the pass Thinkr's Critique automates — eleven of these checks on your draft, each finding classified by severity and landed as a comment on the line it concerns, so the gaps surface before your team opens the doc instead of in the meeting about it.