The PR/FAQ Product Validation
"We're going to start with what's best for the customer and then come backward from there." — Bill Carr
What It Is
A product development process that starts with the customer by writing a Press Release and FAQ documents before any coding begins. This ensures the product solves a real customer problem and forces clarity of thought.
When To Use
- •At the very beginning of product development
- •Before allocating engineering resources
- •When validating new product ideas
- •To prevent "solution in search of a problem" failures
The Document Structure
┌──────────────────────────────────────────────────────┐ │ PRESS RELEASE (1 page) │ │ Written as if product already launched │ ├──────────────────────────────────────────────────────┤ │ • Headline: Name the product and customer benefit │ │ • Subhead: Who is the customer and what they gain │ │ • Problem: What problem does this solve? │ │ • Solution: How does the product address it? │ │ • Leader Quote: Why this matters strategically │ │ • Customer Quote: How a customer describes benefit │ │ • Call to Action: What should reader do next? │ └──────────────────────────────────────────────────────┘ ┌──────────────────────────────────────────────────────┐ │ FAQ (2-5 pages) │ ├──────────────────────────────────────────────────────┤ │ EXTERNAL FAQ (Customer questions): │ │ • How do I use this? │ │ • What does it cost? │ │ • How is it different from alternatives? │ │ │ │ INTERNAL FAQ (Feasibility questions): │ │ • How hard is this to build? │ │ • What are the dependencies? │ │ • How do we measure success? │ └──────────────────────────────────────────────────────┘
How To Apply
STEP 1: Define Customer Problem └── Who is the customer? └── What is their struggling moment? STEP 2: Draft Future Press Release └── Write as if it's launch day └── Be specific, not hyperbolic STEP 3: Draft FAQs └── External: Customer perspective └── Internal: Feasibility reality check STEP 4: Concentric Circle Review └── Start with small trusted group └── Expand to broader leadership └── Iterate based on feedback STEP 5: Leadership Approval └── Get resources only after validation
Common Mistakes
❌ Using hyperbole/marketing fluff instead of factual descriptions
❌ Writing it as a real external PR rather than internal validation
❌ Skipping the iterative review process
Real-World Example
AWS and Prime Video were both defined via PR/FAQs before they existed. The Fire Phone is cited as a failure where the process may have been overridden or the problem wasn't validated.
Source: Bill Carr, Co-author of "Working Backwards", Lenny's Podcast