TL;DR
Prompt engineering for product managers is different from prompt engineering for engineers. Engineering prompts demand correct code; PM prompts demand complete structure. This guide gives you 10 ready-to-use prompt templates for the real work PMs do with LLMs — generating personas, prioritizing features, writing user stories, drafting PRDs, researching competitors, and turning qualitative feedback into structured insights. Every template is copy-paste ready and includes the specific constraints that stop AI output from drifting generic. For the full pipeline context, see our pillar guide on AI product planning.
Why PM prompts are different
Engineers prompt LLMs to generate code. The test is binary: it runs or it doesn't. Product managers prompt LLMs to generate artefacts — personas, stories, PRDs, research summaries. The test is subjective: is this usable in the next meeting, or is it decorative?
This matters because the failure modes are different:
- An engineering prompt that fails produces a compile error — easy to diagnose and iterate.
- A PM prompt that fails produces plausible-looking stock output — the output looks correct, which makes the failure invisible until someone tries to use it.
The antidote is structural specificity in the prompt: naming the personas, demanding specific field formats, tagging every output category, and explicitly listing what the model must not produce. The 10 templates below apply this pattern.
10 templates
1. Customer problem exploration
Use when: you have a vague product hypothesis and need to pressure-test who it's for.
I'm exploring this product hypothesis:
<HYPOTHESIS>
Generate 5 distinct customer segments who might have this problem. For each segment:
- Segment name (specific — not "SMBs", but "Marketing ops managers at 20–100 person B2B agencies")
- Size of segment (rough TAM estimate with a reasoning sentence)
- Current solution (what they do today — with specific tool names)
- Pain severity on a 1–10 scale
- Willingness-to-pay indicator (how do we know they'd pay?)
- A question I should ask in a customer interview to validate
Rules:
- No segment can be a superset of another
- Rank by pain severity × size
- If a segment's willingness-to-pay is unclear, say so explicitly
2. Persona generator (linked)
Covered in depth in our persona generator guide. Short version:
Generate 3 user personas for this product: <PRODUCT DESCRIPTION>
Rules:
- No alliteration, no "Sarah the [role]"
- Specific roles, tools, and pains
- Each persona has a different primary motivation
- Output as JSON: { personas: [{ name, role, companyContext, dailyTools, goals, pains, quote, whyTheyMatter }] }
3. Feature prioritization (MoSCoW)
Use when: you have a list of ideas and need prioritization that stakeholders will accept.
Here's a list of feature ideas for <PRODUCT>:
<LIST>
Apply MoSCoW prioritization. For each feature:
- Priority: Must / Should / Could / Won't this iteration
- 1-sentence justification tied to a user persona or business goal
- T-shirt size estimate (S / M / L / XL)
- Dependencies on other features (explicit)
- Risk if we cut it: high / medium / low
Rules:
- Must-haves are REQUIRED for a minimum lovable product. Nothing else.
- Total Must-haves should be 30–40% of the list. If more, force some down.
- Every Should/Could must have a user persona it serves (name the persona).
- Won't-this-iteration items get a 1-line "revisit when" condition.
Output as a markdown table.
4. User story generator
Covered in depth in How to Generate User Stories from a Prompt. Short version:
Generate user stories for this feature:
<FEATURE>
Use INVEST format: "As <named persona>, I want <action>, so that <outcome>."
For each story, include:
- Persona name (must be from my existing persona list below)
- T-shirt size (S/M/L)
- Engineering scope: frontend / backend / fullstack
- Priority (Must/Should/Could)
Personas available: <LIST>
Rules:
- Every story must name a real persona (not "the user")
- Stories must be INVEST-compliant
- 3–5 stories per feature
Output as JSON array.
5. Acceptance criteria generator
Covered in depth in The Gherkin Playbook. The template:
For this user story:
<STORY>
Generate acceptance criteria.
Rules (do not skip):
1. At least 3 happy path, 4 edge cases, 4 failure states
2. Gherkin format: Given <precondition> When <action> Then <result>
3. Tag each: happyPath | edgeCase | failureState
4. Edge cases MUST cover: empty state, max limits, concurrent actions, stale session
5. Failure states MUST cover: unauthenticated access, invalid input, server error, rate limit
6. Specific values, not placeholders
Output as JSON array.
6. Competitive research summary
Use when: you need a fast landscape scan before a launch or a positioning document.
Research this competitive landscape: <SPACE>
For each of the top 5 competitors:
- Name + website
- Primary target segment (specific)
- Pricing model with specific numbers
- 3 differentiators (things they do that others don't)
- 3 weaknesses (things users complain about — search Twitter/Reddit)
- One positioning quote from their homepage (verbatim)
Then: a 1-paragraph analysis of the whitespace — what segment is underserved by all 5?
Rules:
- Only include competitors that exist and have a public website
- If you cannot find specific pricing, say "Unknown — verify"
- Weaknesses must be user-reported, not speculation
- Do not make up review quotes
Caveat: LLMs sometimes hallucinate competitor facts. Treat this output as a starting point for verification, not a finished report.
7. Stakeholder update (for async communication)
Use when: you need to write a weekly or biweekly stakeholder update and have 20 minutes.
Draft a biweekly stakeholder update for <PRODUCT>. The audience is: <AUDIENCE — e.g. executive team, investors>.
Structure:
1. Bottom-line metric (one number with direction vs last period)
2. What shipped (bulleted list with user impact)
3. What's in progress (bulleted list with ETA)
4. Blockers (bulleted list with ask)
5. Next period priorities (ranked)
6. Open questions
Rules:
- Every "shipped" item names the user impact (not just the feature)
- Every "in progress" item has an ETA or a "held — reason"
- Every blocker includes a specific ask (not "please help")
- Maximum 300 words total
Here are the raw inputs from my notes: <PASTE NOTES>
8. User interview synthesis
Use when: you ran 5–10 customer interviews and have transcripts you need to turn into insights.
I have interview transcripts from <NUMBER> customers in the <SEGMENT> segment.
<PASTE TRANSCRIPTS>
Synthesize the findings:
1. Common themes (appearing in 3+ interviews): list with representative quotes
2. Unique but striking insights (appearing in 1 interview but thought-provoking): list with the interview source
3. Contradictions (interviewees disagreeing): list with both sides
4. Language patterns (specific phrasing customers use repeatedly): for copy/marketing
5. Unmet needs (gaps between stated desire and current solution): explicit
6. Validated assumptions vs invalidated assumptions from my hypothesis list: <PASTE HYPOTHESES>
Rules:
- Tag every theme with interview IDs (P1, P2, etc.)
- Use verbatim quotes — no paraphrasing
- If evidence is thin for a theme, say "weak signal — validate further"
- Do not infer emotion — only report what was actually said
9. PRD draft
Covered in depth in AI PRD Generator: Free Templates. Short version:
Generate a standard PRD for this product: <DESCRIPTION>.
Include: Executive summary, Context, Goals, Non-goals, Personas (3), Features (MoSCoW), User stories (INVEST), Acceptance criteria (Gherkin), Non-functional requirements, Success metrics, Open questions.
Rules:
- Every story references a named persona
- Every AC is Gherkin-tagged by category
- Non-functional requirements: at least 2 specific items per subsection (performance, security, compliance, accessibility)
- Mark anything you can't determine as [OPEN: <question>], do not hallucinate
10. Retrospective prompt (for teams)
Use when: you need to structure a retro and the team is stuck.
Here are the notes from our sprint: <PASTE NOTES>.
Generate retrospective material:
1. 3 "what went well" moments with specific examples
2. 3 "what didn't go well" moments with specific examples (not generic)
3. 2 "improvements to try" suggestions — each must be a specific, testable action the team can commit to by next sprint (not "communicate better")
4. One question the team should ask themselves that they're probably avoiding
Rules:
- Every "went well" and "didn't go well" item references a specific incident or output
- "Improvements to try" must be doable in 1 sprint — not "become a better team"
- The avoided question is the most valuable part — don't soften it
The patterns across all 10 templates
Every template above shares four structural elements:
- Specific output format (JSON schema, markdown table, field list). Never "write X" without specifying the shape.
- Explicit rules list. The model follows rules it can see; vague expectations produce vague output.
- Named references (personas by name, features by name, stories by ID). Prevents the model from drifting into generic "the user".
- Negative constraints ("not this pattern", "banned phrases", "do not hallucinate"). What you want is half of a good prompt; what you don't want is the other half.
Master these four, and you can build your own templates for any PM task.
When templates are enough vs when you need a pipeline
The templates above work for one-off tasks. They start to break when:
- The output feeds another prompt. Personas from template 2 should be inputs to template 4. Copy-paste becomes error-prone.
- You need persistence. A persona you generated last week should still be available this week, referenced by every story you write.
- You need propagation. Editing a persona's goal should flag stories that reference that goal.
When those failure modes appear, you need a pipeline. VibeMap runs the same prompts above automatically with persistent state, linked artefacts, and change propagation. For a single task, use the template. For an ongoing product, use the pipeline.
Common prompt engineering failures
- Leading questions. "Generate 3 goals my users have" biases the output toward 3 even if reality has 5 or 2.
- No negative constraints. Models default to safe, generic output. Tell them what to avoid.
- Trusting the first response. Always generate twice and compare. Variance reveals model uncertainty.
- Missing context. "Personas for a SaaS app" is nothing. "Personas for a B2B SaaS app sold to marketing ops teams at 100–500 person agencies, competing with HubSpot and Marketo" is everything.
- Asking the model to evaluate its own output. It rates itself generously. Use a second model (e.g. Claude auditing GPT output) or a human reviewer.
Related reading
- AI Product Planning: The Complete Guide — the pillar covering the category.
- How to Generate an App Spec from a Prompt — the full pipeline, of which these templates are a subset.
- AI PRD Generator: Free Templates — deep-dive on template 9.
- AI Persona Generator for Product Teams — deep-dive on template 2.
Try the pipeline instead of copy-paste
🎯 All 10 templates, persistent state, linked artefacts, no manual context passing.
👉 Try VibeMap free → · Join the Product Hunt launch waitlist →
Sources & further reading
- Anthropic, Prompt engineering overview — reference for structured prompting with Claude.
- OpenAI, Best practices for prompt engineering with the OpenAI API — GPT-specific guidance.
- DAIR.AI, Prompt Engineering Guide — comprehensive catalogue of prompt patterns.
- Lilian Weng, Prompt Engineering (OpenAI research blog) — theoretical underpinning of the patterns used above.
