Working backwards PR/FAQ for product managers
Our reviewers evaluate writing services independently. Learn how we stay transparent, our methodology, and tell us about anything we missed.
A working backwards PR/FAQ is a product framing exercise in which I describe the customer value of a future offering before committing to its implementation. The PR is a short, customer-facing announcement written as if the product were ready. The FAQ answers the questions customers, operators, leaders, and builders would ask about the promise. I use the pair to test whether the idea is clear, valuable, and coherent before a roadmap turns it into a presumed solution.
This is not a copywriting trick or a guarantee that the product will launch exactly as described. It is a forcing function. Writing for a customer makes vague internal language easier to spot, while writing the FAQ exposes assumptions about audience, behavior, scope, economics, operations, and risk.
Start with the customer problem
I begin with the customer and the situation, not the feature list. Who is trying to accomplish what? What is difficult about the current experience? What meaningful result would change if the product existed? I write the customer’s context in plain language and remove claims I cannot support.
The PR should make a focused promise. I avoid saying that a product is faster, smarter, simpler, or best unless I can explain what that means for a real customer and how I would know. I describe the before and after without inventing adoption numbers, testimonials, or performance claims. If the concept is still hypothetical, the document remains an internal exercise rather than public proof.
I ask whether the announcement would matter to the intended reader. A list of capabilities may be accurate and still fail to explain why anyone should change behavior. The strongest draft usually names a painful moment, the new way of working, and the outcome the customer can reasonably expect.
Write the PR in customer language
I keep the press release short enough to read as an announcement rather than a requirements document. I include a headline, a concise summary, the customer problem, the experience or result, and the next step. I write from the customer’s perspective and avoid internal names, architecture, team boundaries, and roadmap jargon.
I do not present an imagined customer quote as a real testimonial. If I use a quote in a workshop, I label it as a draft voice-of-customer line or leave it out. Product HQ’s editorial standard is clear on this point: I do not invent proof to make an idea sound validated.
The PR also helps me test scope. If the announcement needs ten unrelated promises to sound compelling, the product may be several bets mixed together. I narrow the audience, job, and outcome until the value is understandable without an explanation from the product team.
Use the FAQ to surface assumptions
I organize the FAQ around the questions that could change the decision. What exactly is included? Who is it for and who is it not for? What must the customer already have? How does the experience work? What happens when the workflow fails? How will we measure value? What does it cost to deliver and support? What privacy, security, accessibility, legal, or operational constraints apply?
I include hard questions rather than writing an optimistic defense. If the product requires a new process, an integration, behavior change, or manual service, I state that. If a benefit depends on data quality or a particular segment, I record the dependency. A useful FAQ makes uncertainty visible while there is still time to change the idea.
I separate questions that need evidence from questions that need design or engineering work. “Do customers experience this problem often enough?” calls for discovery. “Can we support the required permission model?” calls for technical and security investigation. “What should the first release exclude?” calls for product judgment informed by both.
Review it with the product triad
I review the PR/FAQ with product, design, and engineering together. The designer checks whether the described experience is understandable and inclusive. The engineer checks feasibility, data flow, operational burden, reliability, and hidden dependencies. Product checks the customer outcome, strategy, sequencing, and opportunity cost.
I invite other perspectives when the promise affects them. Support can identify likely failure modes, sales can explain buying friction, legal or security can flag constraints, and operations can test whether the service model is realistic. The goal is not to turn the document into a committee-produced encyclopedia. It is to discover risks that the core team cannot see alone.
I ask reviewers to mark statements as evidence, assumption, decision, or open question. This keeps polished prose from disguising a belief as a fact. I also ask which sentence they would remove if the team had half the time. That question often reveals scope that belongs in a later release.
Let disagreement improve the idea
A PR/FAQ is useful when it can be rejected or materially changed. If everyone is expected to approve the draft, the exercise becomes presentation theater. I welcome disagreement about the problem, target audience, promise, economics, or feasibility and turn the disagreement into a question or decision.
Sometimes the draft reveals that the value is too weak for the cost. Sometimes the FAQ shows that the intended user and buyer need different proof. Sometimes the concept is sound but the first release needs a narrower workflow. I treat these outcomes as progress because they happen before the team has invested heavily in delivery.
I avoid polishing language to hide an unresolved issue. A clear “we do not know yet” is more useful than a confident sentence that nobody can defend.
Connect the document to a learning plan
After review, I create a small set of tests. I may speak with people in the target context, prototype the key workflow, inspect existing behavior, validate an integration, or estimate a service process. Each test has a question, evidence boundary, owner, and decision it can influence.
I update the PR/FAQ as the product learns, keeping meaningful changes visible. The document is not a contract that prevents adaptation. It is a record of the promise and reasoning at a point in time. If the core customer or outcome changes, I say so rather than quietly preserving language that no longer fits.
A practical starting exercise
I choose one product bet and write a one-page PR for a specific customer and outcome. Then I write ten FAQ questions that could make the bet uncomfortable: adoption, value, feasibility, cost, safety, support, measurement, and scope. I mark each answer as known, assumed, or needing evidence, and I choose the riskiest question for the next test.
Working backwards PR/FAQ helps me make product strategy concrete without pretending that a polished announcement proves demand. It improves the idea when it is still flexible, connects customer value to delivery reality, and gives the team a shared artifact for deciding what to learn, build, defer, or stop.
Next step
A one-pager for PMs helps me compress an opportunity and its uncertainty before I decide whether a longer working-backwards brief is warranted.
Build stronger product strategy, discovery, and decision-making skills in the Product Manager Certification. Subscribe to the Product HQ newsletter for practical frameworks and career-ready product lessons.
