AI Prompts for Product Managers

Act as a senior product manager. I'm going to give you a one-line problem statement. Before drafting any PRD, do this:

1. State the assumptions you're making about audience, scope, and constraints. Number them. I'll correct any that are wrong.
2. Then produce a PRD with these exact named sections: Problem, Goal, Non-goals, Success metrics, Open questions.
3. The Open questions section must contain 3-5 questions an engineer or designer would actually ask in review - not generic 'what's the timeline'. Specific to this feature.

Do not pad. Do not write a 'Background' section. Do not invent metrics that I haven't given you data for - if you don't know the baseline, the success metric should say 'TBD - need baseline from {{metric_source}}'.

The one-line problem:
{{problem_statement}}

Why it works: PRDs are the most-cited PM AI use case in the 2026 Lenny's survey - 87% of PMs use AI for them.

Example: Assumptions I'm making (correct me before I draft): 1.

Read full prompt page →

Read the raw customer interview transcripts below. Produce:

1. The top 5 themes ranked by frequency (number of interviews where the theme appeared). For each theme, give 2-3 verbatim quotes - exact words, not paraphrased.
2. 3-5 Jobs-to-be-Done candidates surfaced from the patterns, in the format 'When I {situation}, I want to {motivation}, so I can {outcome}.'
3. Anything that surprised you - a signal that contradicts the assumed pain points or that came up unprompted in multiple interviews.

If I've pasted fewer than 3 transcripts, refuse and ask for more - 3 is the minimum for a real signal.

The transcripts:
{{transcripts}}

Why it works: Customer interview synthesis is the single biggest opportunity gap in PM AI work - the 2026 Lenny's survey shows a 27-point gap between current usage (4.7%) and desired usage…

Example: Themes ranked by frequency across 7 interviews: 1.

Read full prompt page →

Convert my raw bullets below into a weekly stakeholder update. Use exactly three sections:

1. Shipped: each item with a one-line outcome, not a feature name. 'Filter persistence rolled out, 18% reduction in time-to-first-result' - not 'Shipped filter persistence.'
2. Stalled: each item with the specific blocker named (person or thing) and an ETA if one exists. Do not include items that are just 'in progress' - those don't belong here.
3. Asking for help: each item with the specific decision or action needed and the named decision-maker. If there are no asks, write 'No asks this week' explicitly.

Banned phrases: synergy, leverage, circle back, touch base, on track, in flight.

My raw bullets:
{{raw_bullets}}

Why it works: Stakeholder updates are the third-most-cited PM AI use case (74% report value, 18.5% top value).

Example: Week of 2026-04-26: Shipped: Filter persistence rolled out to 100% of power users.

Read full prompt page →

Convert the messy debate input below into a structured one-page decision memo. Use exactly these sections:

1. Decision: stated in one sentence.
2. Options considered: 2-3 options, each with a one-line description and the tradeoff. Do not invent options that weren't actually on the table.
3. Criteria: the criteria used to choose, in priority order. Maximum 4.
4. Recommendation: one paragraph stating which option and why, anchored to the criteria.
5. Risks: 2-3 risks with one-line mitigations each.
6. What would change our mind: the specific conditions under which we'd reverse this decision. This section is mandatory - if you cannot fill it, the decision isn't actually decided yet.

The messy input:
{{debate_input}}

Why it works: Decision memos are the highest-leverage PM artifact - a one-pager that survives a Slack scroll three weeks later, a new exec joining mid-discussion, or a postmortem six months on.

Example: Decision: Ship cross-device sync as opt-in for the first 30 days, then evaluate.

Read full prompt page →

Read the raw retro notes below (post-its, Miro export, Slack debrief - whatever the team produced). Produce:

1. Themes: items mentioned by 3+ team members, with the underlying source named ('on-call rotation', 'design handoff timing', etc.). Not just labels - the cause.
2. Action items: each with a named owner and a 'try by' date. Do not list actions without owners; either find one in the input or flag 'no owner identified'.
3. Escalate up: only items that genuinely cannot be solved inside this team and have a named recipient at a higher level. Not a complaint dump.
4. Consciously drop: items from previous retros that nobody picked up. Mark each as 'drop unless someone advocates within 7 days.'

The raw notes:
{{retro_notes}}

Why it works: Sprint retros produce the messiest, most valuable raw text in PM work - and the writeup almost always falls on the PM late on Friday.

Example: Themes (mentioned by 3+ team members): Code review queue grew to 9-day average.

Read full prompt page →

Convert the messy input below (Slack thread, bug report, feature ask, customer email) into a clean ticket for {{tool}}. Use this format:

Title: action-oriented, specific enough to find later by search. No 'improve' or 'fix' as the only verb.

Summary: one paragraph. What's happening, who's affected, why it matters.

Acceptance criteria: in Given / When / Then format. Maximum 3 criteria - if you need more, the ticket is too big and should be split.

Severity: P0 / P1 / P2 / P3 with one-line rationale.

Edge cases: 2-4 specific cases the engineer should handle explicitly.

Instrumentation: what metrics or events should be added so we can verify the fix worked. This section is mandatory.

The messy input:
{{messy_input}}

Why it works: PMs spend a surprising amount of time converting messy Slack threads into clean Jira/Linear tickets.

Example: Title: Filter state lost when iPad app backgrounds for 30+ minutes Summary: Power users on iPad lose their applied filters when the app is backgrounded for ~30 minutes (matches…

Read full prompt page →

Given my draft roadmap and quarter context below, write a roadmap rationale memo. Use this structure:

1. Rationale: one paragraph. Why these priorities, in the order shown. Anchor to evidence (data, customer feedback, business constraint).

2. Pushback 1 (skeptical exec): name the most likely exec-level objection. Pre-answer it.
3. Pushback 2 (frustrated engineer): name the engineering objection (scope, sequencing, technical debt). Pre-answer it.
4. Pushback 3 (missed-out PM): name the objection from a peer PM whose work got de-prioritized. Pre-answer it.

Each pre-answer must acknowledge the pushback before responding to it. Reframe, don't dismiss.

My draft roadmap and context:
{{roadmap_and_context}}

Why it works: Roadmap memos are the prompt PMs are most likely to outsource to AI badly.

Example: Rationale: We're prioritizing the cross-device sync work this quarter over the new analytics dashboard because (1) the sync gap is the #1 churn reason in the last 50…

Read full prompt page →

I'm planning an A/B test. Help me write a rigorous hypothesis. Use this exact structure:

1. Hypothesis: stated as a directional prediction with a magnitude. Format: 'Doing X will change metric Y by at least Z%, because [mechanism].'

2. Experiment design: audience, split, duration (or sample-size threshold), exclusions.

3. Success criteria:
- Primary: the metric and threshold.
- Secondary: a sanity-check metric.
- Guardrails: 1-2 metrics that must NOT degrade (downstream funnel, refund rate, support load).

4. Expected lift: a range with reasoning. Why this number, not a different one?

5. What would falsify: the specific result that would tell us we were wrong - not just 'no effect' but the direction and threshold.

The test I'm planning:
{{test_description}}

Why it works: A/B test hypotheses are the prompt where most PMs accidentally do bad statistics.

Example: Hypothesis: Replacing the 'Add to cart' button label with 'Buy now' will increase the cart-add rate by at least 8% on the product detail page, because the 'Buy now' framing…

Read full prompt page →

Six months from now, the launch described below failed. Work backward and produce three layers:

1. Causal failure: the proximate reason it failed (an adoption number, a metric drop, a user reaction).
2. Upstream cause: what was true earlier that made the proximate failure inevitable. The decision, gap, or assumption upstream of the proximate cause.
3. Early warning sign: something I could observe today (in the beta, in interviews, in current data) that would predict this failure.

Then propose one concrete mitigation I could implement this week to address the early warning sign.

Do not constrain the failure mode in your reasoning - if you find a failure I didn't predict, name it.

The launch:
{{launch_description}}

Why it works: Pre-mortem is the single most under-used PM decision tool.

Example: Six months from now, the cross-device sync launch failed.

Read full prompt page →

Build a one-page persona from the real customer evidence below (transcripts, surveys, support tickets, sales notes - any direct customer voice). Use exactly these 5 sections:

1. Who they are: role, context, demographic shape. Cite the source ('5/8 interviews fit this shape').
2. What they're trying to do: their job-to-be-done in their words. Include a verbatim quote.
3. What's getting in the way: evidence-backed pain. Include a verbatim quote and a count of how many sources mentioned it.
4. Current workaround: what they do today to cope. Often 'do nothing' or 'use a template' - both are valid.
5. What would change for them: if you solved the pain in section 3, what concretely changes in their week.

Do not invent quotes. If you can't find evidence for a section, write 'no direct evidence in input' rather than fabricate.

The evidence:
{{customer_evidence}}

Why it works: Personas built from imagination are the worst documents in product.

Example: Persona: 'Maya, the busy growth PM at a Series B SaaS' Who she is: 28-34, 2-4 years PM experience, owns one product surface (not the full product), reports to a Head of Product or…

Read full prompt page →

Tear down the competitor below from a product-strategy lens. Use this structure:

1. Positioning: how they describe themselves and their target market. Quote their actual marketing language.
2. Proof: what they actually deliver based on the input I've given you (changelog, screenshots, pricing). Where the marketing matches the product.
3. Weakness: where the positioning breaks down or the product doesn't deliver on the claim. Be specific.
4. Your counter-angle: the strategic move I could make that they cannot easily copy without breaking their own positioning. If you can't find one, say 'no defensible counter-angle in this comparison' - that's a valid finding.

Competitor input (URL, changelog, pricing page, screenshots, recent updates):
{{competitor_input}}

My product (one-line):
{{my_product}}

Why it works: Competitor teardowns produced by AI are usually generic feature lists.

Example: Competitor: Notion AI Positioning: 'AI built into the workspace you already use' - leans on existing Notion install base, frames AI as a feature not a product.

Read full prompt page →

Below is a wish-list of features. Convert it into a scoped plan with these three sections:

1. MVP (ship by end of quarter): the smallest meaningful slice that delivers the core value. Maximum 5 items. If you need more than 5, force a cut and explain it.
2. Next increment (next quarter): items that should ship soon but don't fit the MVP. Maximum 5 items.
3. Explicitly out of scope (do not add back without a new decision): items dropped from the MVP, each with a one-line reason ('speculative', 'requires X infra', 'low signal from interviews', etc.).

End with a one-paragraph reasoning explaining why this slicing.

The wish-list:
{{wish_list}}

Why it works: Wish-list-to-MVP is the single hardest scoping conversation in product.

Example: Wish-list (15 items) → MVP scope: MVP (ship by end of quarter): 1.

Read full prompt page →

I have a technical decision to make between two options. Translate the tradeoff into business-shaped language a non-technical exec (CFO, CEO, Head of Sales) can decide on. For each option produce:

- Cost: in money, time, or both. Specific numbers if I've given them.
- Capability: what becomes possible (or impossible) with this choice. In business terms - 'handles 100x growth' not 'eventually consistent'.
- Risk: what could go wrong. Include the engineer-side risk that the team might be motivated to downplay.
- Timeline: when each option pays off (immediately, year 1, year 2-3, etc.).

End with a one-line recommendation AND a 'when to revisit' clause - the conditions under which we'd reconsider this decision.

No jargon in the option descriptions. If a concept needs jargon, define it inline in plain language.

Option A:
{{option_a}}

Option B:
{{option_b}}

Why it works: Engineering tradeoffs are where PMs lose the room.

Example: Option A: Postgres with logical replication.

Read full prompt page →

Convert the strategic goal below into one objective + three key results. Rules:

1. Objective: a measurable outcome stated as a state-of-the-world, not an activity. 'Power users feel the product gets meaningfully more useful over time' - not 'Improve power-user retention.'

2. Key results: exactly three. Each must:
- Be independently measurable (no compound KRs).
- Have a starting baseline and a target ('from X to Y'). If the baseline is unknown, write 'baseline TBD - need {{measurement_owner}} to pull'.
- Name the metric source explicitly: dashboard ID, query, survey instrument, or report. Without a named source, the KR is unverifiable.

3. End with a one-line note describing the mix of leading vs. lagging indicators - and why you picked that mix.

No activities as KRs ('Run 5 customer interviews' is a task, not a KR).

The strategic goal:
{{strategic_goal}}

Why it works: OKRs are the artifact PMs are most likely to write badly under deadline.

Example: Strategic goal input: 'We need to fix retention for power users this quarter.' Objective: Power users feel the product gets meaningfully more useful the longer they use it.

Read full prompt page →

This is step 1 of a four-step chain. Read the raw customer feedback below (interviews, support tickets, NPS comments, app reviews, sales call notes). Produce:

1. The top 5-7 themes ranked by frequency (count of mentions).
2. Per theme: 2-3 verbatim quotes - exact words, not paraphrased.
3. End with a marker line so I remember to continue: '--- End of step 1. Paste this output into Discovery-to-decision: step 2 (impact rank). ---'

If I've pasted fewer than 20 raw items, refuse and ask for more.

The raw feedback:
{{raw_feedback}}

Why it works: This is step 1 of the four-step Discovery-to-Decision chain - the headline differentiator no competing PM pack ships.

Example: Themes from 47 raw feedback items: 1.

Read full prompt page →

This is step 2 of a four-step chain. Below is the themed output from step 1. Re-rank the themes by addressable impact - that is, by:
- Cohort size affected (% of users)
- Signal strength (how consistently the pattern appears)
- Addressability (can we actually do something about it?)

For each theme, produce:
- Mention count (carry over from step 1).
- Impact rationale: one paragraph weighing the three factors above.
- 'What we could do': a first-pass response, not a full solution.

Keep all themes from step 1 - do not drop any. Just re-order.

End with a marker: '--- End of step 2. Paste this output into Discovery-to-decision: step 3 (solution candidates) along with the top theme to explore. ---'

The themed output from step 1:
{{step1_output}}

Why it works: Step 2 of the chain.

Example: Themes ranked by addressable impact: 1.

Read full prompt page →

This is step 3 of a four-step chain. Below is the impact-ranked output from step 2 plus the top theme I want to explore. Produce 2-3 distinct solution candidates - not variations of one approach, genuinely different approaches.

Per candidate:
- What we'd build: one paragraph.
- How it addresses the theme: link the build directly to the customer pain.
- Engineering effort: rough estimate (days or weeks).
- What to validate: the assumption inside this candidate that we'd want to test before committing.

If two candidates are minor variations of the same approach, force a structurally different option C.

End with a marker: '--- End of step 3. Pick the strongest candidate and paste it into Discovery-to-decision: step 4 (decision memo). ---'

Step 2 output + top theme:
{{step2_output_and_theme}}

Why it works: Step 3 of the chain.

Example: Top theme being addressed: Setup friction (14 mentions, 100% of new users affected).

Read full prompt page →

This is step 4 of a four-step chain - the payoff. Below is the chosen solution candidate from step 3. Produce a decision memo using this structure:

1. Decision: one sentence.
2. Options considered: the 2-3 candidates from step 3, each with a one-line description and the tradeoff.
3. Criteria: priority-ordered list of what matters in this decision. Maximum 4.
4. Recommendation: one paragraph anchored to the criteria.
5. Risks: 2-3 risks with one-line mitigations.
6. What would change our mind: the specific conditions under which we'd reverse course (mandatory).

The full chain (steps 1-4) takes ~20 minutes and produces a decision memo grounded in real customer evidence rather than your assumptions. Use it on decisions you don't already have a strong opinion about - the chain is designed to challenge priors, not confirm them.

The chosen candidate from step 3:
{{chosen_candidate}}

Why it works: Step 4 of the chain - the payoff.

Example: Decision: Ship solution C (skip permissions, degraded mode) over Q3 weeks 1-3.

Read full prompt page →