create-prd-one-pager

name	create-prd-one-pager
description	Write a single-page PRD for leadership and partner audiences. Covers problem, proposal, impact, timeline, ask, and risks using business language. Use when you need to drive alignment and approval, not detail implementation.

Create PRD (One-Pager)

Generate a single-page Product Requirements Document for leadership and partner audiences. This format is deliberately concise -- it covers the problem, proposed solution, business impact, timeline, resource ask, and key risks. Everything a decision-maker needs to say yes, nothing they do not.

The discipline of a one-pager is compression. If you cannot explain it in one page, you do not understand it well enough yet.

When to Use

• You need leadership approval or alignment on an initiative
• You are pitching a feature or project to a partner team
• You want to circulate a proposal before investing in a full PRD
• The audience cares about "what and why," not "how"
• You need a document that can be read in under 5 minutes

When NOT to Use

• The audience is engineering and they need to build from this -- use create-prd-engineering
• You need a full cross-functional spec -- use create-prd (standard)
• You need an AI agent to build from this -- use create-prd-claude-code
• You need a formal decision with options and comparison -- use decision-brief

Inputs

Ask the user for:

1. Initiative name -- What are we calling this?
2. Problem -- What problem are we solving? Why does it matter now?
3. Proposed solution -- What are we proposing? (2-3 sentences max.)
4. Impact -- What is the expected business impact? Revenue, retention, efficiency, strategic positioning?
5. Timeline -- When would this ship? What are the key milestones?
6. Ask -- What do you need from the reader? Approval, resources, alignment, feedback?
7. Risks -- What could go wrong? What are the top 2-3 concerns?
8. Audience -- Who will read this? (This shapes the language and emphasis.)

If the user has an existing full PRD, distill it into one-pager format.

Outputs

A single-page PRD in markdown, following the template in references/template.md. The document fits on one printed page and includes:

• Title and metadata
• Problem statement (2-3 sentences)
• Proposed solution (2-3 sentences)
• Business impact (quantified where possible)
• Timeline (3-5 milestones max)
• The ask (what you need from the reader)
• Key risks (2-3 max)

Steps

1. Gather inputs -- Ask for the inputs above. If the user has an existing longer doc, read it and distill.
2. Write the problem statement -- Two to three sentences. Lead with the user or business pain. Avoid jargon. If the reader does not feel the problem, they will not care about the solution.
3. Write the proposal -- Two to three sentences describing what you are proposing. Stay at the "what," not the "how." No architecture, no technical details.
4. Quantify the impact -- Use numbers. "Reduces support tickets by 30%" is better than "improves customer experience." If exact numbers are not available, use estimates with ranges: "Expected to reduce churn by 5-10% based on comparable features."
5. Build the timeline -- Three to five milestones maximum. Each milestone is a date and a deliverable. Keep it high-level: "Q2: Beta with 10 pilot customers" not "Sprint 4: Complete API endpoint refactoring."
6. State the ask -- Be direct. "I am requesting approval to staff a team of 3 engineers for Q2-Q3" is clear. "I would love your thoughts" is not an ask.
7. List risks -- Two to three maximum. Each risk gets one sentence for the risk and one sentence for the mitigation. Do not list more than three -- this is a one-pager, not a risk register.
8. Edit for length -- The entire document should fit on one printed page. If it does not, cut. Every sentence must earn its place.
9. Review with the user -- Key question: "If a VP reads this in 3 minutes, will they understand the problem, the proposal, and what you need from them?"

Example Usage

User: "I need a one-pager to get VP approval for building a self-service analytics dashboard. We have 200+ ad-hoc data requests per month from clients."

Agent: Asks about the expected impact (time savings, CSAT improvement), timeline expectations, and what specifically the VP needs to approve (headcount, budget, priority). Produces a one-page PRD focused on business impact.

User: "Turn this 8-page PRD into a one-pager for the leadership review next week."

Agent: Reads the full PRD, identifies the core problem/solution/impact, and distills it into one-pager format. Flags if key information (like the ask or impact metrics) is missing from the source doc.

Guardrails

• One page means one page. If the rendered markdown exceeds approximately 500 words, it is too long. Cut ruthlessly.
• Business language, not engineering language. "REST API migration" means nothing to a VP. "Faster integrations for partners, reducing onboarding time from weeks to days" is what they care about.
• Quantify impact. Unquantified impact sounds like opinion. Even rough estimates with ranges are better than qualitative statements.
• The ask must be specific. "Thoughts?" is not an ask. "Approval to allocate 3 engineers in Q2" is. If the user does not know what they are asking for, help them figure it out before writing the doc.
• Do not hide risks. Leadership respects PMs who surface risks with mitigations. Two honest risks build more trust than zero risks, which reads as naive.
• Do not add sections. The power of a one-pager is constraint. Resist the urge to add "nice to have" sections. If it does not fit the template, it does not belong.

Related Skills

• create-prd -- Full PRD when the one-pager gets approved and you need to spec it out
• create-prd-engineering -- Engineering spec for the build phase
• decision-brief -- When you need a formal decision with options and comparison
• storytelling-for-impact -- When the one-pager needs a compelling narrative