Prompt engineering for PMs is a different job from prompt engineering for engineers, and the difference is in how failure shows up.
An engineering prompt that fails produces a compile error. Loud, immediate, easy to diagnose. A PM prompt that fails produces plausible-looking stock output, which means the failure is invisible until someone tries to use the artifact in a meeting and discovers it says nothing.
That asymmetry is why PM prompting leans so hard on structural constraints. You cannot rely on the output looking wrong, so you have to make it structurally impossible for it to be generic.
Below are ten templates. Six are unique to this post and cover work the rest of this blog does not touch. Four belong to the spec pipeline and are covered properly elsewhere, so I have listed them as pointers rather than repeating half of each guide here.
1. Customer problem exploration
Use when you have a vague hypothesis and need to pressure-test who it is actually 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 to 100 person B2B agencies"
- Rough size, with one sentence of reasoning
- Current solution: what they do today, with named tools
- Pain severity, 1 to 10
- Willingness-to-pay indicator: how would we know they'd pay?
- One question to ask in a customer interview to validate this
Rules:
- No segment can be a superset of another
- Rank by pain severity multiplied by size
- Where willingness-to-pay is unclear, say so explicitly rather
than estimating
The "no superset" rule stops the model returning five segments that are really one segment sliced by company size.
2. Feature prioritisation with MoSCoW
Use when you have a list of ideas and need prioritisation stakeholders will accept.
Here's a list of feature ideas for <PRODUCT>:
<LIST>
Apply MoSCoW prioritisation. For each feature:
- Priority: Must / Should / Could / Won't this iteration
- One-sentence justification tied to a persona or business goal
- T-shirt size: S / M / L / XL
- Explicit dependencies on other features
- Risk if we cut it: high / medium / low
Rules:
- Must-haves are REQUIRED for a minimum lovable product. Nothing else.
- Must-haves should be 30 to 40% of the list. If more, force some down.
- Every Should and Could names the persona it serves.
- Every Won't gets a one-line "revisit when" condition.
Output as a markdown table.
The percentage constraint is the one doing the work. Without it everything becomes a Must, which is the same as having no priorities, just with more ceremony.
3. Competitive research summary
Use when you need a fast landscape scan before a launch or a positioning doc.
Research this competitive landscape: <SPACE>
For each of the top 5 competitors:
- Name and website
- Primary target segment, specific
- Pricing model with actual numbers
- 3 differentiators: things they do that others don't
- 3 weaknesses: things users complain about
- One positioning line from their homepage, verbatim
Then: one paragraph on the whitespace. What segment is underserved
by all five?
Rules:
- Only competitors that exist and have a public website
- If you cannot find specific pricing, write "Unknown, verify"
- Weaknesses must be user-reported, not speculation
- Do not invent review quotes
A real caveat on this one: competitor facts are among the things models hallucinate most confidently. Pricing changes, products get acquired, and homepages get rewritten, all faster than any training cutoff. Treat this output as a list of things to verify, not as a report. I have seen it invent a pricing tier that never existed, complete with a plausible feature breakdown.
4. Stakeholder update
Use when you owe someone a biweekly update and have twenty minutes.
Draft a biweekly stakeholder update for <PRODUCT>.
Audience: <e.g. executive team, investors>.
Structure:
1. Bottom-line metric: one number with direction vs last period
2. What shipped: bulleted, each with the user impact
3. What's in progress: bulleted, each with an ETA
4. Blockers: bulleted, each with a specific 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 "held, because <reason>"
- Every blocker includes a specific ask, never "please help"
- Maximum 300 words
Raw inputs from my notes: <PASTE NOTES>
The word limit is the most important line. Left unconstrained, a model will turn six bullet points of notes into 900 words, and nobody reads the ninth paragraph of a status update.
5. User interview synthesis
Use when you ran five to ten interviews and have transcripts to turn into findings.
I have interview transcripts from <NUMBER> customers in the
<SEGMENT> segment.
<PASTE TRANSCRIPTS>
Synthesise:
1. Common themes appearing in 3+ interviews, with representative quotes
2. Unique but striking insights from a single interview, with the source
3. Contradictions where interviewees disagreed, with both sides
4. Language patterns: specific phrasing customers repeat, for copy
5. Unmet needs: gaps between stated desire and current solution
6. Which of my hypotheses this validates or invalidates:
<PASTE HYPOTHESES>
Rules:
- Tag every theme with interview IDs (P1, P2, ...)
- Verbatim quotes only, no paraphrasing
- Where evidence is thin, say "weak signal, validate further"
- Do not infer emotion. Report only what was said.
This is the template I would defend hardest. Synthesis across transcripts is genuinely tedious human work where models are strong, and the "do not infer emotion" rule is what keeps it honest, because inferred emotion is where synthesis quietly becomes fiction. Section 3 is the valuable one: contradictions are the finding, and human synthesists tend to smooth them away.
6. Retrospective material
Use when you need to structure a retro and the team is stuck in politeness.
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, each a specific testable action the team
can commit to by next sprint, not "communicate better"
4. One question the team is probably avoiding
Rules:
- Every item references a specific incident or output
- Improvements must be doable in one sprint, not "become a better team"
- The avoided question is the most valuable part. Do not soften it.
Point 4 is the entire reason to use this. A model has no social stake in the team and will name the thing everyone is politely not saying, which is a genuinely useful property and one of the few places where not being a person is an advantage.
7 to 10: the spec pipeline prompts
These four are covered properly elsewhere, with the full rules, worked examples, and the review checklists that go with them. Repeating shortened versions here would just give you a worse copy.
- Persona generation. AI persona generator for product teams, including the five-question audit that catches invented personas.
- User story generation. Generating user stories with AI, with the critique loop that makes the output usable.
- Acceptance criteria. What LLMs skip in acceptance criteria, with the twelve edge-case categories models omit by default.
- PRD drafting. AI PRD generator and free templates, with three complete templates.
The four things every one of these has in common
Look back at the six templates above and the same four structural elements appear in all of them.
A specific output format. JSON schema, markdown table, numbered field list. Never "write X" without saying what shape X should arrive in.
An explicit rules list. Models follow rules they can see. Vague expectations produce vague output, and "be thorough" is a vague expectation.
Named references. Personas by name, features by name, interviews by ID. This is what stops output drifting into generic "the user," and it is the single highest-leverage habit on this list.
Negative constraints. "Not this pattern," "banned phrases," "do not invent." What you want is half of a good prompt. What you do not want is the other half, and most people write only the first half.
Get those four right and you can build your own template for any PM task without needing anyone's library.
Where prompting fails
Leading questions. "Generate 3 goals my users have" gets you exactly three, even when the honest answer is five or one.
No negative constraints. Models default to safe and generic. If you have not said what to avoid, you have implicitly accepted it.
Trusting the first response. Generate twice and compare. Where the two runs diverge is where the model is uncertain, and that divergence is free information about which parts of your brief were thin.
Thin context. "Personas for a SaaS app" is nothing. "Personas for a B2B SaaS app sold to marketing ops teams at 100 to 500 person agencies, competing with HubSpot and Marketo" is a brief.
Asking a model to grade its own output. It rates itself generously, every time. Ask it to attack its output from a named adversarial role instead, or run the review in a different model, because the failure modes do not fully overlap.
When templates stop being enough
The templates above are built for one-off tasks, and they start to strain in three specific situations.
When one prompt's output becomes another's input, copy-paste becomes the weak link and you will eventually paste a stale version. When you need last week's persona to still be available this week, referenced by everything you wrote since. And when editing a persona's goal should flag the six stories depending on it, which no amount of prompt quality can do for you.
Those are bookkeeping problems rather than prompting problems, which is worth being precise about, because better prompts genuinely will not fix them. VibeMap handles that layer. For a single task, the template is enough and reaching for a pipeline is overkill.
Related reading
- How to generate an app spec from a prompt, the full pipeline these templates feed.
- AI product planning: the complete guide, the category pillar.
- How to pressure-test a product idea, which pairs well with template 1.
If you want to see the pattern applied end to end, the User Story Generator is a worked example of these four constraints in a single prompt. Free, no signup.
Sources and further reading
- Anthropic, Prompt engineering overview: structured prompting reference.
- OpenAI, Prompt engineering guide: GPT-specific guidance.
- DAIR.AI, Prompt Engineering Guide: a broad catalogue of prompt patterns.
- Rob Fitzpatrick, The Mom Test: why template 5's "report only what was said" rule matters.
