1. Generate a Complete PRD from a Feature Brief
A PRD that engineering and design can actually ship from needs problem context, measurable goals, user stories, and clear scope. This prompt produces the full document from a single feature description — so you spend your time refining the thinking, not formatting the doc.
Copy-paste prompt
You are a senior product manager. Write a complete Product Requirements Document for the following feature: [FEATURE DESCRIPTION]. Include: 1) Problem statement and user pain 2) Goals and success metrics (with 3 specific measurable KPIs) 3) User stories in 'As a [user], I want [goal] so that [reason]' format (minimum 5) 4) Functional requirements (numbered list) 5) Out-of-scope items 6) Open questions 7) Dependencies and risks Use clear, concise language. Assume engineering and design will read this.
Replace [FEATURE DESCRIPTION] with a 2–3 sentence summary of the feature and the problem it solves. The output gives you a structured first draft your team can comment on immediately — no blank doc, no bikeshedding on format.
2. Write a Quarterly Roadmap Narrative in 3 Minutes
Roadmap all-hands slides are one thing. But a tight written narrative — one you can read aloud, send to the company, or paste into a board update — takes real time to draft well. This prompt builds that narrative from your initiative list.
Copy-paste prompt
You are a head of product presenting to the company. Write a quarterly roadmap narrative for Q[QUARTER] [YEAR] based on these initiatives: [LIST YOUR INITIATIVES]. Structure it as: 1) Theme for the quarter in one sentence 2) Three pillars (each with 1 headline initiative and 2-sentence rationale) 3) What we're NOT doing this quarter and why (2-3 items) 4) How this connects to annual strategy Write it to be read aloud in 3 minutes. Confident, clear, no jargon.
The “what we’re NOT doing” section is the most underrated part of any roadmap presentation — it shows strategic prioritization, not just a list of things. This prompt forces you to include it every time.
3. Write a Stakeholder Update Email That Gets Read
Most stakeholder updates are too long, too vague, or both. This prompt produces a tight under-200-word email with a clear status signal, progress bullets, risk flags, and a single ask — the format executives actually respond to.
Copy-paste prompt
Write a stakeholder update email for the following product initiative: [PROJECT NAME AND CONTEXT]. The email should: 1) Open with the status in one word (On Track / At Risk / Blocked) 2) Summarize what shipped or progressed this week (2-3 bullets) 3) Flag any risks or blockers with proposed mitigations 4) State the next milestone and its date 5) Include one clear ask or decision needed from the reader (if any) Keep it under 200 words. No fluff, no padding.
The one-word status opener is the key — it lets a busy executive scan their inbox and know immediately if they need to act. Everything else provides the context if they want to dig in.
Nexus Vault
Need more than the free prompts?
Get 200 business prompts, instant download, and no subscription.
4. Build a User Story Map from a Single Goal
Story mapping sessions are a staple of product discovery — but prepping one from scratch takes time. This prompt generates a complete story map with backbone activities, user stories, and release slices, formatted as a table your team can work from immediately.
Copy-paste prompt
You are a product manager running a story mapping session. Given this user goal: [USER GOAL], create a user story map with: 1) The backbone — 5-8 sequential activities the user does to achieve the goal 2) Under each activity, 3-4 user stories ('As a user, I want…') 3) A recommended MVP slice that delivers the core value with minimum stories 4) A v2 slice for the next iteration Format as a table: Activity | User Stories | Release slice.
Use this as a starting point for your actual story mapping workshop, not a replacement for it. Having a draft on the board before the session starts saves 30 minutes of blank-staring and gets the team straight into debate and refinement.
5. Run a Post-Launch Retrospective That’s Actually Useful
Most retros produce vague takeaways that nobody acts on. This prompt structures the retrospective around specific metrics, root causes, and concrete actions — so it becomes an asset you can reference for the next launch, not a document that goes into a folder and dies.
Copy-paste prompt
Run a post-launch retrospective for the following product launch: [LAUNCH NAME, DATE, BRIEF DESCRIPTION]. Structure it as: 1) What we shipped (bullet list of features vs. planned scope) 2) Key metrics at launch vs. targets (make a table) 3) What went well (3-5 items with root cause) 4) What to improve next time (3-5 items with specific action) 5) Surprises — things we didn't anticipate 6) One-sentence overall verdict Be honest and specific. Avoid vague feedback.
The “surprises” section catches the things that fell outside the planned vs. actual analysis. Those surprises are often the most valuable learning from any launch — and the easiest to forget three months later.