Send the prototype, not the spec

A spec asks the reader to simulate the product in their head, then react to the simulation. Most people can’t do that reliably, so they react to the writing instead — wording, scope, whether “should” means “must”. Two weeks of comments later you have agreement about a document nobody will use.

A prototype removes the simulation step. The reader clicks the thing and knows within ten seconds whether it’s right. It’s the same instinct as fake door testing — put something real in front of people instead of asking them to imagine it — applied one step earlier, before you know whether the thing is worth validating at all.

What I build

Not a design mockup — a working slice, front to back, on the real data shape. For most B2B products that’s a few hundred lines:

// One route, real validation, fake persistence.
export async function POST(request: Request) {
  const parsed = InviteSchema.safeParse(await request.json());
  if (!parsed.success) {
    return Response.json({ errors: parsed.error.flatten() }, { status: 422 });
  }
  return Response.json(await store.invite(parsed.data), { status: 201 });
}

The persistence is fake. The validation is not — that’s where the product questions live. Can one person hold two roles? What happens to a pending invite when the seat limit is hit? You cannot answer those in Figma, and in a spec you’ll simply forget to ask them.

The meeting changes shape

With a spec	With a prototype
“I think users would want…”	“That’s not what I expected to happen.”
Decision deferred to next review	Decision in the room
Engineering estimates the document	Engineering estimates the thing

The second column is the entire argument. Opinions get replaced by reactions, and reactions are much cheaper to resolve.

When I still write the spec

Three cases, and I don’t skip them:

1. Regulated or contractual behaviour — billing, data retention, anything with a legal reviewer. The document is the deliverable.
2. Async decisions across time zones — a prototype needs someone in the room to watch the reaction. Without that, prose wins.
3. After the prototype settles the question. Then the spec is a two-page record of what we decided and why — written in an hour, because the hard part is already done.

That last one is the real workflow. The prototype isn’t a replacement for writing. It’s what makes the writing short.

Getting a team to work this way round is mostly a habit change rather than a tooling one, and habits are hard to change from inside your own team — which is the case coaching is built for.