PRD Pre-Read: Getting Reviewers to Actually Read the Spec

Most pre-reads are skims. A reviewer opens the link five minutes before the meeting, reads the summary and the first section, and arrives ready to react to page one. The findings you get are about the part they read. The sections you were least sure about, usually further down, get nothing.

It is tempting to call that a discipline problem. It is mostly a document problem. A spec is written for the person who builds it. A pre-read is a request, and most of them never say what is being requested: no decision named, no sections singled out, no question for anyone in particular. Faced with twelve pages and "thoughts?", skimming is the rational response.

Three changes fix most of it: the ask at the top, a reading order, and one question per reviewer.

Why reviewers skim

They do not know what they are being asked. "Please review" has no finish line. A reviewer who cannot tell when they are done stops when they run out of time.

The document is sized for a different reader. An engineer reads a spec in passes: a skim for shape, a hunt for constraints, a list of questions. A reviewer with fifteen spare minutes only gets through the first pass unless you tell them where the second should go.

They cannot tell what changed. On a second round, a reviewer who saw v1 either rereads all of it or none of it. Usually none.

Nothing happens if they do not. If the meeting opens with the author narrating the doc, the pre-read was optional, and everyone has learned that.

Put the ask at the top

Above the title, before any context, five lines. An illustration:

DECISION NEEDED   Approve scope for bulk member import, v2
BY                Thursday's review, 14:00
READ              Scope (sec 2), Limits (sec 4), Error handling (sec 6), about 9 minutes
SKIM              Background (sec 1)
SKIP              Appendix: competitor notes

That block does three jobs. It tells the reviewer what kind of reading this is: deciding, not browsing. It gives them a finish line. And it puts the sections you most need read at the front of their attention, instead of wherever they happen to fall in the document.

The same header works for an earlier, softer session. In a product critique the decision line becomes "what I want critiqued", and the settled decisions go under SKIP.

Order by risk, not by document order

Your spec is in the order a builder needs: problem, scope, requirements, edge cases. Your reviewers need it in the order of where you might be wrong.

List the reading order with the shakiest sections first. If the row limit is a guess, it goes first. If the problem statement has survived three reviews already, it goes under SKIM. This is the pre-read version of the author naming their soft spot at the start of a spec review meeting: you get a review of the parts that need one.

Keep the READ list to about ten minutes. Longer than that and you are asking for more than one review. Split it by section, or send part of it out first.

One question per reviewer

The highest-yield change, and the one almost nobody makes.

Instead of asking everyone to review everything, give each reviewer one question they are best placed to answer. An illustration, for the same import spec:

Reviewer	Their question
Engineering lead	Can you estimate the import job from section 4 alone? If not, what is missing?
Designer	Does every error in section 6 have somewhere to appear?
Support lead	Which of these errors will become tickets, and what will customers call them?
Decider	Is excluding SSO provisioning, in section 2, a cut you would defend to the accounts that asked?

A named question turns reading into a task with an end. It spreads coverage, so section 6 gets read by someone who cares about section 6. And it makes silence informative. A reviewer who answers "nothing missing" to a specific question has told you something. A reviewer who leaves no comment on "thoughts?" has told you nothing.

They can still comment on anything else. The question is a floor, not a fence.

Show what changed

For any round after the first, add a change block under the ask:

CHANGED SINCE V1   Row limit cut from 1,000 to 500 (sec 4). Duplicate rule added (sec 6).
NOT CHANGED        Scope, metric.
OPEN               3 comments from v1, listed in sec 7.

Returning reviewers read the delta and the open items, which is what you need from them. Without the block, they skim the whole spec again, which is worse than reading the delta properly.

Timing, and a comment deadline

Send it when it can be read in working hours, not the night before. Two working days ahead is a sensible default for a substantial spec.

Then set a comment deadline a day before the meeting. That gives you time to sort what came back by severity, blocker, major or minor, so the meeting opens on the contested items instead of discovering them. A pre-read with no deadline produces comments during the meeting, which is the read-aloud with extra steps.

Make it worth their attention

Reviewers stop reading carefully when careful reading keeps turning up typos and missing error states. Their attention goes on the floor of the document, and they never reach the questions only they can answer.

Clear the floor before you send it. Run your own pass, or a mechanical one: our critique runs eleven passes and lands findings as comments marked blocker, major or minor, each with a suggested rewrite. Close what it finds, and the reviewer opens a draft where their question is the most interesting thing left on the page.

When they still do not read it

Some will not. Plan for it rather than take it personally.

Keep the silent read. Open the meeting with ten minutes of reading anyway. It costs the people who prepared little, since they can use it to check their comments, and it rescues the meeting from the ones who did not.

Watch the questions, not the attendance. If a reviewer's question comes back unanswered twice in a row, the pre-read is not the problem. Either they are the wrong reviewer, or nobody has made room in their week for the review. Both are conversations to have outside the doc.

Shrink the ask before you chase. A reviewer who will not read nine minutes will often read three. One section and one question beats a full document and silence.

FAQ

What is a PRD pre-read? The spec sent ahead of a review, written as a request: the decision, the reading order, and a question for each reviewer.

How long should it take to read? About ten minutes for the assigned sections, however long the full spec is.

When should I send it? Two working days ahead, with a comment deadline the day before.

What if they still do not read it? Keep a silent read, watch whether the questions come back, and shrink the ask before you chase.