AI Prompt Template for Expanding Rough Ideas into Structured PRDs

Objective: Provide a reusable AI prompt that systematically expands a rough problem statement into a complete, reviewable Product Requirements Document (PRD) through ordered reasoning steps covering user personas, jobs-to-be-done, success metrics, functional requirements, edge cases and open questions.

The base prompt was formed through the following deliberate steps:

Identify the single input that product teams already have: a short, often incomplete problem statement.
Enforce a fixed Chain-of-Thought sequence so the model cannot skip critical sections or produce shallow summaries.
Insert modular control points (snippets and variables) that let teams inject brand voice, domain constraints, preferred format and desired depth without rewriting the entire prompt.
Require explicit labeling of each section so the output is immediately usable in review meetings or documentation tools.
Add a final open-questions block to surface assumptions and missing information rather than inventing details.

Note

The ordered sequence is non-negotiable. Changing the order risks incomplete coverage of edge cases or metrics that do not map back to real user jobs.

Prompt Template

You are a senior product manager with deep experience writing precise, reviewable PRDs.

{{snippet:brand_voice}}

Take the following rough problem statement and expand it step by step using Chain of Thought. Do not summarize. Produce a structured PRD.

Problem statement:
{{problem_statement}}

Follow this exact sequence and label each section clearly:

1. User Personas
   - Derive 2–4 primary personas that would be affected.
   - For each persona include goals, pain points and context.

2. Jobs-to-be-Done
   - List the core jobs each persona is trying to accomplish.
   - Phrase them in the format “When [situation], I want to [motivation], so I can [expected outcome].”

3. Success Metrics
   - Define measurable leading and lagging indicators that prove the problem is solved.
   - Tie every metric back to at least one job-to-be-done.

4. Functional Requirements
   - Translate the jobs and metrics into concrete, testable functional requirements.
   - Use “The system shall…” statements.
   - Group by priority: Must-have, Should-have, Could-have.

5. Edge Cases
   - Identify realistic failure modes, unusual user paths and boundary conditions.
   - For each edge case state the expected system behavior.

6. Open Questions
   - List remaining unknowns, assumptions that need validation, and decisions that require stakeholder input.

Constraints:
- Stay within the domain of {{domain}}.
- Keep the total length under {{max_length}} words unless more detail is required for clarity.
- Output format: {{output_format}}
- Tone: {{tone}}

Begin the expansion now.

Element	Type	Example Value
{{snippet:brand_voice}}	snippet	Write in a clear, direct style that avoids jargon and focuses on user impact. Prefer short paragraphs and bullet points.
{{problem_statement}}	variable	Users abandon the checkout flow because they cannot easily apply discount codes on mobile.
{{domain}}	variable	e-commerce mobile checkout
{{max_length}}	variable	1200
{{output_format}}	variable	Markdown with numbered headings
{{tone}}	variable	professional and concise

Prompt Example

You are a senior product manager with deep experience writing precise, reviewable PRDs.

Write in a clear, direct style that avoids jargon and focuses on user impact. Prefer short paragraphs and bullet points.

Take the following rough problem statement and expand it step by step using Chain of Thought. Do not summarize. Produce a structured PRD.

Problem statement:
Users abandon the checkout flow because they cannot easily apply discount codes on mobile.

Follow this exact sequence and label each section clearly:

1. User Personas
   - Derive 2–4 primary personas that would be affected.
   - For each persona include goals, pain points and context.

2. Jobs-to-be-Done
   - List the core jobs each persona is trying to accomplish.
   - Phrase them in the format “When [situation], I want to [motivation], so I can [expected outcome].”

3. Success Metrics
   - Define measurable leading and lagging indicators that prove the problem is solved.
   - Tie every metric back to at least one job-to-be-done.

4. Functional Requirements
   - Translate the jobs and metrics into concrete, testable functional requirements.
   - Use “The system shall…” statements.
   - Group by priority: Must-have, Should-have, Could-have.

5. Edge Cases
   - Identify realistic failure modes, unusual user paths and boundary conditions.
   - For each edge case state the expected system behavior.

6. Open Questions
   - List remaining unknowns, assumptions that need validation, and decisions that require stakeholder input.

Constraints:
- Stay within the domain of e-commerce mobile checkout.
- Keep the total length under 1200 words unless more detail is required for clarity.
- Output format: Markdown with numbered headings
- Tone: professional and concise

Begin the expansion now.

Tip

After the first run, feed the generated Open Questions section back into a follow-up prompt to force the model to propose concrete next research steps or stakeholder interviews.

Extended example values:

{{snippet:brand_voice}}
- Write in a clear, direct style that avoids jargon and focuses on user impact. Prefer short paragraphs and bullet points.
- Adopt a collaborative tone that invites engineering and design feedback while remaining decisive on scope.
- Use language suitable for cross-functional review: precise, free of marketing hype, and oriented toward measurable outcomes.
{{problem_statement}}
- Users abandon the checkout flow because they cannot easily apply discount codes on mobile.
- Support agents spend too much time manually reconciling inventory mismatches between the warehouse system and the online storefront.
- New users drop off during onboarding because the first-value moment takes more than three minutes to reach.
{{domain}}
- e-commerce mobile checkout
- B2B SaaS onboarding
- internal developer tooling for CI/CD pipelines
{{max_length}}
- 800
- 1200
- 1500
{{output_format}}
- Markdown with numbered headings
- Structured JSON with keys matching the six sections
- Confluence-ready wiki markup
{{tone}}
- professional and concise
- collaborative and precise
- formal yet approachable