The Section-by-Section Critique: Finding Gaps Before Eng Does

Finding spec gaps before engineering does means critiquing each section of a PRD against its own rubric — problem, users, acceptance criteria, edge cases, dependencies, metrics — instead of reading the whole document once for a general impression. A single skim rewards fluent prose and quietly skips over sections that are technically present but functionally thin.

Quick answer: Run a per-section critique, not one overall read-through. Score the problem statement, users, acceptance criteria, edge cases, dependencies, and metrics separately, each against its own rubric. Thin sections hide behind confident prose in a single skim — a section-by-section pass catches them before refinement does.

Why One Read-Through Isn't Enough to Catch Spec Gaps

A single read-through judges a PRD's overall narrative flow, not each section's individual completeness — so a document can feel finished while three of its eight sections are structurally thin. Section-by-section critique swaps one holistic impression for six or seven independent pass/fail checks, one per section type.

This matters because well-written prose creates a halo effect. A confidently worded problem statement makes a reader assume the acceptance criteria three pages later are equally solid — even when they're a bulleted list of vague adjectives ("fast," "intuitive," "reliable") with nothing testable in them. The writing quality of one section leaks credibility onto sections nobody actually checked.

Karl Wiegers, whose book Software Requirements is one of the field's most cited references on requirements engineering, has long argued that incomplete requirements are the single most common and most expensive class of defect in software projects — not wrong requirements, missing ones. The Standish Group's long-running CHAOS research has repeatedly placed incomplete or unclear requirements near the top of its list of project-challenge factors, alongside shifting scope and thin user input.

Neither source is talking about bad writing. They're talking about absence — a section that exists in name but not in substance.

The halo effect shows up in a few predictable places:

• A strong problem statement masking acceptance criteria nobody could actually test.
• Clean formatting masking a dependency with no owner behind it.
• A confident tone masking an edge-case section that only ever describes the happy path.

A section-by-section critique is the practical antidote. Instead of asking "does this PRD read well," you ask, section by section: "if engineering built exactly what's written here, and only what's written here, would they hit a wall?"

That question is unforgiving of narrative polish and forgiving of nothing else. It's the same discipline behind section-level maturity scoring for a living spec — treating a spec as a set of independently gradable parts rather than one document with one grade.

The Section-by-Section Critique Rubric

A useful rubric asks one or two pointed, testable questions per section type — not a generic "is this section good?" prompt. Below is a working rubric covering the six sections most PRDs share, with the specific signal that a section is thin rather than merely short.

Problem statement: is the user actually named?

A problem statement that never names a specific user or segment is the most common thin section, because it's the easiest one to write vaguely and still sound authoritative. "Users struggle to find their invoices" describes a feeling, not a job.

Compare it with "finance ops leads at 200-500 person companies re-export invoices from three systems every billing cycle because none of them cross-reference." The second version names who, what, and why, and gives engineering something to design toward.

This is exactly the gap that jobs-to-be-done framing is built to close: a job statement forces a situation, a motivation, and a desired outcome onto the page, which makes it much harder to write a problem section that's technically present but empty of information.

Acceptance criteria: is each one testable, independently?

The fastest rubric check for acceptance criteria is to read each bullet and ask whether a QA engineer, alone, with no follow-up questions, could mark it pass or fail. "The dashboard should load quickly" fails that test — quickly compared to what, measured how, under what load? "The dashboard renders within 2 seconds at p95 latency for accounts with fewer than 10,000 records" passes it.

• Testable: has a number, a condition, and a boundary.
• Not testable: contains an adjective with no unit attached — "intuitive," "robust," "seamless," "modern."
• Half-testable, still a gap: has a number but no condition — "loads in 2 seconds" without specifying device, network, or data volume.

Edge cases and constraints: what happens off the happy path?

Most PRDs describe the happy path in detail and wave at everything else with "errors are handled gracefully." A section-level critique treats that phrase itself as a red flag — it's a placeholder for work nobody has done yet.

Walking the customer journey's emotion curve for the flow in question is a reliable way to surface the moments most likely to break. The step where a user is rushed, distracted, or on a bad connection is exactly where an edge case is waiting.

Dependencies & sequencing: is there a name behind every arrow?

A dependency line that reads "coordinate with the platform team" is a thin section wearing the shape of a complete one — it names a team, not a person, a ticket, or a date. The rubric question here is blunt: if this dependency slips, whose calendar does it slip on, and how would anyone know before the sprint it was due?

• Ready: a named owner, a ticket or tracking link, and a date the dependency is needed by — not just requested.
• Thin: a team name with no individual, no artifact, and no date — technically documented, practically untraceable.
• Missing entirely: a dependency implied by the acceptance criteria (an integration, a data migration, a legal sign-off) that never appears in this section at all.

That last category is the one a single read-through almost never catches, because nothing on the page is wrong — a whole dependency is simply absent, and prose has nothing to point at.

Success metrics: is there a number, a baseline, and a window?

"We'll track engagement" or "measure adoption" is a section that names a direction without naming a destination. A testable success metric needs three things: a specific metric definition, a baseline it's measured against, and a time window in which it's evaluated.

"Weekly active accounts among the last 90 days' signups rise from a 22% baseline to 30% within one quarter of launch" gives an engineer, a data analyst, and a PM the same shared target. "Improve engagement" gives each of them a different one, which is its own kind of gap — not missing information so much as information nobody can act on consistently.

Running the Critique: A Step-by-Step Workflow

A section-by-section critique works best as a short, repeatable sequence run at a fixed point before a spec goes to engineering — not an ad hoc "does this look done" pass whenever someone remembers. The workflow below takes most specs 20-40 minutes and produces a section-by-section scorecard instead of one vague verdict.

1. Freeze the section boundaries. Confirm the PRD actually has discrete sections (problem, users, acceptance criteria, edge cases, dependencies, metrics) rather than one long narrative — you cannot critique a section that doesn't exist as a unit.
2. Score each section pass, thin, or missing against the rubric above, independently. Resist the urge to average — a spec with five strong sections and one missing section is not "80% ready," it's blocked on that one section.
3. Write down the specific question, not the verdict. "Thin" isn't actionable; "no owner named for the payments-team dependency" is.
4. Route each gap to the person who can close it, not back to the whole document. A missing metric goes to whoever owns the success measure, not to a general "please revise" comment.
5. Re-run the critique on the diff, not the whole document, next time. Once a spec has been through one critique pass, subsequent passes only need to check what changed — treating each revision as a PR-style spec diff keeps the re-review fast and focused on genuinely new risk instead of re-litigating sections that already passed.

Gojko Adzic's Specification by Example makes a related point about acceptance criteria specifically: a criterion that can't be turned into a concrete example with real inputs and outputs almost certainly isn't testable yet, no matter how confident it sounds. That's a useful gut-check to apply at step 2 above, section by section, rather than trusting a single overall impression of "the criteria section looks fine."

Thin Section vs. Ready Section: What the Difference Looks Like

The difference between a thin section and a ready one is rarely about length — a thin section can be three paragraphs of confident prose, and a ready one can be four bullet points. The difference is whether an engineer reading only that section, with no other context, would know exactly what to build and how to verify it.

Reading down that right-hand column, notice that every "ready" entry contains something a thin version never does: a number, an owner, or a concrete example. That's a fair proxy for readiness at the section level — not polish, but specificity you could act on without asking a follow-up question.

Where a Copilot Critique Fits — and Where It Doesn't

A structured per-section critique is a workflow a PM runs, with or without tooling — the value is in the rubric and the discipline of scoring sections independently, not in who or what applies it. Where a copilot can help is by running that same rubric consistently, on every section, every time.

That consistency matters because a reviewer's attention is a limited resource. A copilot handling the rote checks frees a reviewer to spend that attention on judgment calls, instead of remembering to check acceptance criteria for testability on a Friday afternoon.

A fair way to think about what any copilot layer here should and shouldn't do:

• Can: apply the same rubric to every section, every time, without fatigue or a Friday-afternoon skip.
• Can: point at the specific section and question that's thin, not just flag the document as "incomplete."
• Can't: judge whether a criterion actually reflects real user need, or whether an edge case is worth the engineering cost to handle.

In the current prototype, the critique text itself is templated. It's the intended shape of that review experience, not a live model that has read and reasoned about your particular spec — treat it the way you'd treat a rubric checklist held up against your document, a structured prompt to look harder at a section rather than an oracle that has already found every gap for you.

That distinction matters for how you use any spec-critique tool, copilot or otherwise. A rubric — human-run or software-assisted — is only as good as the sections it's pointed at and the judgment applied to what it flags.

The workflow in this article works whether you run it from a printed checklist or a screen; the point of a copilot layer is consistency and coverage, not replacing the read. For the broader practice this rubric sits inside, a complete guide to living specs covers how a PRD stays current as a project moves, not just how it's critiqued once before a kickoff.

Key Takeaways

• A single read-through judges narrative flow, not section completeness — well-written prose in one section can mask a missing one three pages later.
• Score sections independently, never average. A spec with one missing section is blocked on that section, not "mostly done."
• Acceptance criteria should be pass/fail testable — an adjective with no unit ("fast," "seamless") is a gap, not a detail to fill in later.
• Name the user in the problem statement. A jobs-to-be-done framing forces a situation and motivation onto the page instead of a vague feeling.
• "Handled gracefully" is a placeholder, not an edge case. Walk the actual failure states before calling that section done.
• Re-review the diff, not the whole document, once a spec has cleared one critique pass — PR-style spec diffs keep re-review fast.
• A copilot critique is a consistency layer, not an oracle — treat a templated or automated flag as a prompt to look closer, the same way you'd treat a rubric checklist.