Working Backwards

A product-development approach that starts from the desired customer experience and reasons backward to what must be built, rather than starting from existing capabilities and pushing forward. Its signature mechanism is the PR/FAQ: before building anything, write the press release announcing the finished product to customers, plus an FAQ answering the hard questions, and iterate on that document until the idea is compelling and clear.

Why it Matters

Teams default to building what is easy or interesting and then searching for a customer, which produces products nobody wanted. Working backward forces the value proposition, the customer, and the problem to be explicit and convincing on paper, where changing direction is cheap, before expensive engineering begins. If you cannot write a compelling press release, the product is not worth building yet.

Signals

• A roadmap driven by existing technology or internal convenience.
• "Build it and they will come"; features justified by capability rather than customer need.
• No clear, written statement of who the customer is and why they would care.

Benefits

Kills weak ideas cheaply, aligns everyone on the customer outcome, and turns a vague concept into a concrete, debatable artifact before code is written.

Risks

Writing an aspirational press release for a product you cannot actually build (fiction); going through the motions without honest customer insight; treating the document as a one-time gate rather than a living argument.

Tensions

Working backward demands up-front clarity, which feels slow against the bias to start coding; and a polished narrative can persuade even when the underlying idea is weak, so the discipline depends on intellectual honesty.

Examples

Drafting the customer-facing announcement and FAQ for a feature, then revising until the benefit is obvious, before committing engineers; abandoning an idea because no honest press release could make it compelling.