promptprompts7 min read

Product Requirements AI Prompt Template

A reusable AI prompt template for product managers generating PRDs, user stories, acceptance criteria, and feature prioritization frameworks — with placeholder fields for product name, target user, problem statement, and constraints.

Use case: AI-assisted product requirements writing for product managers and product teams

Template objective#

This prompt template gives product managers a consistent, reusable structure for using AI to draft product requirements documents, user stories, acceptance criteria, and feature prioritization frameworks. It is designed to reduce the time spent on first-draft requirements writing while preserving the judgment, context, and specificity that come from the product manager's knowledge of the user and product.

Use this template to accelerate the creation of standard product artifacts. The output from each variation is a strong first draft intended for PM review, refinement, and validation with engineering and design — not a finished deliverable.

Prerequisites#

Before using any variation of this template:

  1. Define the product name and a brief description of what it does or will do.
  2. Document the target user — their role, context, and primary goal.
  3. Articulate the problem statement in one to two sentences.
  4. Identify any known technical or business constraints.
  5. Confirm which phase of development this artifact supports (discovery, definition, sprint planning, or post-launch).

Core prompt template#

Copy the block below and replace each [PLACEHOLDER] with your specific values.

You are a product manager working on [PRODUCT NAME] at [COMPANY NAME].

Product description: [ONE TO TWO SENTENCE DESCRIPTION OF WHAT THE PRODUCT DOES]
Target user: [USER ROLE AND CONTEXT — e.g., "a mid-market sales operations manager
who manages Salesforce configuration for a team of 20 AEs"]
Problem being solved: [SPECIFIC PROBLEM THE FEATURE ADDRESSES]
Business objective: [WHAT SUCCESS LOOKS LIKE FOR THE COMPANY — e.g., "reduce
onboarding time by 30%", "increase feature activation rate"]
Known constraints: [TECHNICAL, RESOURCE, REGULATORY, OR TIMELINE CONSTRAINTS]

Task: [INSERT SPECIFIC TASK FROM VARIATIONS BELOW]

Variation 1: PRD generation prompt#

For producing a structured first-draft product requirements document for a new feature or significant change:

You are a product manager at [COMPANY NAME].

Product: [PRODUCT NAME]
Feature name: [FEATURE NAME]
Target user: [USER DESCRIPTION]
Problem statement: [THE PROBLEM THIS FEATURE SOLVES]
Business objective: [MEASURABLE BUSINESS GOAL]
Out of scope: [EXPLICITLY EXCLUDE ANYTHING THAT IS NOT IN SCOPE FOR THIS FEATURE]
Known constraints: [TECHNICAL, RESOURCE, OR TIMELINE CONSTRAINTS]
Prior research: [SUMMARIZE RELEVANT USER RESEARCH, DATA, OR PRIOR WORK IF AVAILABLE]

Write a product requirements document (PRD) for this feature.

PRD structure:
- Summary (2-3 sentences): what this is and why we are building it
- Problem statement: the specific user problem, with evidence if available
- Goals: 2-4 measurable success metrics tied to business objective
- Non-goals: what this PRD explicitly does not address
- User stories: 4-6 user stories in format "As a [user], I want to [action] so that [outcome]"
- Requirements: numbered list of functional requirements
- Open questions: 2-4 questions that need answers before development begins
- Dependencies: other teams, systems, or features this work depends on
- Success metrics: how the team will measure if this feature achieved its goals

Tone: [TONE — e.g., "clear and concise, use specific and measurable language,
avoid vague qualifiers like 'easy' or 'flexible'"]

Variation 2: User story generation prompt#

For producing a well-formed set of user stories from a feature description or PRD:

You are a product manager writing user stories for [PRODUCT NAME].

Feature or epic: [FEATURE OR EPIC NAME]
Target user(s): [USER ROLE(S) — there may be more than one]
Feature description: [WHAT THE FEATURE DOES]
Acceptance criteria style: [CHOOSE: Gherkin (Given/When/Then) / numbered list /
checklist format]

Generate [NUMBER] user stories for this feature. For each user story:

1. User story: "As a [user role], I want to [action] so that [outcome]"
2. Context note: one sentence explaining why this story matters to this user
3. Acceptance criteria: [NUMBER] criteria in [CHOSEN STYLE]
4. Story size estimate: [CHOOSE: XS / S / M / L / XL] with one-line rationale
5. Dependencies: any other stories or systems this story depends on
6. Edge cases to consider: 2-3 edge cases the development team should be aware of

Prioritize stories from highest to lowest user value.
Flag any stories that require design review before development.
Flag any stories that introduce new technical dependencies.

Variation 3: Acceptance criteria prompt#

For generating detailed acceptance criteria for a specific user story or feature requirement:

You are a product manager defining acceptance criteria for [PRODUCT NAME].

User story: "[THE USER STORY TEXT]"
Feature context: [BRIEF DESCRIPTION OF THE FEATURE THIS STORY BELONGS TO]
Technical context: [RELEVANT TECHNICAL CONSTRAINTS OR IMPLEMENTATION NOTES, IF KNOWN]
User environment: [WHERE THIS FEATURE IS USED — e.g., "web app on desktop",
"mobile app iOS and Android", "API consumed by third-party integrations"]
Related features: [ANY EXISTING FEATURES THAT INTERACT WITH THIS ONE]

Generate acceptance criteria for this user story.

Format each criterion in Gherkin style:
  GIVEN [precondition]
  WHEN [user action or system event]
  THEN [expected outcome]
  AND [additional outcome, if applicable]

Cover:
- The primary success path (happy path)
- The most important alternative path
- At least [NUMBER] error or failure states
- Any edge cases involving: empty states, maximum values,
  concurrent users, or permission variations
- Performance expectation if response time is user-visible
- Accessibility requirement if this is a UI component

After criteria, list: [NUMBER] questions engineering should answer
before work begins.

Variation 4: Feature prioritization prompt#

For generating a structured prioritization framework across a set of candidate features:

You are a product manager prioritizing the feature backlog for [PRODUCT NAME].

Product context: [BRIEF PRODUCT DESCRIPTION AND CURRENT STAGE]
Target user segment for this prioritization: [USER SEGMENT]
Business priority for this quarter: [PRIMARY BUSINESS OBJECTIVE — e.g.,
"increase activation", "reduce churn", "expand to enterprise segment"]
Engineering capacity: [ROUGH CAPACITY — e.g., "one 4-person team for 6-week sprint"]

Features to evaluate:
1. [FEATURE NAME]: [ONE SENTENCE DESCRIPTION]
2. [FEATURE NAME]: [ONE SENTENCE DESCRIPTION]
3. [FEATURE NAME]: [ONE SENTENCE DESCRIPTION]
4. [FEATURE NAME]: [ONE SENTENCE DESCRIPTION]
5. [FEATURE NAME]: [ONE SENTENCE DESCRIPTION]

Evaluate each feature using the following criteria:
- User impact (1-5): how directly this solves a user pain point
- Business value (1-5): alignment with the stated business priority
- Confidence (1-5): how well-understood the problem and solution are
- Effort (1-5, inverted: 5 = low effort): estimated implementation effort

Calculate a priority score = (user_impact + business_value + confidence) × effort_inverse.

Output:
1. Scored and ranked feature list
2. Recommended build sequence with rationale
3. Features to defer and why
4. Risks or dependencies that could change the prioritization
5. Two questions the PM should answer before finalizing this prioritization

Customization guidance#

User specificity is the highest-impact field. The difference between "a user who wants to export data" and "a B2B SaaS operations manager at a 200-person company who needs to pull monthly usage data into a spreadsheet for a leadership report" is the difference between a generic user story and one that engineering can build against confidently.

Problem statement before solution. Each variation includes a problem statement field. Resist the temptation to fill this with a solution description instead. The AI will generate better requirements if the problem is stated clearly and the solution space is left open.

Acceptance criteria iteration. The Variation 3 output should be reviewed with the engineering team before it is treated as final. Engineers frequently identify implementation constraints that change what "correct behavior" means. Build in one review cycle before moving acceptance criteria to the sprint board.

Implementation guidance#

These prompts work best as part of a defined product workflow. The typical sequence is: PRD generation (Variation 1) → user story breakdown (Variation 2) → acceptance criteria detail (Variation 3) → backlog prioritization (Variation 4). Each variation's output feeds the next.

For a sprint-level workflow that connects these prompt outputs to sprint planning, standup automation, and retrospectives, see the Product Sprint Workflow Blueprint.

For context on how AI agents are being deployed across the product function, the AI agent use cases in product management guide covers patterns from teams using agents for discovery, requirements, and roadmap work.

Tags:
promptproduct-managementrequirementsuser-stories
← Back to Prompt Templates