Product Management Prompt Pack: PRDs, Requirement Breakdown, and Roadmaps

A product manager's daily job isn't writing code, it's writing the documents that keep code from being wasted. A vague PRD sends dev off course; the team ships something nobody uses. A roadmap with the wrong priorities burns a whole quarter on features no one wanted. The root cause isn't execution, it's the input end of product decisions, a fuzzy requirement going straight into the sprint backlog like hiking without a map.

This pack breaks product management into three progressive levels: beginner turns vague needs into standard user stories with acceptance criteria; intermediate generates a structured PRD; expert does roadmap planning and requirement breakdown using RICE and MoSCoW for prioritization. Each level has a complete prompt with role, task, constraints, and output format. A competitor quick-look cheatsheet is included. Every prompt has built-in anti-fabrication rules: the AI only builds the frame, market data and user facts must be filled in by humans.

1. Beginner: User Stories and Acceptance Criteria

The user story is the smallest contract unit in product management. The template "As a... I want... so that..." has survived two decades in Agile because it forces "what to build" back onto "for whom" and "why." The classic beginner mistake is listing features without value or acceptance, dev builds it, and nobody can say whether it "succeeded."

This step makes the AI your requirement translator, turning "the boss said add search" into a structured story with role, value, and testable acceptance criteria.

You are a senior product manager skilled at turning vague requirements into actionable user stories.

Requirement description:
{{requirement description}}

Task: Translate the above requirement into a standard user story + acceptance criteria + open questions.

Output format:

1. User Story
   - Format: As a {{role}}, I want to {{action}}, so that {{value}}
   - Role must be a specific user type (not just "user")
   - Value must state what the user gains, not the feature itself

2. Acceptance Criteria
   - Each starts with "can ___", must be test-verifiable
   - At least 3 positive cases + 2 negative cases (bad input / no permission)
   - No subjective words like "smooth" or "good experience"

3. Open Questions
   - List facts you still don't know about this requirement, tag each "needs human input"
   - Do not fabricate answers, only list the questions

Constraints:
- Never fabricate user data, market numbers, or competitor share. For any external fact, mark "market data subject to research"
- End output with "The above is an AI draft, requires product owner approval before use"
- De-AI the tone: avoid empty buzzwords like "empower," "closed-loop," "comprehensive," use plain language with concrete subjects and actions

Key point: the biggest trap in user stories is writing the role as "user." Push the AI to write specific roles like "free-tier individual user" or "enterprise admin," only then can acceptance criteria land. The "open questions" section is one I added, the AI doesn't know your business facts, so having it list "what it doesn't know" is far more useful than letting it invent a plausible-sounding answer.

2. Intermediate: Generating a Structured PRD

User stories solve "single-point requirements," a PRD solves "where this feature fits in the product." A usable PRD isn't a feature list, it's a decision record: why build, for whom, to what extent, and what not to do. PRD templates abound online, but the core skeleton is consistent: background, goals, users, features, non-goals, flow, acceptance, risks, metrics.

This step makes the AI generate a PRD draft against a fixed skeleton. You fill in the business facts. The AI owns structural completeness, you own factual truth.

You are a senior product manager. Generate a structured PRD draft based on the following direction.

Product direction:
{{product direction}}

Output strictly in this structure:

## 1. Background
- Why build this (business problem or opportunity), max 3 sentences
- Mark any market data as "subject to research," do not fabricate numbers

## 2. Goals
- Business goal: quantifiable (e.g., "increase signup conversion by X%", X left blank to fill)
- User goal: what the user gains after completion

## 3. Target Users
- 2-3 user personas, each with: role, usage scenario, core need

## 4. Feature List
- Each feature: name, one-sentence description, priority (P0/P1/P2)
- Present as a table

## 5. Non-Goals
- What is explicitly out of scope this iteration, at least 3 items, each with a reason

## 6. Core Flow
- Numbered steps for the main flow, each annotated with input and output
- List 2-3 exception branches

## 7. Acceptance Criteria
- Each starts with "can ___", must be test-verifiable

## 8. Risks and Dependencies
- Technical risks, compliance risks, dependencies, each with specific items

## 9. Success Metrics
- What data to look at post-launch to judge success, give specific metric names (no fabricated numbers)

Constraints:
- Any market data, user counts, or competitor share must be marked "subject to research," no specific numbers
- End output with "The above is an AI draft, requires product owner approval before use"
- De-AI the tone: avoid "empower," "closed-loop," "comprehensive," "deep dive," every sentence needs a concrete subject and action

The critical sections are "Non-Goals" and "Success Metrics." Most PRDs have goals but no non-goals, features but no metrics. Non-goals prevent scope creep, success metrics give you a post-launch judgment tool. The AI will slack on these two, you must push it to write specific "what we won't do" and "what data to watch," not "depends on the situation."

3. Expert: Roadmap and Requirement Breakdown

A PRD solves a single feature, a roadmap solves "which features this quarter, and in what order." This is the dividing line for senior PMs: junior PMs want to build everything, senior PMs know what to skip. Prioritization isn't gut feel, it's a framework. RICE (Reach, Impact, Confidence, Effort) and MoSCoW (Must / Should / Could / Won't) are two widely adopted methods.

This step gives the AI a quarterly goal and asks it to break it into Epic -> Feature -> User Story, then prioritize and propose a roadmap.

You are a senior Product Owner. Based on the following quarterly goal, do requirement breakdown and roadmap planning.

Quarterly goal / constraints:
{{quarterly goal/constraints}}

Task:

1. Requirement Breakdown (three layers)
   - Epic: Break the quarterly goal into 2-4 Epics, each with a one-sentence value statement
   - Feature: Break each Epic into 2-4 Features
   - User Story: Break each Feature into 1-3 User Stories (As a... I want... so that...)
   - Present hierarchy as an indented table

2. Prioritization
   - Score each Feature with RICE: Reach(1-10) x Impact(0.25/0.5/1/2) x Confidence(0-100%) / Effort(person-weeks)
   - Also tag MoSCoW category (Must / Should / Could / Won't)
   - Leave Reach and Confidence blank tagged "needs human input", AI does not fabricate

3. Roadmap Suggestion
   - Schedule Must and high-RICE Features into the first 6 weeks
   - Should into the latter 6 weeks
   - Could / Won't into the backlog for observation
   - Annotate each week with expected Feature output, leave buffer for risk

Constraints:
- Market size, user base, conversion rates and other external numbers must be marked "subject to research"
- RICE Reach and Confidence must be left blank for humans to fill, do not fabricate
- End output with "The above is an AI draft, requires product owner approval before use"
- Start output with "This is a planning assumption based on current information, subject to iteration as validation comes in", a roadmap is not a promise
- De-AI the tone: avoid "empower," "closed-loop," and other empty buzzwords

The soul of RICE is the "Confidence" score, it forces you to admit what is a guess versus what has data backing. The AI is most prone to fabricating Reach and Confidence, so the prompt forces those blank. The opening line "a roadmap is an assumption, not a promise" is also key, too many teams treat roadmaps as pledges, penalize misses, and end up with no one daring to plan honestly.

4. Competitor Quick-Look Cheatsheet

Product decisions can't skip competitors. But competitor analysis easily falls into "copy a big table," listing 20 features with check marks that yields no decision insight. This cheatsheet skips the full report and gives you a "fast framework": a skeleton that guides your next move in 10 minutes.

You are a product analyst. Help me quickly build a competitor comparison framework, not a full report.

My product / direction:
{{product direction}}

Task: Output a lightweight competitor quick-look table with this structure:

1. Competitor List
   - Prompt me to fill 3-5 competitors, grouped into: direct competitors / substitutes / potential entrants
   - Leave names blank for me to fill, AI only gives category hints

2. Comparison Dimensions (pick 5)
   - Choose from: target users, core features, pricing model, differentiation, tech stack, distribution channels, content strategy, service model
   - For each, write one sentence on "why compare this"

3. Gap Opportunities
   - Based on the framework structure, flag 2-3 "what competitors may not do well" opportunity points
   - Tag each "needs validation", do not draw conclusions directly

4. Next Steps
   - List 3 specific questions on "what I need to research to fill this framework in"

Constraints:
- Never fabricate competitor-specific data (user counts, revenue, market share), mark all as "subject to public info"
- Do not predict "competitor X will definitely do Y", only describe observed current state
- End output with "The above is an AI draft framework, competitor facts require manual verification before filling in"
- De-AI the tone: avoid "comprehensive," "deep dive," and other empty words

The design philosophy here is "AI builds the frame, humans fill the facts." The most valuable part of competitor analysis is the real information you gather yourself by researching and trying products. The AI just gives you a skeleton that doesn't miss dimensions. The "gap opportunities" section is tagged "needs validation" because the AI tends to jump to conclusions from the frame, but conclusions need your real data to back them.

How to Use

The three levels aren't mandatory to run end-to-end, pick by scenario:

1. A requirement comes in: Run the beginner prompt to turn it into user stories, confirm role and value are on track.
2. Sprint planning: Run the intermediate prompt for a PRD draft, you fill in business facts, the team reviews against it.
3. Quarterly planning: Run the expert prompt for requirement breakdown and roadmap, dual RICE and MoSCoW prioritization gives you defensible priorities.
4. Scoping competitors: Run the cheatsheet prompt for a framework, you go fill in real info.

On model choice: structured reasoning (PRD, roadmap breakdown) works well with Claude or GPT-5; long-form document generation and Chinese expression are solid on DeepSeek; lightweight tasks like user stories work on all three. The key isn't the model, it's the constraints. Every prompt has anti-fabrication and de-AI rules baked in, keep those constraints whichever model you switch to.

Pitfalls

1. Letting the AI invent market data: PRD lines like "market size is X billion" or "user retention Y%" get fabricated by the AI down to the decimal. You must verify manually, the prompt already forces "subject to research," don't be the one who fills fake numbers back in.
2. Skipping PRD review: An AI-generated PRD draft is structurally complete but content-pending, the team must walk through it. Structural completeness does not equal correct decisions.
3. Treating the roadmap as a promise: A roadmap is an assumption based on current info, it changes as you validate. Taking it upstairs as a pledge sets you up for an awkward miss later.
4. RICE scoring entirely by AI: Reach and Confidence must be human-filled. AI-generated Reach=8, Confidence=80% looks plausible, it's all fake.
5. Competitor analysis as table-copying: 20 features with checkmarks yields no decision insight. After the cheatsheet gives you the frame, focus on "gap opportunities" and "what to research next."

References

• Anthropic, "Prompt engineering": docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
• Atlassian, "Product management": atlassian.com/agile/product-management
• Intercom, "RICE: Simple prioritization for product managers": intercom.com/blog/rice-simple-prioritization
• Agile Business Consortium, "MoSCoW Prioritisation": agilebusiness.org/dsdm-project-delivery/moscow-prioritisation.html
• ProductPlan, "What is a Product Roadmap?": productplan.com/learn/what-is-a-product-roadmap/
• Roman Pichler, "Product strategy and roadmap": romanpichler.com/blog/product-strategy/