COMMON PITFALL
Working backwards: finish the go call
A filled template and a warm review meeting are not a decision.
By Michael Tor · October 2026
Colin Bryar and Bill Carr define Working Backwards as starting with the customer experience and working backwards to what to build, using a PR/FAQ as the principal tool. But the document is finished only when it produces a named go, no-go, or not-ready call. A filled template and a warm review meeting are not that call. Write the hard internal FAQ answers, run the review to uncover the truth, and do not commit people or money until the outcome is written down with who decided.
Who is this for?
This is for product managers and product leads who write Working Backwards PR/FAQs before a build - a new product, a major feature, or a platform bet. The tension is the illusion of progress. The template gets filled, the review meeting feels productive, and the team treats the finished document as permission to start building. Meanwhile, the hard internal questions about economics, dependencies, risks, and why alternatives lost remain hedged, and nobody actually wrote go, no-go, or not-ready.
What is the filled-template failure mode?
The primary failure mode is the sell-the-doc review. The press release reads well, but the hard internal FAQ answers are blank, hedged, or deferred to the build phase. The meeting ends with energy and a vague agreement to build, without a named go, no-go, or not-ready. Bryar and Carr frame the review as truth-seeking versus selling - the sell-the-doc meeting gets this exactly wrong. The inverse failure is the endless rewrite with no decision event, where truth-seeking becomes a reason never to decide.
A hypothetical example: A team wants an AI digest that emails each account a weekly summary of their activity. In the filled-template version, they write a polished one-page press release about finally knowing what happened last week, plus a short external FAQ. The internal answers on who already gets this from exports, what the support load looks like, and whether customers would change behavior are blank. The review ends with enthusiasm and a green light.
In the finished version, the internal FAQ states today's alternatives - a CSV export and a spreadsheet a CSM maintains. It names why those lose for a specific segment, and prices the support and model cost. The decision maker writes "not ready - need two weeks of interviews on whether anyone would stop using the export." The press release is revised after those interviews, and then a go or no-go is written.
When is a Working Backwards doc actually finished?
Check these six conditions before you open a ticket.
-
The customer and problem are named with evidence.
Bryar and Carr emphasize working customer-backwards, rather than skills-forward from what the team already knows how to build.
-
The press release would make a real customer change behavior.
Colin Bryar notes on Product Mastery Now that if the release does not convince a customer to switch from today's alternatives, you must rewrite it.
-
Hard internal FAQ answers are written.
Bryar and Carr define the FAQ as the map, and The PRFAQ notes it must articulate assumptions for strategic decision making.
-
The review was truth-seeking.
Bryar and Carr contrast truth-seeking with selling; Bryar adds that early meetings uncover the truth rather than greenlight a pitch.
-
A named go, no-go, or not-ready is written, with who decided.
Bryar states meetings end in yes, no, or not ready, and Bryar and Carr require a clear go or no-go at completion.
-
The outcome carries its required details.
If go, Bryar and Carr note resources are already in the FAQ; if not-ready, the missing information is named; if no-go, the reason is a copycat, small TAM, risky investment, unsolved problem, or priority.
When does Working Backwards help?
The process helps when a team is about to build from a skills-forward position instead of working customer-backwards, as Bryar and Carr describe. It works when many ideas need a funnel before a tunnel of builds, and when a review requires truth-seeking instead of a pitch. It also ensures a go call carries resources and next steps that are already written down. As a forcing function, discovery is for killing ideas, and the PR/FAQ provides the structure to find the no-go path early.
When does it hurt?
It hurts when the PR/FAQ becomes a ceremony whose mere existence is treated as the green light. It fails when "not ready" is never allowed and every review devolves into a sales meeting. It also stalls teams when they rewrite forever with no decision event, using the document to stop shipping your way out of thinking but replacing it with endless formatting. Finally, it hurts when the page is used as a template listicle instead of a strict deciding check.