Problem and scope
Working Backwards starts with the customer experience and problem, then reasons back to a product solution. A PR/FAQ uses a customer-facing press release to state the core value and an FAQ to expose details customers and internal stakeholders will challenge. The question tests opportunity validation, scope control, metrics, and cross-team alignment; its category is product. It does not require a fixed template, and a polished document is not evidence that the need is validated.
What the interviewer is testing
Define a target customer and pain first, then make the promise falsifiable. Cover adoption conditions, data and privacy, cost, support, failure modes, success metrics, and stop conditions. Explain how interviews, prototypes, or a limited pilot will test the FAQ instead of treating a document written in isolation as proof.
Clarifying questions
- Who is the target customer, and how do they export data today?
- Is the costly or risky pain waiting time, format compatibility, authorization, or compliance?
- What data can be exported, and who can start, approve, or revoke it?
- Which outcome would customers pay for, and what alternatives exist?
- What are expected adoption, SLA, storage, and support costs?
- Which assumption, if falsified, should stop the project immediately?
A 30-second answer framework
“First narrow the customer and problem, then write a PR that describes only the customer result. Split the FAQ into value, workflow, boundaries, privacy, security, pricing, and operations, assigning evidence to every key assumption. Use interviews and a clickable prototype to test the hardest claims; define adoption, completion, failure, support-ticket, and cost ceilings. If evidence is weak, shrink the promise or stop rather than committing to a full platform.”
Step-by-step answer
Step 1: Define the customer and problem
Choose a specific role and situation, such as an administrator migrating a tenant before a contract ends. Record the current steps, time, errors, and compliance constraints instead of treating “every enterprise needs this” as the problem statement.
Step 2: Write the PR in customer language
The headline and opening should promise a customer outcome, such as a recoverable export with auditable authorization. Avoid internal architecture, technical jargon, and “industry first” claims; do not promise 100% success without evidence.
Step 3: Expose constraints with the FAQ
Answer data scope, formats, retention, permissions, approval, cancellation, retry, notification, price, SLA, support, and responsibility boundaries. Label each answer as known fact, hypothesis to test, or explicitly unsupported case, putting high-risk questions first.
Step 4: Design evidence and a pilot
Interview customers of different sizes and observe a real migration; use a prototype to test authorization, progress, and recovery. Limit the pilot to selected data types and tenants, measuring completion, retries, human intervention, support tickets, and infrastructure cost per export.
Step 5: Set decision gates
Write continue, narrow, and stop criteria into the document. For example, if a target customer cannot finish without extra manual approval, or unit cost exceeds budget, change the scope first. After review, map FAQ changes to the roadmap, runbook, and next experiments.
Model answer
“I would choose an enterprise administrator with a concrete migration job, quantify the current time, errors, and compliance risk, and write a customer-readable PR. The FAQ would answer authorization, formats, recovery, retention, SLA, pricing, and support, turning unknowns into testable hypotheses. Interviews, a prototype, and a constrained pilot would measure completion, failure, intervention, tickets, and unit cost. I would expand only after predefined gates are met; otherwise I would narrow the promise or stop. The PR/FAQ would evolve with evidence rather than approving a full platform once.”
Common mistakes
- Starting with architecture → customer value and problem stay vague → write a falsifiable outcome first.
- Turning the FAQ into marketing copy → risks, boundaries, and cost disappear → answer the hardest objections first.
- Assuming every customer is identical → pilot signals become uninterpretable → limit role, context, and alternatives.
- Looking only at adoption → intervention and support costs are hidden → track completion, failure, tickets, and unit cost.
- Having no stop condition → the pilot expands automatically → predefine continue, narrow, and stop gates.
- Never updating the document → decisions drift from evidence → version the FAQ through review and roadmap processes.
Follow-up questions
Follow-up 1: How does a PR differ from a requirements document?
The PR states the customer outcome and value; the FAQ captures details customers and stakeholders will challenge. A requirements document later defines implementation scope. A PR/FAQ validates and aligns an opportunity; it does not approve implementation by itself.
Follow-up 2: How do you avoid interviewing only supporters?
Sample by predefined roles, sizes, and current alternatives, and record refusals and failed attempts. Ask about alternatives, willingness to pay, and stop reasons; include counterexamples in the FAQ.
Follow-up 3: When should you stop?
Stop or narrow when the pain is weak, authorization or compliance cannot be met, pilot completion is below the gate, or unit cost stays above budget. Write the gate before the pilot so the standard cannot move afterward.
Follow-up 4: How does the document connect to the roadmap?
Map every FAQ hypothesis to a validation task, owner, and date. Verified promises enter the version scope; unverified or failed promises remain risks instead of being scheduled directly into development.