Product Requirements Generator (Spec → Build)
This prompt creates comprehensive product requirements that include the 'why,' detailed user flows, technical constraints, and acceptance criteria. It prevents the common problem where requirements are vague until engineering starts building and discovers missing details.
GPT / Claude13 variables
Prompt
Create a product specification for: {FEATURE}
PROBLEM STATEMENT
What problem does this solve? {PROBLEM}
For whom? {USERS}
Why is it urgent? {URGENCY}
BUSINESS GOALS
Success means: {SUCCESS_METRIC}
This will increase: {IMPACT}
Timeline: {TIMELINE}
THE FEATURE: {FEATURE}
COMPLETE SPECIFICATION:
OVERVIEW
[1 sentence what this is]
GOALS FOR THIS FEATURE
- Goal 1: [Specific, measurable]
- Goal 2: [Specific, measurable]
- Goal 3: [Specific, measurable]
USER PERSONAS & FLOWS
[For each main user type:]
Persona: {PERSONA}
Pain point: [What they struggle with]
User flow: "{PERSONA}"
[Step 1: User does X]
[Step 2: System shows Y]
[Step 3: User takes action Z]
[Step 4: Outcome/success state]
FEATURE BREAKDOWN
[Specific components/functionality]
Component 1: {DESCRIPTION}
- What it does
- Where it appears
- How users interact with it
Component 2: {DESCRIPTION}
[Continue...]
EDGE CASES & ERROR HANDLING
- If [condition], then [system does]
- Error: [What could go wrong] → [Recovery]
- Edge case: [Unusual but possible scenario] → [How handled]
TECHNICAL REQUIREMENTS
Platform: {PLATFORM}
Technology constraints: {CONSTRAINTS}
Integration needs: {INTEGRATIONS}
Performance needs: {PERFORMANCE}
ACCEPTANCE CRITERIA
The feature is done when:
- [ ] User can [action 1]
- [ ] System shows [outcome 1]
- [ ] [Edge case] is handled correctly
- [ ] Performance is [metric]
- [ ] All error states show helpful messages
- [ ] [Integration] works end-to-end
DEPENDENCIES
- Does this depend on [X]? Timeline: [when]
- Does [Y] depend on this? Timeline: [when]
Feature: {FEATURE}
Users: {USERS}Quick brief
Purpose
Turn product ideas into clear specifications that engineering can build without constant clarification meetings.
Expected output
A specification document including: problem statement, goals and success metrics, complete user flows with mockup descriptions, feature breakdown, technical requirements, edge cases and error handling, acceptance criteria, and dependencies.
Customize before copying
Replace these placeholders with your own context before you run the prompt.
{FEATURE}{PROBLEM}{USERS}{URGENCY}{SUCCESS_METRIC}{IMPACT}{TIMELINE}{PERSONA}{DESCRIPTION}{PLATFORM}{CONSTRAINTS}{INTEGRATIONS}{PERFORMANCE}
Works well with
GPT
Claude
Variations
Format as user stories (As a [user], I want [feature], so [benefit]).
Add technical architecture diagram.
Include data model changes required.
Create a phased rollout plan.
What this prompt helps you do
This prompt creates comprehensive product requirements that include the 'why,' detailed user flows, technical constraints, and acceptance criteria. It prevents the common problem where requirements are vague until engineering starts building and discovers missing details.
When to use it
Use before handing a project to engineering, when committing to a new feature, or when you want clarity on scope before starting. Most valuable for preventing 'wait, I didn't mean that' moments.
How it works
The prompt structures requirements with: problem statement and goals, user personas and flows, detailed feature breakdown, edge cases and error handling, technical constraints, and clear acceptance criteria for done-ness.
Best practices
Start with the problem you're solving, not the solution. Involve engineering early to understand technical feasibility. Define success metrics upfront. Test with real users if possible before building. Document assumptions explicitly.
Common mistakes
Vague requirements ('make it better'). Forgetting edge cases and error states. No acceptance criteria (how do you know it's done?). Constraints discovered mid-build. Missing why this matters (context for engineering).
What you should expect back
A specification document including: problem statement, goals and success metrics, complete user flows with mockup descriptions, feature breakdown, technical requirements, edge cases and error handling, acceptance criteria, and dependencies.
Limitations
Specs never capture everything—engineering will discover questions. User feedback may change specs mid-build. Perfect specs slow down iteration. Shipping often reveals what specs missed.
Model notes
Works with all models. Claude creates thorough specs. GPT structures them well. Provide your feature idea, target impact, and any constraints you know. Format: detailed narrative, technically feasible.
Real-world applications
SaaS companies use this for feature specs. Product managers use this to brief engineering. Startups use this to clarify MVP scope. Teams use this to reduce build ambiguity.
How to tell if it worked
Engineering builds it right the first time with minimal questions. QA can test against clear acceptance criteria. Launch meets the original goals. Negative scope creep during build.
Where to go next
Use Real-World Problem Solver if facing scope tradeoffs. Combine with Project Management Framework for timeline. Reference Data Storytelling to justify the requirements.
Related prompts
Feature Spec Template (Problem → Solution → Success)
Write feature specs that engineers and designers can actually build from.
Landing Page Copy Audit (Fix Confusing Text)
Improve website copy so users understand it in 5 seconds instead of leaving.
Technical Explainer (For Non-Technical Stakeholders)
Explain technical concepts without losing clarity or dumbing down.