37+ ChatGPT & Claude prompts for Product Management

**Role:** Senior PM who has shipped 40+ features. You've learned that 10-page specs become wallpaper while one-pagers ship.

**Context:** Feature: [name + 1-sentence purpose]. The user problem (in user's words): [the verbatim complaint or job-to-be-done]. The success metric: [the ONE number we'll measure]. Team capacity: [people-weeks available]. Hard deadline (if any): [date + why].

**Task:** Write the spec.

1. TL;DR (3 sentences): user problem + what we're shipping + how we'll know it worked.
2. User story: "As a [persona], I want [outcome], so that [reason]." Specific. Not "users want X."
3. Scope: what's IN (3-5 bullets), what's OUT (2-3 explicit bullets). Out-of-scope is a feature.
4. Success metric: ONE primary metric + how it's measured + the lift we'd need for the feature to "win."
5. Solution sketch: 3-5 bullets on the approach. Reference designs/Figma if they exist. NOT a feature list — the user journey.
6. Edge cases: 3-5 specific scenarios we need to handle. Include the empty state and the failure case.
7. Risks: 2-3 things that could go sideways + mitigation.

**Constraints:**
- ≤1 page (~500 words)
- ONE success metric — never tie-break later
- Out-of-scope is required, not optional
- Edge cases include empty state + failure case minimum
- No "we'll figure it out in build" placeholders

**Output format:** 7 sections · ≤500 words · ready for 30-min spec review meeting.

ROLE: You are a product designer-PM who writes lean PRDs that align design, engineering, and stakeholders fast.

CONTEXT: Feature: [FEATURE_NAME] for [PRODUCT]. The user problem and evidence: [PROBLEM_AND_EVIDENCE]. Target users: [USERS]. Business objective it serves: [OBJECTIVE]. Known constraints (tech, timeline, legal): [CONSTRAINTS].

TASK: Draft a one-page-style PRD.
1. Write the problem statement and who has it, backed by the evidence — not a solution in disguise.
2. State the goal and the measurable success metrics (and a guardrail metric).
3. Define scope: what is in v1, what is explicitly out, and why.
4. Describe the core user flow in plain steps and the key states/edge cases that must be handled.
5. List functional requirements as testable statements ('The system must...').
6. Capture dependencies, risks, and the top open questions blocking a confident build.
7. Define the rollout approach (flag, phased, full) and how we will learn post-launch.

OUTPUT FORMAT: Sections — TL;DR | Problem & Evidence | Goals & Metrics | Scope (In/Out) | User Flow | Requirements (testable list) | Risks & Dependencies | Open Questions | Rollout. Lead with a 2-sentence TL;DR.

CONSTRAINTS: Problem before solution — do not smuggle the solution into the problem statement. Every requirement must be testable. Make 'out of scope' explicit. Surface open questions rather than papering over them. Keep it lean and skimmable.

Write a Product Requirements Document for [feature/product]. Sections: (1) Problem statement — what user pain does this solve? (2) Goals and non-goals. (3) User stories (in "As a [user], I want to [action] so that [outcome]" format — 5-8 stories). (4) Functional requirements (must have / should have / nice to have). (5) Non-functional requirements (performance, security, accessibility). (6) Technical constraints. (7) Success metrics and OKRs. (8) Open questions. (9) Out of scope. Target: engineering team can start sprint planning from this doc.