Each prompt follows the role-context-task-format-constraints anatomy so you get a usable draft fast. Fill the brackets with your real specifics; thin context is what makes a model invent.
**1. One-page PRD from a problem statement.**
```
You are a senior PM writing a one-page PRD for engineering and design.
Context:
- Problem: [2-3 sentences]
- Evidence we have: [paste real data, tickets, or quotes]
- Constraints: [platform, timeline, dependencies]
- Success metric: [the one metric this should move]
Sections: Problem, Goal, Non-goals, Requirements (numbered, testable), Open questions.
Rules: use only the evidence above; if a number is missing, write [TBD: needs data]; under 400 words.
```
**2. Adversarial PRD review.**
```
You are a skeptical staff engineer reviewing this PRD. List the top 5 risks, ambiguous requirements, or hidden dependencies. For each, ask the one clarifying question that resolves it. Be specific; don't pad.
[paste PRD]
```
**3. Interview synthesis with verbatim quotes.**
```
You are a UX researcher synthesizing raw interview notes (separated by '---').
1. Identify 4-6 recurring themes.
2. For each: one-line summary, count of participants who raised it, and 1-2 VERBATIM supporting quotes copied exactly from the notes.
3. Flag single-participant themes as 'single source — low confidence.'
Do NOT invent quotes or participants. If no verbatim quote fits a theme, write 'no direct quote.'
---
[paste notes]
```
**4. Requirements → clean tickets.**
```
You are a PM writing engineering tickets in this format:
Title | User story (As a... I want... so that...) | Acceptance criteria (testable, bulleted) | Out of scope
From the feature description below, produce 1-3 tickets.
Rules: acceptance criteria derived ONLY from the description; if ambiguous, add to a 'Questions for PM' list instead of guessing; keep each ticket independently shippable.
Description:
[paste]
```
**5. Roadmap update, three audiences.**
```
Here is our roadmap status (facts — do not change them):
[paste initiatives, status, dates]
Produce THREE versions:
1. EXEC (<120 words): outcomes, the one risk worth attention, what you need from them.
2. ENGINEERING: scope, sequence, dependencies, open technical questions.
3. CUSTOMER-FACING: lead with the benefit, no internal dates, no hedged language.
Do not introduce any initiative, date, or metric not in the source.
```
**6. Metrics dump → narrative.**
```
Turn the metrics below into a 150-word plain-language summary for a non-technical stakeholder: what changed, the likely 'so what,' and the one open question.
Use only the numbers provided. Do not infer causation you can't support. Label anything speculative as 'hypothesis.'
Metrics:
[paste]
```
**7. Competitive teardown structure.**
```
From the competitor materials I paste below, build a feature-comparison table across these dimensions: [list]. Note where information is missing as 'unknown' rather than guessing. Then list 3 differentiation angles for our product.
[paste sources]
```
**8. Experiment hypothesis + design.**
```
We want to improve [metric] on [surface]. Draft 3 testable hypotheses in the form 'If we [change], then [metric] will [direction] because [reason].'
For the strongest one, outline a simple A/B test: variant, primary metric, guardrail metric, and the obvious confounder to watch. Flag assumptions explicitly.
```
The recurring guardrails — '[TBD]', 'verbatim', 'Questions for PM', 'do not introduce', 'label as hypothesis' — are what keep PM artifacts honest. To save any of these as reusable parameterized templates, use the ChatGPT Prompt Generator; for the stakeholder readout, drop a finished doc into the Presentation Outline Generator.