PRD Sign-Off: What Approval Should Actually Mean

A thumbs-up on a spec records one fact: somebody saw it. It does not record what they agreed to, which version they saw, or what they assumed would change before the build. Three weeks later the same person says "I approved the direction, not the 500-row limit", and they are not lying. Nobody wrote down what the approval covered.

This is the sixth of the six ways specs fail: the document mistaken for the agreement. A spec can faithfully record a consensus that never existed, and a column of approvals at the top makes it look stronger than it is.

Sign-off fixes that only if it is a named commitment with a scope: who signed, for what, on which version, except for what. Four parts, about a line each.

What a thumbs-up leaves out

Scope. An engineering lead approving a spec might mean "the approach is sound", "I can estimate this", or "I have not read section 6 but I trust you". Three different commitments that look identical.

Version. The spec changed twice after the approval. Does the approval still hold? Nobody knows, including the approver.

Exceptions. Almost every real approval has a "provided that": provided the retry policy gets settled, provided legal is comfortable with the data in the export. Unwritten, those conditions evaporate, and the approval reads as unconditional.

Consequence. An approval that commits the approver to nothing is easy to give. That is why specs collect approvals from people who did not read them.

The four parts of a real sign-off

Who. A named person in a named role. Not "engineering".

What. The sections or decisions they are signing for, phrased as a commitment. "Buildable as specified, sections 3 to 6, estimate three sprints" is a commitment. "LGTM" is not.

Which version. A version number or a date. Sign-off is against a text, and the text moves.

Except. Open items carved out explicitly, each with an owner and a date. An exception is not a weakness in the sign-off. It is the most honest part of it.

An illustration of a sign-off block, kept at the top of the spec:

SIGN-OFF · v3 · 9 Oct
Head of Product (accountable approver): scope and success metric.
Engineering lead: buildable as specified, sections 3-6. Estimate: three sprints.
   Except: retry policy for failed rows. Open, owner engineering lead, 14 Oct.
Design lead: every state in section 5 has a designed screen.
Support lead: error copy in section 6 reviewed for ticket risk.

Five lines. Anyone opening the spec can see what was agreed, by whom, and what was not.

Who signs for what

One accountable approver plus named reviewers for specific sections is the shape that works. A signature from everyone diffuses ownership: when nine people approved, nobody is accountable.

Role	Signs for	Does not sign for
Accountable approver	The bet: scope, metric, priority	Whether it can be built as written
Engineering lead	Buildability and the estimate	Whether it is the right thing to build
Design lead	Every flow and state has a design	The business case
Dependency owners	The part that touches their system	Everything else

The right-hand column matters as much as the middle one. An engineer signing for buildability is not endorsing the strategy and should not be asked to. Keeping each signature narrow is what makes people willing to sign something specific.

Sign-off is not a freeze

Frozen sign-off is the ceremony that gives specs a bad name in agile teams: approval turns the document into a contract, and changing it becomes political. That is a property of the ceremony, not of signing.

What sign-off should fix is the commitment, not the text. Detail can be added, wording improved, examples added, without anyone re-signing. What reopens a sign-off is a change to a signed decision:

• the scope, in or out;
• a limit or a threshold;
• the success metric or its target;
• a permission rule;
• anything else inside a signer's "signs for" line.

When that happens, three lines go into the doc: what changed, why, and who agreed. The people who signed that section re-sign it. Nobody else does. That keeps amendment cheap, which is what stops a team quietly abandoning the document halfway through the build.

What it commits each side to

The signer commits to not relitigating the signed scope from memory. New information is welcome. It arrives as a proposed amendment, through the same route, not as "I never agreed to that".

The author commits to telling signers when their section changes. A sign-off the author can quietly route around is not one anyone will take seriously the next time.

The same dispute, twice

An illustration. Three weeks into building a bulk member import, the support lead reports that the accounts who asked for it have more than 500 members each. They want the row limit raised to 2,000.

Without a sign-off block, the conversation runs on memory. The head of product remembers approving "the import feature". The engineering lead remembers the limit being provisional. Someone finds a thumbs-up from three weeks ago and nobody can say which version it was on. The argument is about what was agreed, not about what to do.

With the block, it takes ten minutes. The limit sits inside the engineering lead's signed sections, so this is a change to a signed decision. The author writes three lines: limit raised to 2,000, because the requesting accounts exceed 500, agreed by the engineering lead and the head of product, with a revised estimate. The engineering lead re-signs sections 3 to 6. The head of product re-signs too, because the estimate moved and priority is theirs. Design and support do not, because nothing they signed for changed.

The block did not prevent the change. It made the change cheap, and it made it visible.

Signs your sign-off was a thumbs-up

• The approver cannot say what is out of scope.
• The engineering estimate arrives after approval and changes the plan.
• The questions that come up at handoff are ones the review should have closed.
• Nine people approved, none of them for anything in particular.
• Nobody can say which version was approved.

Each one means the approval recorded attendance, not agreement.

Before you ask

Sign-off goes best when there is nothing left to discover in the room. The review has happened, blockers have been closed by the people who raised them, and the open items are known well enough to be listed as exceptions. An async review with real resolution rules gets you most of the way there.

The mechanical floor should be clear too. Approvers who sign a spec with undefined terms and missing states are signing for something they will each read differently. Our critique runs eleven passes and lands each finding as a comment marked blocker, major or minor, with a suggested rewrite, so the version people sign has been checked against a fixed standard first. What it cannot do is the part sign-off exists for: a person putting their name to a decision.

FAQ

What does PRD sign-off mean? A named person committing to defined sections of a specific version, with open items listed as exceptions.

Who should approve a PRD? One accountable approver, plus named reviewers for the sections they can judge.

Does sign-off freeze the PRD? No. It fixes the commitment; only changes to signed decisions reopen it.

What if the spec changes after sign-off? Record what changed, why and who agreed, and the signers of that section re-sign.