The One-Pager That Replaced Our PRDs (Template Included)

The short version

We stopped writing PRDs three years ago. Replaced them with a one-page template covering six sections: problem statement, evidence (quotes plus data), proposed solution with prototype link, success metrics, risks and mitigations, ask (what's blocking you). It made execution 40% faster and improved communication because everyone reads one page instead of skimming the first three of a 30-page doc. The one-pager works because the page constraint forces clarity, everyone reads it, it stays relevant even mid-project, and it's a conversation starter, not a command. A working AI prompt to draft the first version in minutes is included. Use it on your next feature. PRDs are fossils by day five.

Three years ago, we stopped writing PRDs. Thirty-page documents that nobody reads. Outdated by the time they're done. The kind of spec work that makes engineers groan and designers skip to the wireframes.

Instead, we use a one-pager. One page. Maybe 1.5 if you count the AI prompt at the bottom.

It covers the problem, the evidence, what we're building, how we'll know it worked, and what could go wrong. No fluff. No "out of scope." No stakeholder theater.

This change made our execution 40% faster and actually improved communication because everyone reads one page instead of skimming the first three.

Why PRDs Fail (And Why One-Pagers Work)

The typical PRD is 20-30 pages. It covers background, related features, edge cases, future roadmap, legal considerations, and accessibility requirements.

Who reads that?

• Engineers: First 2 pages, then they ask questions anyway.
• Designers: Maybe the "User Flows" section, if it has diagrams.
• QA: Nothing. They wait for stories on the board.
• Executives: First page, maybe.

Meanwhile, you spent 15 hours writing it. A week later, assumptions changed, but the PRD didn't. Now it's a source of confusion: "But it says on page 17..." when the world has moved on.

The one-pager works because:

1. It fits on one page. Literally. That constraint forces clarity. You can't hide a bad decision in section 4.2.3.
2. Everyone reads it. Because it takes 5 minutes, not an hour.
3. It covers what matters. Problem and evidence (why we're doing this), solution (what we're building), metrics (how we know it worked), risks (what could go wrong). Everything else is detail work.
4. It's a conversation starter, not a command. Engineers and designers add to it. They propose changes. It evolves as understanding improves.
5. It stays relevant. Even mid-project, the one-pager is still true. PRDs are fossils by day five.

The One-Pager Template (Exactly What We Use)

Here's the template. Copy this, fill it in, done.

[PROBLEM STATEMENT]

[Write 2-3 sentences. What is the customer problem? Why does it matter?]

Example: "Enterprise customers spend 30-45 minutes per day switching between our app and Salesforce to log notes. This creates friction at deal close and risks lost deal context."

[EVIDENCE]

Customer quotes:

• "[Direct quote from customer interview]" - Customer Name, Company
• "[Direct quote]" - Customer Name, Company

Data:

• 60% of enterprise customers mention this as a friction point (survey of 47 customers)
• Average time wasted per customer: 40 mins/day
• Estimated annual cost to customer base: $2.1M in lost productivity
• Competitor [X] has this integrated; three customers mentioned it in exit interviews

[PROPOSED SOLUTION]

[2-3 sentences. What are we building? How does it solve the problem?]

How it works:

• [Step 1]
• [Step 2]
• [Step 3]

Prototype: [Link to Figma, prototype.app, or video]

Out of scope: [What we're NOT doing]

Example: "We're building Salesforce two-way sync. When a deal closes in our app, it syncs to SFDC as an opportunity. When notes are logged in our app, they push to the opportunity's notes field. No more copy-paste.

How it works:

1. User enables Salesforce sync in settings (OAuth flow)
2. Our app syncs deal updates to SFDC every 5 minutes
3. User can disable sync per deal if needed

Prototype: [Figma mockup link]

Out of scope: Reverse sync (SFDC → our app), custom field mapping, Salesforce Einstein scoring"

[SUCCESS METRICS]

What does success look like? Pick 1-3 measurable outcomes.

• Primary metric: [Metric + target]. Example: "Reduce time switching apps by 80% - target daily switch count from 12 to 2."
• Secondary metric: [Metric + target]. Example: "Increase data accuracy - 95% of deal notes in SFDC match notes in our app within 30 seconds."
• Adoption metric: [Metric + target]. Example: "30% of enterprise customers enable sync within 6 weeks of launch."

[RISKS & MITIGATIONS]

Risk: Salesforce sync breaks on duplicate deals. Customer has same deal in our app and SFDC twice. Mitigation: Built-in deduplication; user can manually merge before enabling sync.

Risk: Sync creates compliance issues if PII is exposed in Salesforce comments. Mitigation: Audit log + explicit data handling policy. Legal approval before launch.

Risk: Performance degradation if we're syncing for 1000+ customers at scale. Mitigation: Queue-based architecture (AWS SQS). Prioritize active deals. Load test with 10x expected volume before launch.

[ASK]

What do you need to move forward?

• Design sign-off (need mockup feedback by [date])
• Legal review of data handling policy
• Engineering feasibility assessment (how long to build?)
• Customer advisory board feedback
• [Anything else blocking you]

A Filled-In Example: Real One-Pager

Here's a real example I actually used (details anonymized):

[PROBLEM STATEMENT]

Customers don't discover advanced features because help is scattered across docs, email, and video. When they reach out with a feature question, 40% of the time the answer is "oh, we already have that - here's a 15-minute video." Lost opportunity cost and customer frustration.

[EVIDENCE]

Customer quotes:

• "I had no idea you could do X. I almost switched because I thought you were missing this." - VP Product, Series B SaaS
• "Your feature set is great but impossible to learn. The docs feel scattered." - Head of Ops, Enterprise

Data:

• 38% of support tickets are feature discovery questions
• Average time to answer: 25 minutes (we dig through docs + record a video)
• NPS impact: Customers who discover features organically have 15-point higher NPS
• Competitor has in-app feature tours; mentioned by 4 customers in win/loss interviews

[PROPOSED SOLUTION]

We're building in-app guided tours: contextual, interactive tutorials that appear when a user is in a feature for the first time. Tour content is authored once, then appears in-app. Customers can skip or replay tours anytime.

How it works:

1. Customer opens a feature for the first time (tracked via feature_first_seen event)
2. Small prompt appears: "New to this? Take a 90-second tour"
3. Click → step-by-step interactive guide (highlight UI elements, explain what they do)
4. Option to skip or replay anytime from help menu

Prototype: [Figma link to tour mockups]

Out of scope: Video tours, mobile app tours (Phase 2), custom tour builder for customers

[SUCCESS METRICS]

• Primary metric: 50% of feature discovery questions eliminated (from support volume) within 8 weeks of launch
• Secondary metric: 70% of users who see a tour watch it to completion
• Adoption metric: At least 5 guided tours live within 6 weeks of launch

[RISKS & MITIGATIONS]

Risk: Tours become annoying. Users get prompt fatigue. Mitigation: Limit to 1 tour per session. Max 3 prompts per day. Let users disable tour notifications.

Risk: We ship tours with bad guidance. Worse than no guidance. Mitigation: QA tours with actual customers before launch. Feedback loop: track drop-off points in tours, improve copy based on data.

Risk: Maintenance burden. Keeping tours in sync with UI changes. Mitigation: Tour content in structured format (JSON). Update tour alongside UI changes in the same PR.

[ASK]

• Design mockups (targeting feedback by March 28)
• Engineering feasibility assessment (is this 2 weeks or 2 months?)
• Legal: Do tours count as "communications"? Any compliance concerns?
• Pick first 5 features for tours (what's most impactful?)

How to Write Each Section (The Craft)

Problem Statement

Your goal: Make someone who hasn't used your product understand why this matters in 30 seconds.

Good: "Customers export data to Excel 5+ times per week to create reports. This takes 15 minutes per export and creates version control chaos."

Bad: "We need better reporting capabilities to improve the user experience and drive retention metrics."

The bad version doesn't explain why, what customers are frustrated with, or how much it costs them.

Formula: [Customer role] [does painful thing] [X times per week], [costs time/accuracy/money]. Competitor [Y] has this.

Evidence

Don't make claims without data.

Quotes: Get 2-3 direct quotes from customer conversations. Paraphrase is worthless - direct quotes are powerful. Include who said it.

Data: Pick numbers that matter. "47 customers surveyed" + "60% mentioned this" is stronger than "customers have been asking for it." If you don't have quantitative data, say so and commit to getting it before shipping.

Competitive signals: If competitors have this, name it. Not as desperation (don't lead with "everyone else has it"), but as evidence the market wants it.

Proposed Solution

Be specific enough that an engineer could scope it. Be vague enough that there's room for better ideas.

How it works: 3-4 bullet points maximum. Walkthrough the happy path. If it's complex, link to a prototype.

Prototype: Always include one. Figma mockup, prototype.app, or even a video showing the concept. This kills ambiguity.

Out of scope: This is critical. What are we NOT doing? It gives engineers permission to question optimizations and feature creep later.

Success Metrics

Be measurable. Be realistic.

Bad metrics: "Improve user satisfaction," "increase engagement," "drive adoption"

Good metrics: "Reduce feature discovery support tickets from 38 to 19 per week," "80% of enterprise customers enable Salesforce sync within 6 weeks," "reduce time to complete onboarding from 25 minutes to 8 minutes"

One primary metric (the thing that matters most). One or two secondary. One adoption metric if it's new functionality.

Risks & Mitigations

Be honest. Every feature has risk.

Risk: Performance problems, compliance issues, maintenance burden, customer confusion, competitive response

Mitigation: Not just "we'll be careful." Concrete steps: "load test with 10x volume," "legal review before launch," "feature flag so we can turn off if broken"

Ask

What's blocking you from moving forward? Be specific.

"Design feedback," "engineering feasibility assessment," "legal review," "customer interviews to validate," "buy-in from [specific person]"

Bonus: AI Prompt to Generate a First Draft

Hand this prompt to Claude with basic inputs and it'll generate a draft one-pager in minutes:

I'm writing a one-pager for a product feature. Generate a first draft based on these inputs:

Problem: [What's the customer problem?]
Evidence: [Customer quotes + data points]
Solution: [What are we building?]
Context: [Any other context?]

Generate a one-pager in this format:

---

### [PROBLEM STATEMENT]
[2-3 sentences]

### [EVIDENCE]
Customer quotes:
- "[quote]" - Name, Company
- "[quote]" - Name, Company

Data:
- [metric 1]
- [metric 2]

### [PROPOSED SOLUTION]
[2-3 sentences describing what we're building]

How it works:
- [step 1]
- [step 2]
- [step 3]

Out of scope: [what we're not doing]

### [SUCCESS METRICS]
- Primary: [metric + target]
- Secondary: [metric + target]
- Adoption: [metric + target]

### [RISKS & MITIGATIONS]
Risk: [risk description]
Mitigation: [concrete steps]

Risk: [risk description]
Mitigation: [concrete steps]

### [ASK]
- [ ] [Blocker 1]
- [ ] [Blocker 2]
- [ ] [Blocker 3]

---

Make it concrete and specific. Use real numbers where possible. Focus on impact, not implementation details.

Plug in your details, run it, then spend 15 minutes editing. You're done.

Transition from PRD to One-Pager

If your org currently writes PRDs, how do you switch?

1. Start with next feature. Don't retrofit the template to existing PRDs. Use it going forward.
2. Share the template. Show your team this post. Ask one person to try it.
3. Make it the norm. "Feature requires a one-pager before engineering starts" becomes policy.
4. Accept the adjustment period. Engineers will ask for more detail. That's OK - answer in comments on the doc. But don't let it become a 20-page document.

The Reality Check

One-pagers aren't perfect. You might need more detail for complex features. Build in a "details doc" as an appendix - linked from the one-pager but not the main page. The principle remains: the one-page version should be complete and sufficient for 80% of questions.

You'll find that writing tighter actually makes you think more clearly. Constraints force priorities. A feature that takes 15 pages to justify probably isn't worth doing.

Start today. Your next one-pager, not PRD. One page. Problem, evidence, solution, metrics, risks, ask.

You'll be faster, clearer, and actually get people to read your spec.