Drafting the FAQ Section of a PR/FAQ Document
This skill teaches you to write external and internal FAQ sections that systematically stress-test every assumption in your PR/FAQ document, surfacing the hardest questions before a single line of code is written.
Start by listing every question a skeptical customer or executive would ask about your product concept. Split questions into external (customer-facing) and internal (stakeholder-facing) categories. External FAQs address usability, pricing, and value. Internal FAQs tackle feasibility, cost, timelines, and competitive risk. Write honest, specific answers backed by data or clearly labeled assumptions.
Outcome: You produce a complete FAQ section containing 10-25 external and 10-25 internal questions with honest, data-informed answers that expose weak assumptions, clarify scope, and give leadership the information they need to make a go/no-go decision.
Prerequisites
- A drafted internal press release (the PR half of the PR/FAQ)
- Familiarity with the Working Backwards framework and its purpose
- Basic understanding of your target customer segment and their pain points
- Access to stakeholders or subject-matter experts who can validate technical and business assumptions
Overview
The FAQ section is the most intellectually demanding part of the Working Backwards PR/FAQ document. While the press release paints an optimistic picture of the customer experience, the FAQ section exists to dismantle that optimism methodically, question by question, until only defensible claims remain. The FAQ is where you prove you have actually thought through the hard parts: the edge cases customers will encounter, the technical constraints engineers will face, the unit economics finance will scrutinize, and the competitive responses your strategy team will worry about. Without a rigorous FAQ, even a beautifully written press release is just marketing fiction.
The FAQ section splits into two distinct halves. External FAQs adopt the voice of a skeptical customer. They ask about pricing, ease of use, data privacy, compatibility, and why this product is better than what already exists. Internal FAQs adopt the voice of a skeptical executive or cross-functional partner. They ask about development cost, timeline, required headcount, technical feasibility, cannibalization risk, regulatory exposure, and how success will be measured. Both halves require different thinking modes: empathy for the customer, rigor for the business. This dual structure is what makes the PR/FAQ uniquely powerful compared to slide decks or one-page briefs, because it forces the author to argue both sides of every important question.
The concrete artifact you produce is a written document containing 20-50 questions and answers, organized into external and internal sections, with each answer grounded in data, research, or clearly labeled assumptions. This artifact becomes the centerpiece of PR/FAQ review sessions and is refined through multiple feedback cycles. A well-crafted FAQ section will save weeks of circular debate later, because every hard question has already been asked, answered, and pressure-tested in writing. Product managers who master this skill often report that it is also the single best preparation for product manager interview questions, because it trains you to anticipate objections, reason through tradeoffs, and communicate uncertainty with precision.
How It Works
The FAQ section works because it converts implicit assumptions into explicit, written claims that can be examined and challenged. Every product concept carries dozens of hidden assumptions: that customers will pay a certain price, that the technology can be built on schedule, that a market exists at sufficient scale, that regulatory requirements are manageable. When these assumptions stay implicit, they become invisible risks. The FAQ format forces each assumption into the open by framing it as a question a real person would ask.
The external/internal split is not arbitrary. It reflects two fundamentally different risk categories. External questions probe product-market fit: Will customers want this? Will they understand it? Will they pay for it? Will they trust it? Internal questions probe organizational feasibility: Can we build it? Can we afford it? Does it align with strategy? What happens if it fails? These two risk categories require different evidence, different expertise, and different decision-makers. By separating them, you ensure neither category gets buried under the other.
The mechanism of the FAQ is adversarial by design. You are writing the questions a hostile reviewer would ask. The best FAQ authors adopt the mindset of someone trying to kill the project, then switch to the mindset of someone defending it with evidence. This adversarial dynamic is what produces genuine intellectual honesty. If you find yourself writing softball questions with easy answers, you are doing it wrong. The questions should make you uncomfortable. The answers should require research you have not yet done, conversations you have not yet had, and decisions you have not yet made.
Within the Working Backwards framework, the FAQ section is where the real intellectual work happens. The press release is relatively easy to write because it is aspirational. The FAQ is where aspirations meet constraints. A common pattern is that writing the FAQ causes you to rewrite the press release, because answering hard questions reveals that the original vision was too broad, too expensive, or targeted at the wrong customer. This iterative tension between the PR and the FAQ is the engine that drives clarity. The FAQ also serves as institutional memory. Six months into development, when someone asks why a certain scope decision was made, the FAQ provides the documented reasoning. This makes the FAQ one of the most referenced artifacts across a product's lifecycle.
Step-by-Step
Step 1: Re-read the press release with a skeptic's eye
Before writing a single question, read your completed press release from start to finish as though you are a customer who has never heard of your company, then read it again as though you are a VP being asked to fund this initiative. Underline or highlight every claim that could be challenged, every number that could be questioned, and every benefit that could be dismissed as vague. Mark sentences where you used superlatives like 'best,' 'fastest,' or 'easiest' because those are guaranteed to generate questions. Also note anywhere the press release implies technical capability that does not currently exist.
This read-through produces a raw list of 15-30 potential question topics, which becomes your working inventory for the next steps.
Tip: Print the press release on paper and use two different colored highlighters: one for customer-facing claims, one for business or technical claims. This physical separation primes you to think in the two FAQ categories from the start.
Step 2: Generate external (customer-facing) questions
Working from your highlighted claims, write 10-25 questions phrased in the voice of a real customer. Use natural, conversational language. Avoid questions a customer would never actually think to ask. ').
Order the questions from most likely to be asked to least likely. Each question should map to a specific claim or gap in your press release. If you cannot generate at least 10 genuine customer questions, your press release may be too vague to trigger real curiosity.
Tip: Interview 2-3 people who match your target customer profile and ask them to read the press release. Record every question they ask, including the ones that seem obvious. Customers often ask questions that product teams forget to address because the answer seems self-evident internally.
Step 3: Generate internal (stakeholder-facing) questions
Now shift to the perspective of the executive, finance lead, engineer, or legal counsel who will review this proposal. '). Internal questions should feel uncomfortable to answer. If every answer comes easily, you are not asking hard enough questions.
Include at least two questions about what could go wrong and at least one about what you would do if initial results are poor.
Tip: Think about the last product review meeting you attended. What questions did leadership actually ask? Use those real patterns. Common executive questions include 'What is the opportunity cost of doing this instead of something else?' and 'What assumptions would need to be wrong for this to fail?'
Step 4: Write honest, specific answers to each question
For each question, write an answer that is specific, honest, and useful. ') in favor of direct statements ('Our research shows X' or 'We assume Y, and here is why'). Every answer should be 2-6 sentences. Short answers signal a shallow question that should be cut or combined.
Answers longer than 6 sentences usually contain multiple claims and should be split into separate Q&A pairs. Where you have supporting data, cite it with specifics: exact numbers, study names, customer quotes, or competitor benchmarks. Where you do not have data, say so explicitly and describe how you plan to get it. Label every key assumption with the word 'assumption' so reviewers can find them easily.
Tip: Use this structure for answers with uncertain data: 'Our current assumption is [X]. This is based on [source/reasoning]. We plan to validate this by [method] before [milestone].' This format gives reviewers both the claim and the path to verification.
Step 5: Identify and fill gaps in your question coverage
Review your complete list of questions against a checklist of standard risk categories: customer desirability, technical feasibility, business viability, regulatory compliance, competitive response, and operational readiness. For each category, verify you have at least two questions. If a category is missing entirely, it usually indicates a blind spot, not the absence of risk. Also check for the 'second-order question' pattern: if you have a question about pricing, do you also have a question about what happens if the price point does not work?
If you have a question about technical architecture, do you also have a question about what happens if the technology vendor raises prices or shuts down? These follow-up questions are where the most valuable insights often hide.
Tip: Share your draft FAQ with someone from a function you do not represent (engineering if you are in product, finance if you are in engineering). Ask them to identify the question they expected to see but did not find. Cross-functional blind spots are the most dangerous.
Step 6: Order and group questions for readability
Organize external questions into logical groups: product experience, pricing, trust and security, compatibility, and support. Organize internal questions into groups: feasibility, cost and resources, timeline, measurement, risk, and strategic fit. Within each group, place the most fundamental question first and the most nuanced question last. This ordering helps reviewers build context progressively.
Add a brief heading or label before each group so readers can navigate quickly. The total FAQ should read as a coherent document, not a random collection of Q&A pairs. If two questions have very similar answers, combine them into one question with a broader scope.
Tip: A good ordering test: read only the questions in sequence, ignoring the answers. If the questions alone tell a logical story about what this product is, who it is for, what it will cost, and what could go wrong, the ordering is working.
Step 7: Stress-test answers for intellectual honesty
' If the answer is yes and you are not acknowledging the uncertainty, revise it. Look specifically for three patterns of dishonesty that creep into FAQ answers. First, false precision: stating '15% conversion rate' when you have no conversion data. Second, cherry-picked comparisons: comparing your best feature to a competitor's worst feature.
Third, hidden dependencies: answers that assume ideal conditions without stating those conditions. For each answer, verify that the strongest counterargument has been acknowledged. An FAQ that presents only favorable evidence will be torn apart in review sessions and will damage your credibility.
Tip: Apply the 'newspaper test': if a journalist quoted your answer in an article about your product launch, would you stand behind every word? If not, revise until you would.
Step 8: Review with stakeholders and iterate
Share the complete FAQ with 2-4 trusted reviewers who represent different perspectives: a customer-facing team member, a technical lead, a finance or business operations person, and ideally someone senior enough to challenge strategic assumptions. Ask each reviewer two specific questions: 'What question is missing that you expected to see?' and 'Which answer do you not believe?' Collect their feedback, add any missing questions, and revise answers that were not convincing. This review step often generates 5-10 additional questions and significantly strengthens 3-5 existing answers. The FAQ is typically ready for a formal PR/FAQ review session after two rounds of informal review.
Tip: Do not ask reviewers if the FAQ 'looks good.' That question invites politeness. Instead, ask them to rank the three weakest answers. Forced ranking produces much more useful feedback.
Examples
Example: B2B SaaS analytics dashboard for mid-market sales teams
A product manager at a 200-person SaaS company is proposing a new analytics dashboard that helps sales managers identify at-risk deals. The press release promises real-time pipeline visibility, AI-powered risk scoring, and integration with Salesforce and HubSpot. The team is 4 engineers and 1 designer. Timeline pressure is high because a competitor launched a similar feature two months ago.
' (Answer: 'The score uses deal velocity, engagement recency, and historical win-rate patterns. In our beta test with 3 sales teams, it correctly flagged 72% of deals that eventually closed-lost. Assumption: this accuracy holds across different sales cycles. ' (Answer: 'Salesforce integration requires admin-level API access and takes 15-30 minutes.
HubSpot integration is OAuth-based and takes under 5 minutes. ' (Answer: 'Assumption: $2,400/month for streaming infrastructure at current projected scale. This triples if we exceed 500 concurrent dashboard users. ') The final FAQ contains 14 external and 16 internal questions.
During review, the engineering lead added three questions about data latency guarantees, and the finance partner challenged the $2,400/month infrastructure estimate, leading the PM to revise it upward to $3,800/month after deeper analysis.
Example: Consumer mobile app for meal planning at a 10-person startup
A small startup is pitching a meal planning app that generates weekly grocery lists based on dietary preferences, budget, and local store inventory. The team consists of 2 developers, 1 designer, and the founder/PM. They plan to raise seed funding and need the PR/FAQ to serve double duty as an investor communication tool. Budget for external research is minimal.
The founder writes external questions from the perspective of a busy parent who currently uses pen-and-paper lists. ' (Answer: 'At launch, the app supports one primary store per week. We chose this constraint to keep the grocery list accurate, since prices and availability differ between stores. Multi-store support is planned for v2, estimated 3 months post-launch.
' (Answer: 'Free for up to 2 meal plans per week. 99/month for unlimited plans, dietary filters, and budget optimization. ') For internal FAQs, the founder writes questions an investor would ask. 99/month requires 167,000 free users.
Our user acquisition plan relies on SEO content targeting meal planning keywords and TikTok recipe content. We have no paid acquisition budget at launch. ' (Answer: 'ChatGPT generates one-off meal suggestions but does not track pantry inventory, store-specific pricing, or dietary history across weeks. Our value is the system, not the single suggestion.
') The final document has 12 external and 11 internal questions. The investor-oriented internal questions proved especially useful during pitch meetings, where investors asked nearly identical questions.
Example: Internal platform tool at a large enterprise
A platform engineering PM at a 5,000-person financial services company is proposing an internal developer portal that standardizes service creation, monitoring, and documentation. The audience for the PR/FAQ is the CTO and VP of Engineering. There are no external customers. The development team would be 8 engineers over 12 months. The company has attempted similar initiatives twice before, both of which stalled after 6 months.
Since there are no external customers, the PM adapts the external FAQ to represent 'internal customers,' which in this case are the 400 software developers who would use the portal. ' (Answer: 'No. The portal integrates with your existing Jenkins, GitHub Actions, or GitLab CI pipelines via a plugin model. Initial setup requires adding a 15-line YAML configuration to your repo.
' (Answer: 'Existing services can be imported into the portal via an automated discovery scan. The scan identifies services registered in our service mesh and creates portal entries with pre-populated metadata. ') For the true internal FAQ, the PM focuses heavily on why this attempt will succeed when two prior attempts failed. ' (Answer: 'Both prior attempts failed due to scope creep: the 2021 attempt tried to replace CI/CD tooling, and the 2023 attempt tried to enforce a single programming language.
This proposal explicitly excludes both. Our scope is limited to service cataloging, health dashboards, and documentation generation. ') The FAQ contains 11 internal-customer questions and 18 stakeholder questions, with 5 questions specifically addressing lessons from prior failures. The CTO approved the initiative largely because the FAQ demonstrated that the team had studied the failure modes of the previous two attempts.
Example: Using FAQ skills to prepare for product manager interview questions
A senior PM preparing for interviews at a top-tier tech company practices the FAQ-drafting skill as a way to demonstrate structured thinking during case study rounds. The interviewer presents a hypothetical product concept and asks the candidate to identify the key risks and open questions.
The candidate receives a prompt: 'Imagine we are launching a feature that lets users schedule messages in our chat app. ' Rather than jumping to solutions, the candidate applies FAQ thinking by generating questions in two categories. For customer-facing questions, she asks: 'What happens if the recipient's time zone changes between scheduling and delivery? What if the sender wants to edit a scheduled message?
' For internal questions, she asks: 'What is the expected load on our message queue if 5% of daily messages are scheduled? Do we have regulatory obligations to store scheduled messages differently since they represent intent to communicate at a future time? ' The interviewer notes that these product manager interview questions demonstrate exactly the depth of thinking they want to see: the candidate identified customer experience gaps, technical infrastructure risks, and regulatory considerations without being prompted. The candidate explains that she developed this skill by drafting FAQ sections for PR/FAQ documents using the Working Backwards framework, which trained her to systematically decompose product proposals into assumption-testing questions.
This approach to framing product manager interview questions as FAQ-style interrogation stood out because it was structured, comprehensive, and demonstrated genuine product judgment rather than rehearsed frameworks.
Best Practices
Write external questions in the exact language your customers use, not in product jargon. If customers say 'Does it work with my Shopify store?' do not rephrase it as 'What e-commerce platform integrations are supported?' Customer language makes the FAQ feel authentic, and the language mismatch is immediately obvious to anyone who talks to customers regularly.
Label every assumption explicitly with the word 'Assumption' in bold or brackets. This makes assumptions scannable during review sessions. Without explicit labels, reviewers will spend half their time trying to figure out which claims are facts and which are guesses, and some assumptions will pass through unexamined.
Include at least two 'pre-mortem' questions in the internal FAQ, such as 'What would cause this product to fail in the first year?' and 'What is the most likely reason a customer would stop using this after the first month?' These questions force you to confront failure scenarios while there is still time to adjust scope, pricing, or positioning.
Keep each answer self-contained so it can be read without context from other answers. Readers rarely read FAQs sequentially. If an answer says 'As mentioned above...' you have created a dependency that will confuse readers who skip around. Repeat key context briefly rather than cross-referencing.
Update the FAQ every time a significant assumption is validated or invalidated during development. An FAQ that was written six months ago and never updated becomes a historical artifact rather than a living decision document. Assign a specific team member to own FAQ maintenance through launch.
Aim for a roughly equal number of external and internal questions. A large imbalance usually signals a blind spot. Too many external questions with few internal ones suggests the team has not thought about feasibility. Too many internal questions with few external ones suggests the team is building for themselves rather than for customers.
Write the hardest question first in each section. If the toughest question has a strong answer, it sets the tone for the entire section and gives reviewers confidence that you have done serious thinking. If the toughest question has a weak answer, you learn immediately where to invest more research.
Common Mistakes
Writing softball questions with obvious answers to make the FAQ look thorough
Correction
This happens when authors treat the FAQ as a marketing document rather than a stress test. The symptom is answers that are all confident and positive, with no uncertainty, no tradeoffs, and no acknowledged risks. Catch it by reading only the questions in sequence: if none of them make you nervous, they are too easy. Replace each softball with the hardest version of that question. Instead of 'Is the product easy to use?' try 'Why would a user who already has a working solution switch to this product and accept the cost of changing their workflow?'
Answering questions you do not actually have data for as though you do
Correction
Product managers often feel pressure to appear prepared, which leads to fabricating specificity. The symptom is precise numbers without cited sources, such as 'We expect 20% adoption in the first quarter' with no basis for that estimate. Watch for round numbers and projections that lack supporting evidence. Instead, write 'We estimate 15-25% adoption based on [comparable product X's launch data], with the caveat that our distribution channel differs in [specific way]. We plan to validate this estimate through [method] by [date].'
Including only product-focused questions and ignoring business model, operational, and organizational questions
Correction
This happens when the FAQ author works in isolation without consulting cross-functional partners. The FAQ covers features and customer experience thoroughly but says nothing about unit economics, support staffing, infrastructure costs, or legal review. The signal is an internal FAQ section that reads like an extended product spec. Fix it by sharing the draft with finance, legal, operations, and engineering and explicitly asking each function for their top three concerns about this initiative.
Writing answers that are too long and contain multiple arguments, making them impossible to challenge in review
Correction
When an answer runs longer than 6 sentences, it usually bundles several distinct claims together. Reviewers cannot easily agree with one part and challenge another, so the entire answer gets a vague 'looks fine.' Split compound answers into separate Q&A pairs. A useful test: if you could summarize the answer in one sentence without losing essential information, the answer is the right length. If you need three sentences to summarize it, it should be three separate questions.
Treating external and internal FAQs as the same type of document with the same voice
Correction
External questions should sound like a real customer talking. Internal questions should sound like a sharp executive in a review meeting. When both sections use the same formal product-management language, the external section loses its customer empathy and the internal section loses its rigor. Read each section aloud.
If the external questions do not sound like something you have heard in a user interview, rewrite them. If the internal questions do not sound like something you have heard in a leadership review, rewrite those too.
Writing the FAQ before the press release is complete
Correction
The FAQ exists to interrogate the claims made in the press release. If the press release is still changing, the FAQ will be interrogating a moving target and you will waste effort answering questions about claims that get removed. The press release does not need to be perfect, but it should be complete enough that the core value proposition, target customer, and key benefits are stable. Write the FAQ after the press release has been through at least one round of review.
Other Skills in This Method
Iterating PR/FAQ Documents Through Multiple Feedback Cycles
How to revise and strengthen a PR/FAQ document through successive rounds of leadership and cross-functional feedback, knowing when the document is ready to greenlight development.
Running PR/FAQ Review and Critique Sessions
How to facilitate Amazon-style narrative review meetings where stakeholders silently read the PR/FAQ document and then provide rigorous, structured feedback to sharpen the product concept.
Identifying Minimum Requirements by Working Backwards from Launch
How to use the Working Backwards process to ruthlessly scope down to the minimum set of technology, infrastructure, and features needed for a viable customer experience.
Using Working Backwards Thinking in Product Manager Interviews
How to apply customer-obsessed, Working Backwards reasoning to answer product sense, strategy, and prioritization questions in product manager interviews.
Writing Internal Press Releases for Product Concepts
How to craft a compelling, customer-centric internal press release that articulates the product vision, target customer, problem, and solution before any development begins.
Defining the Desired Customer Experience Before Building
How to start from the ideal end-state customer experience and systematically work backwards to identify the features, services, and technology required to deliver it.
Frequently Asked Questions
How many questions should the FAQ section contain in total?
Aim for 20-50 questions total, split roughly evenly between external and internal. Fewer than 20 usually means you have not interrogated the press release deeply enough. More than 50 often means questions are too granular and should be combined. The right number depends on the complexity of the product: a simple feature addition might need 20, while a new product line might need 40-50.
Should I draft the FAQ before or after writing the press release?
Always write the press release first. The FAQ exists to interrogate the claims and promises in the press release. Without a stable press release, you are generating questions in a vacuum. That said, the press release does not need to be perfect. Write a complete first draft of the press release, then draft the FAQ. Expect the FAQ process to reveal weaknesses that send you back to revise the press release, which is exactly how the Working Backwards process is designed to work.
How do I use FAQ-drafting skills to prepare for product manager interview questions?
The FAQ-drafting discipline trains you to decompose any product concept into customer risks and business risks, which is exactly what interviewers test. When given a case study or product critique question, mentally split your analysis into external questions (customer experience, value proposition, competitive positioning) and internal questions (feasibility, cost, measurement, risk). This gives you a structured, comprehensive response instead of a scattered list of observations. Interviewers consistently rate candidates higher when they demonstrate this kind of systematic risk identification.
What if I genuinely do not know the answer to a question I have written?
Include the question and write an honest answer that states what you do not know, what you would need to find out, and how you plan to find it. For example: 'We do not yet know the expected latency for this integration. Our next step is to build a proof-of-concept with the vendor API by March 15 to measure actual response times under load.' An unanswered question with a clear investigation plan is far more valuable than a fabricated answer. Reviewers respect intellectual honesty and lose trust in authors who bluff.
How long should each FAQ answer be?
Target 2-6 sentences per answer. Shorter than 2 sentences usually means the question is too simple or the answer is too vague. Longer than 6 sentences usually means the answer bundles multiple claims together and should be split into separate Q&A pairs. The exception is pre-mortem or risk-related answers, which sometimes need 7-8 sentences to describe the risk scenario, the mitigation plan, and the trigger conditions for escalation.
Should the FAQ section include questions about competitors by name?
Yes, for internal FAQs. Naming competitors directly in the internal FAQ is essential for honest analysis. Questions like 'How does our pricing compare to Competitor X?' or 'What happens if Competitor Y launches this feature first?' force you to do real competitive analysis. For external FAQs, use customer-natural phrasing like 'How is this different from what I already use?' which addresses the competitive question without naming specific competitors, since the press release is written as a public-facing document.
Why does my FAQ section keep getting longer without improving the quality of discussion in reviews?
This usually happens when you are adding questions about minor details instead of fundamental assumptions. A 60-question FAQ full of implementation details will overwhelm reviewers and bury the important questions. ' test to every question. If the answer is no, move it to an appendix or cut it. The FAQ should focus on the 20-30 questions that actually determine whether this product should be built, funded, and launched.