How do you write for machines, not just executives?

THE SHORT ANSWER

Write for the three machine audiences that now read PM writing: coding agents that turn specs into implementations, answer engines that decide whether customers find you, and your own agent fleet running off briefs. Swap the prose PRD for an eval set plus a half-page brief, because examples pin down what adjectives never could. Version prompts like code. Then run the cold-read test: hand the artifact to a model with zero context and measure the gap between what comes back and what you meant.

Count the actual readers of the last PRD you wrote. A couple of engineers, skimming. Your designer, the relevant sections. And then the readers nobody counts: the coding agent that turned it into a draft implementation, the answer engine that will decide whether a customer ever finds the resulting docs, and the agents in your own fleet running off briefs you wrote last quarter. Half your readers are machines now. Writing that a machine executes faithfully is a distinct craft from writing that persuades a human, and it does not transfer. Some of the best persuasive writers I have worked with produce specs that agents mangle, because the moves that charm a human reader are exactly the moves that scatter a model.

The three machine audiences

Coding agents are spectacularly literal. A human engineer resolves handle errors gracefully by asking what graceful means here. An agent resolves it statistically, differently each run. They reward numbered, individually checkable acceptance criteria, labeled examples of correct and incorrect output, and explicit statements of what is out of scope.

Answer engines, the AI Overviews and Perplexity and ChatGPT-with-browsing of the world, do not read pages the way Google's crawler ranked them. They extract blocks: a self-contained summary, a quotable Q&A pair, a sentence with named entities in it. No extractable blocks means invisible to the channel replacing search.

Your own fleet reads your briefs every single run, and it rewards stability: a brief file with a consistent schema and examples that do not drift. Every time you rewrite the brief from memory in a chat window, you are A/B testing your own infrastructure by accident.

From prose PRD to eval-set-plus-brief

The deepest change in my own practice: the prose PRD is now the cover letter, and the eval set is the spec. An eval set is a table. Inputs in one column, expected outputs in the next, and for the interesting rows, a note on why. Concise and professional summary is an adjective pile. Three labeled examples pin the target in a way no adjective can. Edge cases get promoted from a sad bullet list near the end to first-class rows, equal citizens with the happy path. The brief sits on top: half a page of stable context on what the product is, who the user is, and what good looks like in one paragraph.

Prompt hygiene and the cold read

Prompts and briefs are published writing, so give them the hygiene of code. One named, versioned document per agent, living in a repo with history, not in someone's chat scrollback. Changes get dated, and meaningful ones get checked against a small eval set before they ship.

Then the one test I trust: the cold read. Hand your artifact to a model with zero verbal context. No meeting memory, no you know what I mean. Compare what comes back to your intent. The gap is your score. It is brutal because it removes the shared context that makes ambiguous writing look fine inside a team.

Run the cold read tonight. One artifact, the spec or prompt you most recently shipped, into a model with zero context. The gap you find is your curriculum for the next month.

SOURCES

THE LONG VERSION

RELATED ANSWERS

Last reviewed 2026-07-31 · 3 min read