Working Backwards

When planning starts from what can be built, the explanation gets attached at the very end. Decide what to build, draw the screens, write the code, and only in launch week think about how to tell users. In that order, a feature that can't be explained is discovered after it's finished.

Search at Pagedeck went exactly that way. Theo spent three months rebuilding it, and in launch week Ravi asked what they should tell users. Put into a sentence, the only thing available was that search had gotten faster. The friction users actually had was failing to find a document when they didn't remember its exact title, and nothing built over those three months addressed that case. Speed improved and there was nothing to announce.

Working backwards inverts the order. The sentence that belongs at the end gets written at the beginning. Instead of hunting for something to announce after the work is done, you stop the work when there is nothing to announce. The method leans on the idea that what can't be put into writing won't reach a user either.

Start by writing the announcement customers will receive on launch day, in finished form. Not an outline or a draft — text that could go out as written.

There are six steps.

1. Write the customer and the problem in one sentence, with who, when and what blocks them. Something like: right after a meeting ends, someone looking for what was decided has to open ten past documents.
2. Write the announcement. Describe the change, not the feature name. Not "search has been improved" but "you can find a document by a sentence inside it even without the title." The format borrows the shape of a press release, the kind written for news outlets.
3. Write the questions you expect and answer them. What it costs, what changes for existing users, why now. A question with no answer is a decision not yet made, and it doesn't get left standing.
4. Fix the success criteria to a number and a date. Within two months the share of documents opened through search goes from 12 percent to 30 percent.
5. List what has to exist for the announcement to be true, in reverse order: the screen, the data that screen reads, the processing that produces that data. Technical discussion enters here for the first time, and the list it produces is raw material for the PRD.
6. Decide whether to proceed while it's still a document. Killing something before it is built is half of what this method produces. A document that dies still leaves its problem statement and its numbers behind for the next attempt.

Steps 2 and 3 combined into a single document give you a PR/FAQ. Teams name the sections differently, but announcement in front and questions behind stays the same. The announcement stays in customer-facing language throughout; internal reasoning belongs in the questions behind it.

It fits decisions that are hard to undo: work spanning a quarter or more, work several teams have to move on at once, selling something different from what you sell today. Two days on one document and then stopping is far cheaper than three months and then stopping. Filtering in prose rather than in a demo is the cost this method saves.

Three situations where it doesn't fit.

1. Improvements measured in days. Write an announcement and a question list for a button label change and the writing outlasts the building.
2. Responses where the work is already fixed. A field a new law requires leaves nothing to choose, so there is nothing to walk back from.
3. Work where demand itself is the question mark. Whether people want something can't be settled in prose. Product discovery, which checks whether something is worth building, or an MVP, the smallest product that tests a hypothesis, comes first, and this document comes after.

Two limits come with it. The first is that well-written prose reads as a good proposal. Smooth sentences pass without evidence, so it needs a companion rule: documents with the success criteria or the alternatives considered left blank don't get accepted. The second is that the document hardens into a contract. Defending the end state written six months ago after the situation has changed gives back exactly what inverting the order bought.

"I tried writing the launch announcement and couldn't get past two sentences. We should look again at whether this is worth building."

Reading the absence of text as a sign the evidence isn't there.

"We can't answer the pricing question in the FAQ. We're not starting development with that unsettled."

Treating a blank in the document as a decision that hasn't been made.

"This isn't a question a document settles. We have to build something small to find out."

Drawing a line around work this method doesn't suit.

After that first wasted run at search, Pagedeck restarted with the order changed. Mia wrote the announcement first, and its opening line was that you can find a document by a sentence inside it without knowing the title. Step 5 surfaced that making the line true required indexing document bodies in advance, and Theo spent two weeks checking only whether that was feasible.

One document died in the same meeting. It proposed tagging documents, and while writing the announcement nobody could state in one sentence what users would do less of. Tagging is itself a new chore handed to the user, and putting it into prose is what made that visible. Development never started, and the decision cost two days.

The most common reading is that this is an exercise in writing a plausible press release. The output is a document and the format resembles publicity, so it looks that way. What the method actually does is decide not to build things. It filters proposals that can't be written down; it doesn't package proposals already settled. Miss that and you accumulate a stack of documents with a 100 percent approval rate. A rejection rate of zero means the filter isn't running.

Reading it as a change of template is the other one, because a format is visible and an order isn't. The value sits in when the announcement gets written. Finish the planning and the build, then fill in the same template at the end, and the document becomes an approval form with the chance to kill it already gone.