Draft a One-Page PRD From a Problem Statement
Turns a brief problem statement into a one-page PRD with problem, solution, success metrics, and rollout plan. Built for PMs who need a lightweight PRD format for small-to-medium features.
When to use this prompt
Use this when you have a clear problem but need a lightweight PRD to align engineering, design, and stakeholders without writing a 10-page document. You will need the problem statement, the target user, and a rough idea of the solution space. The prompt is deliberately constrained to one page because most features do not benefit from longer PRDs, and the forcing function of brevity leads to sharper thinking. It is not suitable for large initiatives with many stakeholders; use a full PRD format for those. Best for individual features that will ship in 1-3 sprints.
The Prompt
You are a senior product manager drafting a one-page PRD. The document must fit on a single page (under 500 words) and cover the minimum viable structure for a PM, EM, designer, and exec to align. Problem statement: {{problem_statement}} Target user: {{target_user}} Rough solution direction: {{solution_direction}} Business context: {{business_context}} Produce the PRD with these exact sections: 1. PROBLEM (2-3 sentences) â Describe what is broken or missing for the target user, in their language. No jargon. 2. TARGET USER (1 sentence) â The specific segment you are serving. Avoid "all users." 3. PROPOSED SOLUTION (3-4 sentences) â The approach at a high level. Describe the user experience, not the implementation. Include what you are explicitly NOT doing. 4. SUCCESS METRICS (3 bullets) â Primary metric with target, secondary metrics, and a counter-metric to watch (what could get worse). 5. KEY RISKS (2-3 bullets) â The things most likely to go wrong, each with a 1-sentence mitigation. 6. ROLLOUT (2-3 sentences) â How the feature will be released (beta, staged, feature flag, full launch) and any dependencies. 7. OPEN QUESTIONS (2-3 bullets) â What you do not yet know and who can answer each one. Rules: Keep it under 500 words. Do not pad. If a section has nothing meaningful to say, write "None at this time" rather than filling space with generic content.
Example Output
PROBLEM: Billing admins cannot tell at a glance which invoices are overdue, so they rely on manual spreadsheet exports every morning. This costs each admin ~20 minutes daily and causes overdue accounts to slip past their attention, delaying collections by an average of 9 days. TARGET USER: Billing admins at mid-market customers managing 50-500 invoices monthly. PROPOSED SOLUTION: Add an overdue-first sort and a visual status indicator to the invoices dashboard. Invoices past due will appear at the top by default with a red badge showing days overdue. Clicking an overdue invoice opens a pre-populated reminder email. We are NOT building a standalone overdue page, automated reminders, or SMS notifications in v1. SUCCESS METRICS: - Primary: reduce median days-to-collection by 30 percent within 60 days of launch. - Secondary: 70 percent of billing admins use the new sort within 2 weeks. - Counter-metric: no increase in complaints about the default dashboard view. KEY RISKS: - Billing admins may be used to the old sort and resist. Mitigation: in-app tour + opt-out. - Pre-populated email copy may feel too aggressive. Mitigation: customer interview review. - Overdue calculation depends on timezone handling. Mitigation: audit timezones in test data. ROLLOUT: Feature flag behind beta cohort of 20 customers for 2 weeks, then staged rollout over 1 week. No backend dependencies; UI-only change. OPEN QUESTIONS: - Should overdue include invoices in dispute? (Billing ops) - Is the red badge accessible in dark mode? (Design)
Recommended Tools
Notion and Coda both excel at hosting one-page PRDs with inline comments, making review fast. Productboard adds the advantage of linking the PRD to the originating customer insights and the roadmap item it implements. Notion is the lightest touch when your team does not need a full product ops stack; Productboard is the right choice when PRDs are frequently referenced in roadmap conversations.
Frequently Asked Questions
When should I use this prompt?
Use it for features that will ship in 1-3 sprints and have a clear problem but need alignment across 3-5 stakeholders. It is deliberately not for large initiatives; those need a full multi-page PRD with competitive analysis and technical design. Run it after discovery has validated the problem but before engineering scoping. If your organization does not use PRDs at all, this is a safe starting point because it is lightweight enough to adopt without overhead.
Is one page really enough?
For most features, yes. Longer PRDs often signal muddled thinking rather than thoroughness; the forcing function of one page exposes weak arguments and soft assumptions. That said, if your PRD touches compliance, pricing changes, security, or cross-team dependencies, a one-page document is too thin. Use it as a starting draft, then expand the sections that genuinely need more detail. The rollout and risks sections are most likely to need expansion for sensitive features.