How to Write a One-Page PRD (The Template I Used to Ship in 3 Months)
At Sonic Linker, we had one rule for product documentation: if it takes longer to read than a Slack message, you've already lost the engineer.
That sounds extreme. But when you're on a founding team shipping a core AI platform in 3 months, there's no time for 50-page requirements docs that nobody reads past page two. Every hour spent writing documentation that doesn't change a single engineering decision is an hour not spent on the product.
So we used one-page PRDs. And they worked.
This is the exact format, what goes in each section, and why every other section you've seen in a PRD template is optional at best.
Why Long PRDs Fail
Before we get to the format, it's worth understanding why traditional PRDs collapse in practice.
Long PRDs assume the writer knows everything upfront. They don't. Nobody does. The product will change once real users touch it. Writing 40 pages of detailed specs before that happens is documentation for a product that won't exist.
Research from product teams at companies like Figma, Linear, and Intercom shows that the highest-performing product teams converge on lean documentation, not comprehensive coverage. The insight is consistent: spend more time on the problem than on the solution.
Long PRDs also create a false sense of alignment. A document that everyone "approves" but nobody truly reads isn't alignment. It's theatre.
The most common mistakes in PRD writing are: - Using vague language ("user friendly", "seamless experience") that means different things to every person on the team - Over-specifying the solution before validating the problem - Writing static documents that become outdated and create confusion - Treating the PRD as a compliance exercise rather than a communication tool
A one-page PRD fixes most of these problems by forcing you to cut everything that isn't load-bearing.
The 6-Section One-Page PRD
Section 1: The Problem (4-5 sentences max)
This is the most important section. It gets the least attention. Most PRDs spend two sentences on the problem and two pages on the solution. Flip that ratio.
A good problem statement answers four questions: What is the problem? Who has it? How do you know it's real? Why does it matter to the business right now?
Bad: "Users are struggling with onboarding."
Better: "63% of trial users who don't complete account setup in the first session never return. The drop happens at step 3, the API key entry screen. This is costing us roughly 40 potential activations per week based on current signups."
The second version is specific enough that an engineer reading it understands the priority and scope without a meeting to explain it.
Section 2: Who This Is For (2-3 sentences)
One persona. Not three. If the feature serves multiple user types differently, write two PRDs.
Name the user, describe their context, and state what they're trying to accomplish when they hit this problem. Don't write a full persona document here. Just enough that the team can hold a specific person in mind while making decisions.
Section 3: Success Metrics (3 metrics max)
According to product management research, the most effective PRDs pair each success metric with a quantitative target and a timeframe. Not "improve activation" but "improve activation rate from 42% to 60% by end of Q3."
Three is the right number. More than three and you've lost focus. Fewer than two and you can't triangulate whether the feature actually worked.
At Sonic Linker, for our onboarding redesign, the three metrics were: 1. Session 1 completion rate: 42% to 65% in 6 weeks 2. Time to first AI generation: under 4 minutes 3. 7-day retention for users who completed onboarding: 70%+
Every design decision during that sprint ran through those three numbers. Did this change move us toward or away from those targets?
Section 4: User Stories (3-5 stories)
Use the standard format: "As a [user], I want [goal], so that [outcome]."
Keep them at the feature level, not the implementation level. "As a user, I want to complete API setup without leaving the onboarding flow" is a user story. "As a user, I want a modal that pre-fills the API key field" is a design decision, not a requirement.
The distinction matters because the first one gives engineers room to find the best solution. The second one locks them into yours before they've thought about it.
Section 5: What's Out of Scope
This section saves more time than any other. Write down every related thing you considered and decided not to do, with one line of reasoning for each.
"Custom API key labeling: out of scope, not a blocker for activation, revisit in Q4."
This stops the same conversation from happening five times across different Slack threads. It also signals to the team that you've thought about the edges and made a deliberate call, not just forgotten about them.
Section 6: Open Questions
What do you still not know? What decisions are blocked on external input? What assumptions are baked into this PRD that could invalidate it if they're wrong?
Being explicit about uncertainty is more valuable than projecting false confidence. A PRD with three honest open questions is more useful than one with no questions and hidden assumptions.
When to Use a One-Pager vs a Full PRD
Product management practitioners generally agree that one-pagers work for: - Features scoped under 6 weeks - Single-team work (not cross-functional epics) - Improvements to existing flows - Anything where the problem is already well-understood
Full PRDs (5-8 pages) are worth the investment for: - Multi-team efforts with complex dependencies - Regulated industries where documentation is a compliance requirement - Platform-level changes that will affect how future features are built - New product lines where the problem space itself is being defined
At most startups, 80-90% of your work falls into the one-pager category. Don't write a full PRD because it feels more professional. Write it because the complexity genuinely requires it.
The Actual Template
Here it is, one page, six sections:
---
PRD: [Feature Name] *Owner: [Your name] | Date: [Date] | Status: [Draft / In Review / Approved]*
Problem [4-5 sentences: what's broken, who's affected, evidence it's real, why now]
User [1-2 sentences: who specifically, what they're trying to do]
Success Metrics - [Metric 1]: from X to Y by [date] - [Metric 2]: from X to Y by [date] - [Metric 3]: from X to Y by [date]
User Stories - As a [user], I want [goal], so that [outcome] - As a [user], I want [goal], so that [outcome] - As a [user], I want [goal], so that [outcome]
Out of Scope - [Thing 1]: [one-line reason] - [Thing 2]: [one-line reason]
Open Questions - [Question 1] -- owner: [name] -- needed by: [date] - [Question 2] -- owner: [name] -- needed by: [date]
---
That's it. Print it on one page. Share it in Notion. Drop it in Slack. The format doesn't matter. What matters is that the person reading it understands the problem, the user, the target, and the constraints in under 3 minutes.
What I Learned Using This Format
Switching to one-page PRDs did two things I didn't expect. First, it made me think harder before writing. You can hide sloppy thinking in a long doc. You can't hide it in 400 words. Every sentence has to earn its place.
Second, it made engineers trust the documentation more. When the doc is short and specific, it's clearly been thought through. Long docs signal hedging. Short docs signal clarity.
The goal of a PRD is not documentation for its own sake. It's a shared understanding that lets a team make good decisions without needing a meeting to interpret the document. One page is usually enough to do that job.
If it isn't, the problem statement isn't clear enough yet. Keep working on that.