Product & Delivery · Chapter 2 of 13
Writing that makes engineering able to start
The product manager's real output is not the roadmap. It is the document that removes ambiguity.
Whatever your organisation calls it — PRD, one-pager, spec, brief — the test is the same: can a competent engineer read this and begin, without a meeting? Most cannot, and the resulting meetings are the tax.
What a usable document contains
| Section | What it answers | The failure when it is missing |
|---|---|---|
| The problem | Who has it, how often, what it costs them | Engineering optimises the wrong axis |
| Why now | What changed to make this the quarter | It gets deprioritised the moment something louder arrives |
| What success is | The metric and its current value | You cannot tell afterwards whether it worked |
| Scope — and non-scope | What is explicitly excluded | Scope grows silently and the date slips |
| Constraints | Latency, cost, compliance, data residency | Discovered in week five, after the design |
| Open questions | What you do not yet know, and who decides | Engineers guess, and guess differently from each other |
| Rollout | Flagged, staged, measured, reversible | It ships to everyone on a Friday |
Three habits that raise the quality immediately
- Write the non-scope list first. It is harder and it is where the real thinking is. If you cannot name five things you are deliberately not doing, you have not scoped anything.
- Put the open questions in, honestly. A document that pretends certainty it does not have gets found out in week two and costs you credibility. A document that says ‘we do not know how the vendor rate-limits this; I am finding out by Thursday’ is trusted.
- Write for the engineer who joins in month three. They were not in the meeting and cannot ask you, because by then you are on something else.
The test to run before you circulate it
Give it to one engineer who was not in any of the conversations and ask them to tell you what they would build. Where their answer differs from your intention, the document is ambiguous — not them.
This takes fifteen minutes and it is the highest-return fifteen minutes in product management.
The document that makes engineering able to start
The test of a specification is not completeness. It is whether an engineer can read it and begin — and whether, three weeks in, it still answers the questions that come up.
- State the problem before the solution, in terms of who has it and what it currently costs them. A document that opens with a proposed design cannot be argued with except on implementation details.
- Name what is out of scope, explicitly. This is the highest-value paragraph in any specification and the one most often missing, because scope is defined by its boundaries and an unstated boundary gets crossed by default.
- Write the edge cases down. Empty, one, many, maximum, concurrent, duplicated, and what happens on retry. Engineers will ask; answering in the document answers it once instead of five times.
- Say how you will know it worked, with the metric and the window. If you cannot, that is worth discovering before anyone builds.
- Record the decisions and the alternatives rejected, with reasons. Six months later somebody will propose the rejected option again, and the document is the only thing that stops the argument being re-run from scratch.
The written-document culture, and why it is not about writing
Several large employers require a written document ahead of a decision meeting — one sends an engineering-manager candidate a writing assessment two days before the interview loop specifically to test it.
The point is not writing quality. It is that writing something down exposes reasoning that a presentation conceals. A slide can carry a claim with no argument behind it and nobody notices; a paragraph cannot.
The specific failure it prevents is the plausible-sounding plan whose steps do not connect. Reading it in silence, everyone finds the same gap independently, which does not happen when a confident person is talking over a diagram.
Practical version for any team: write one page before the meeting, circulate it, and spend the first ten minutes reading it in silence. It feels awkward exactly twice.
And for an interview: if you are asked for a writing sample, write about something genuinely complex that you drove, show the reasoning rather than the outcome, and expect to be asked about it in the loop. Candidates treat it as a filter and forget it; several employers explicitly discuss it during the interviews.
Check yourself