How to run a spec review meeting (not a read-aloud)

Most spec review meetings are a person reading their document out loud to people who have not read it, while everyone waits for a gap in the narration to say something.

That format guarantees two outcomes. The findings you get are whatever occurred to someone in the last ninety seconds, weighted heavily toward page one. And the meeting ends with a promise to follow up async, which means it ended with nothing.

A spec review has one job: convert a draft into decisions. Here is the shape that does that.

Open with ten minutes of silence

Put the doc on screen and let people read it. In the room, no talking, timer visible.

This feels wasteful. It is the highest-leverage ten minutes in the hour. The alternative is not "people read it beforehand", the alternative is people skimming the first two sections on the walk over and then reacting to a document they have not actually processed.

Silent reading fixes three things at once. Everyone arrives at the discussion with the same information. The author stops performing the document and starts listening. And the findings you get cover page four, because someone finally reached page four.

Ask reviewers to annotate while they read rather than hold comments in their head. What comes out of a silent read is written down, ranked, and specific. What comes out of narration is whoever talks first.

If the doc cannot be read in ten minutes, that is a finding about the doc.

Run four blocks, in this order

Block 1: the author frames, in two minutes. Not a walkthrough. Two minutes on what problem this solves, what decision they need from the room, and which sections they are least sure about. That last item is what makes the meeting honest. A PM who names their own soft spot gets a review of the soft spot instead of a review of their formatting.

Block 2: blockers only. Go around the room and take blockers first, nothing else. A blocker means engineering cannot start or the launch would be wrong. If the problem statement and the proposed solution turn out to describe different problems, that surfaces here and the rest of the agenda changes, which is exactly what you want to learn at minute fifteen rather than minute fifty.

Block 3: majors, timeboxed. Things that will cost a rework cycle. Two minutes each, no exceptions. When something exceeds two minutes it is not a comment, it is a disagreement, and it goes to the parking lot with a named owner.

Block 4: decisions. Ten minutes, doc on screen, edits made live. This block is not optional and it is not the part you cut when you run long. If you are going to sacrifice something, sacrifice majors.

Minors never get meeting time. They go in the doc as comments and the author closes them alone. A room of six people discussing a section heading is the most expensive proofreading in the company.

Assign four roles out loud

The author presents and edits. They do not defend. This distinction matters more than any other single thing in the room, and it is worth saying at the top: the goal is a better spec, not a vindicated one. An author in defence mode converts every finding into a debate, and the meeting runs out of time on finding three.

The reviewers bring findings with severity attached. "This is a blocker because engineering cannot estimate the sync path" is a finding. "I wonder if we have thought about performance" is a thought, and thoughts belong in comments.

The decider is one named person who can resolve a disagreement when the room does not converge. Name them before the meeting starts. Most stalled reviews are not stalled on information, they are stalled because nobody in the room had the authority to close the question and everybody was too polite to point that out.

The scribe is not the author. The author is editing the doc and cannot also capture decisions, and when they try, both get done badly. Anyone else can scribe. Rotate it.

Three rules that keep it moving

Findings must point at a line. If a reviewer cannot say which section their concern lives in, it is not ready to be raised. This one rule removes most of the abstract discussion that makes these meetings feel long.

Two minutes, then park it. Track the parking lot visibly. An item goes there with an owner and a date, never with "let us take this offline", which is where findings go to die.

Silence is not agreement. Ask the engineer directly whether they can estimate this. Ask the designer directly whether the flow has states they cannot design. Quiet rooms are usually rooms where two people have concerns and each assumes the other will raise them.

End with decisions, not notes

Before anyone leaves, three things are written in the doc itself:

1. The verdict. Ship, revise, or rethink. One word, said out loud, by the decider.
2. Every open item with an owner and a date. No unowned items. An item with no name attached is a note, and notes do not close.
3. What changed in the doc during block 4. Edits made live, in the room, while everyone can see them.

Then send nothing. The doc is the record. A separate recap email creates a second source of truth that immediately starts drifting from the first.

The test of whether the meeting worked is not how many findings surfaced. It is whether the author knows what to do tomorrow morning. Twenty findings and no verdict is a worse outcome than three findings and a clear "revise, fix the metric first."

The meeting you should not have booked

A large share of spec reviews should have been async.

If the spec has never been reviewed by anyone, the meeting will be spent finding gaps a checklist would have caught. That is a waste of six calendars. Run the mechanical pass first, alone: the completeness check, the testability of every acceptance criterion, the non-functional coverage, the internal contradictions. The standing list is the PRD review checklist, and the author's own version of this pass is how to critique your own PRD.

Book the room for what only a room can do. Judgment calls, tradeoffs between two defensible options, and the decision itself. Everything upstream of that is rubric work, and rubric work is what Thinkr's Critique exists to absorb: eleven passes, findings classified blocker, major, and minor, each landed as a comment on the line it concerns, before the meeting rather than during it.

Reviewers walk in with the mechanical gaps already closed. What is left on the page is the part that actually needed six people. For the reviewer's side of the same job, see how to review someone else's PRD.

FAQ

How long should a spec review meeting be?

Sixty minutes for a substantial spec: ten for silent reading, thirty-five for findings, ten for decisions, five of buffer. If the doc needs more than ten minutes to read, it is too long for one meeting and should be split by section or reviewed async first.

Who should be in a spec review?

The author, one engineer who will build it, one designer if there is UI, the person who can actually decide, and anyone with a hard dependency. Five to seven people. Beyond that, attendance is political rather than useful and the discussion stops converging.

Should reviewers read the doc before the meeting?

In theory yes, in practice most will not, which is why the silent-read open exists. Ten minutes of enforced reading in the room beats an hour of people reacting to a document they skimmed on the way in.

What if the meeting does not reach a decision?

Name the reason before it ends: missing information, missing person, or genuine disagreement. Each has a different fix. Assign the owner and the date for that specific unblock rather than booking a second identical meeting.

---

Part of a series on the review side of Product craft. See what a full critique looks like in How Thinkr critiques a PRD, or read where review sits in the wider workflow in the loop.