1. PRD First Draft Generator
Writing a PRD from scratch is slow, and starting from a blank doc means you forget sections or skip edge cases. This prompt forces a complete structure: problem statement with evidence, user stories with acceptance criteria in Given/When/Then, success metrics with target values, and an explicit out-of-scope section. The [ASSUMPTION] flags make your unknowns visible to engineering before the review meeting, which saves a round of back-and-forth.
You are a senior product manager. Write a comprehensive PRD for the following feature:
Feature: [FEATURE NAME]
Product: [PRODUCT NAME]
Target user: [DESCRIBE PRIMARY USER]
Problem it solves: [WHAT PAIN POINT OR JOB-TO-BE-DONE]
Include these sections:
1. Executive Summary (3 sentences max, what, why, and expected impact)
2. Problem Statement (specific user pain with evidence, customer quotes, support ticket data, or analytics if available)
3. Proposed Solution (how it works at a high level, NOT implementation details)
4. User Stories (5-8 stories in 'As a [user], I want [action] so that [outcome]' format with acceptance criteria in Given/When/Then)
5. Functional Requirements (prioritised as Must Have / Should Have / Nice to Have)
6. Non-Functional Requirements (performance, security, accessibility, scalability)
7. Success Metrics (3-5 measurable KPIs with target values and measurement method)
8. Edge Cases and Open Questions (at least 5 edge cases to consider)
9. Dependencies and Risks (what could block or derail this)
10. Out of Scope (explicitly list what this feature does NOT include)
Write for an engineering audience who needs enough detail to estimate and build, but keep each section concise. Flag any assumptions you are making with [ASSUMPTION].
How to use it: Replace the four bracketed fields at the top (feature name, product, target user, problem). Review the output section by section, cut anything generic, and add your real customer quotes and data.
Source
2. Stakeholder Update Email
The weekly status email is deceptively hard to get right. Most PMs default to listing what they did, but this prompt flips the structure: lead with what the reader cares about, use traffic-light status, and close with three bullets covering what is done, what is next, and what is needed. The 200-word constraint keeps you from burying the ask.
Write a stakeholder update email for [PROJECT/FEATURE NAME] to [AUDIENCE: executive / cross-functional team / board].
Context:
- What we have accomplished since last update: [LIST 3-5 ITEMS]
- Key metrics or milestones hit: [ANY DATA]
- What is coming next: [UPCOMING WORK AND DEADLINES]
- Blockers or decisions needed: [LIST OR 'NONE']
- Risks: [ANY EMERGING RISKS]
Requirements:
- Open with the audience's top priority, lead with what they care about, not what you have been doing
- Under 200 words, executives do not read novels
- Use a traffic light status (Green / Yellow / Red) with one-line justification
- If there is a blocker, frame it as 'We need your input on X by [DATE] to keep shipping on [DATE]', specific ask, specific deadline
- End with exactly 3 bullet points: what is done, what is next, what is needed from them
- Subject line: specific and gives them a reason to open it, not 'Weekly Update' or 'Quick Question'
How to use it: Fill in the five context fields (accomplishments, metrics, upcoming work, blockers, risks). The output is ready to paste into your email client.
Source
3. Feature Prioritisation Framework
RICE scoring sounds simple until you try to estimate reach and confidence for twelve features at once. This prompt generates the estimates, calculates scores, and categorizes results into quick wins, big bets, and traps. The traps category is the most valuable part because it surfaces popular requests that score poorly, giving you cover when you say no.
Help me prioritise these features for [PRODUCT NAME] using RICE scoring.
Features to evaluate:
[LIST FEATURES WITH BRIEF DESCRIPTIONS]
For each feature, I need you to:
1. Estimate Reach (how many users will this affect per quarter?)
2. Estimate Impact (how much will this move the needle? 3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal)
3. Assess Confidence (how sure are we about reach and impact? 100% = high, 80% = medium, 50% = low)
4. Estimate Effort (person-months of work)
5. Calculate RICE score: (Reach x Impact x Confidence) / Effort
Then provide:
- Ranked list by RICE score
- Flag which estimates are weakest and need validation (mark as [LOW CONFIDENCE])
- Identify quick wins (high score, low effort)
- Identify big bets (high potential but uncertain)
- Identify traps (popular requests that score poorly, explain why)
- Recommend which 3 features to build next and which 3 to cut, with reasoning
Be honest about uncertainty. A wrong prioritisation is worse than admitting you do not know.
How to use it: List your candidate features with one-line descriptions. The output flags low-confidence estimates, so use those flags to decide where you need real data before committing.
Source
Finding these useful? The full guide has 17 of them, plus tool reviews and a 30-day plan. Get it for $39.
4. Meeting Notes to Action Items
You leave a meeting with a page of scattered notes and three Slack messages asking what was decided. This prompt converts raw notes into five clean sections: summary, decisions with rationale, action items with owners and deadlines, open questions, and a parking lot. Action items start with verbs and include enough context for the owner to act without follow-up questions.
Here are my raw meeting notes from [MEETING TYPE: standup / sprint planning / stakeholder review / user interview / strategy session]:
[PASTE RAW NOTES, messy is fine]
Convert these into:
1. Clean summary (5 sentences max, what was discussed and what was decided)
2. Decisions made (list each decision with who made it and the rationale)
3. Action items (each starts with a verb, is specific enough for someone else to complete without questions, includes an owner and deadline)
4. Open questions (anything unresolved that needs a follow-up)
5. Parking lot (topics raised but deferred, who owns following up)
Group related action items together. Put time-sensitive items first. If no deadline was mentioned, suggest one based on the context.
Format for easy copy-paste into Slack or Notion.
How to use it: Paste your messy notes right after the meeting and specify the meeting type (standup, sprint planning, stakeholder review). Copy the structured output into Slack or Notion as your recap.
Source
5. Edge Case Identification
Specs ship with blind spots because you wrote them knowing the happy path too well. This prompt runs adversarial QA against your feature description across eight categories: permissions, data quality, scale, failure modes, integration conflicts, internationalisation, and backward compatibility. Each edge case gets an impact rating and a call on whether it blocks launch or can follow later.
I am finalising the spec for [FEATURE NAME]. Here is what it does:
[PASTE FEATURE DESCRIPTION OR PRD]
Identify potential edge cases and failure modes across these categories:
1. Permissions and access: What happens when different user roles interact with this? What about users with partial permissions?
2. Data quality: What if input data is missing, malformed, duplicated, or extremely large?
3. Unusual states: First-time user, empty states, maximum capacity, concurrent users editing the same thing
4. Scale: What breaks at 10x current usage? 100x?
5. Failure modes: Network timeout, third-party API down, partial save, interrupted flow
6. Integration conflicts: How does this interact with existing features? Could it break anything?
7. Internationalisation: Time zones, languages, currencies, date formats
8. Backward compatibility: What happens for existing users or existing data?
For each edge case:
- Scenario description (one sentence)
- Impact if unhandled: Critical / High / Medium / Low
- Recommended handling
- Whether it is a launch blocker or a fast-follow
Be adversarial, think like the most creative QA engineer who is trying to break this.
How to use it: Paste your draft PRD or feature spec into the prompt. Add the launch-blocker items directly to your spec before your engineering review.
Source
6. Customer Feedback Analysis
Dumping 50 NPS responses into a chat window and asking "what are customers saying?" gets you a vague summary. This prompt structures the analysis into theme clusters with frequency counts and severity ratings, ranked feature requests, churn signals, and competitive mentions. The [LOW CONFIDENCE] flags on small sample sizes keep you from over-indexing on one loud customer.
Analyse the following customer feedback data:
[PASTE FEEDBACK, support tickets, NPS responses, app store reviews, sales call notes, or survey responses]
Provide:
1. Theme clustering: Group all feedback into 5-8 themes. For each theme:
- Theme name
- Number of mentions
- Representative quotes (top 3)
- Severity: Critical / High / Medium / Low
- Trend: Increasing / Stable / Decreasing
2. Feature requests: Ranked list of requested features with frequency count
3. Pain points: The top 5 frustrations customers are experiencing, ranked by frequency and severity
4. Competitive mentions: Any references to competitors, what are customers comparing us to and why?
5. Churn signals: Any feedback that suggests a customer is at risk of leaving
6. Sentiment distribution: Positive / Neutral / Negative percentage breakdown
7. Recommended actions: The top 3 things we should do based on this data, with expected impact
Flag any themes where the sample size is too small to draw conclusions as [LOW CONFIDENCE].
How to use it: Paste raw feedback from any source: support tickets, NPS comments, app store reviews, or survey responses. The output works as a slide for your next product review or as a brief for your design team.
Source