Lesson 1

Prompts Library

1. User Research and Discovery

Discovery is where most products win or lose, yet it is also where thinking tends to be least structured. These prompts help you synthesize raw inputs into usable insight before you have written a single line of spec.

I conducted [NUMBER] user interviews about [TOPIC/PROBLEM AREA].

Here are my raw notes:

[PASTE NOTES]

Synthesize these into:

1. The top 3 distinct user needs, each stated as a job to be done

(When I... I want to... So I can...)

2. The most common pain points, ranked by frequency

3. Surprising findings that challenge our assumptions

4. Quotes that best represent each need

Keep each section tight. Flag where the data is thin or contradictory.

Here is my current problem statement:

[YOUR PROBLEM STATEMENT]

Evaluate it against these criteria:

- Is it specific enough to guide solution design?

- Does it describe the user's experience, not our solution?

- Is it falsifiable — could we know if we solved it?

- Does it contain hidden assumptions?

Then rewrite it to address any gaps. Give me two versions:

one concise (one sentence), one expanded (three sentences).

We are building [PRODUCT/FEATURE DESCRIPTION] for [TARGET USER].

Our hypothesis is that [CORE HYPOTHESIS].

List the assumptions embedded in this hypothesis, organized by:

1. Desirability assumptions (do users want this?)

2. Feasibility assumptions (can we build it?)

3. Viability assumptions (should we build it?)

For each assumption, rate the risk (high/medium/low) and suggest

the fastest way to test it before committing to a build.

2. Product Specification

A PRD is only as good as the thinking behind it. These prompts help you move from a rough idea to a well-reasoned spec and catch the holes in your logic before engineering does.

Feature name: [NAME]

Problem it solves: [PROBLEM]

Target user: [USER SEGMENT]

Success looks like: [SUCCESS METRIC]

Key constraints: [TECHNICAL, BUSINESS, OR TIMELINE CONSTRAINTS]

Write a one-page feature brief that includes:

1. Problem context (why this, why now)

2. Proposed solution in plain language

3. What is explicitly out of scope

4. Open questions that must be answered before spec is final

5. Risks and mitigations

Write for an audience of senior engineers and a VP of Product.

Feature: [FEATURE DESCRIPTION]

Primary user: [USER TYPE]

Core workflow: [WHAT THE USER IS TRYING TO ACCOMPLISH]

Write a complete set of user stories covering:

- The happy path (primary use case)

- Edge cases and error states

- Admin or internal team needs if applicable

Format each story as:

As a [user], I want to [action] so that [outcome].

Include acceptance criteria for each story in Given/When/Then format.

Flag any stories where the acceptance criteria will be hard to test.

Here is a product spec I have written:

[PASTE SPEC]

Review it from three perspectives and give specific, actionable feedback:

1. As a senior engineer: Where is the spec ambiguous, technically

naive, or missing information needed to estimate or build?

2. As a QA lead: Where are the gaps in acceptance criteria and

which behaviors are undefined?

3. As a skeptical VP: Where is the reasoning weak, the scope

too large, or the success metrics vague?

Be direct. I would rather hear this now than in a sprint review.

3. Prioritization and Roadmap Thinking

Prioritization decisions are rarely pure logic. They are negotiations between data, strategy, stakeholder pressure, and judgment. These prompts bring more structure to that process.

I need to prioritize the following initiatives:

[LIST YOUR INITIATIVES]

For each initiative, help me think through RICE scoring:

- Reach: How many users affected per quarter?

- Impact: Effect on the key metric? (scale: 0.25, 0.5, 1, 2, 3)

- Confidence: How certain are we? (%)

- Effort: How many person-weeks?

Ask me clarifying questions where inputs are unclear. Then produce

a ranked RICE table and flag where two initiatives are close enough

that the ranking could flip with better data.

We are facing a decision between:

Option A: [DESCRIPTION]

Option B: [DESCRIPTION]

Context: [RELEVANT CONSTRAINTS, COMPANY STAGE, TEAM SIZE]

What we are optimizing for: [PRIMARY OBJECTIVE]

Help me think through this trade-off by:

1. Steelmanning both options (best case for each)

2. Identifying the key assumptions each option depends on

3. Describing what a wrong call looks like for each option

4. Recommending a decision framework for making the final call

Do not give me a recommendation yet. I want to think it through first.

Here is our product roadmap for the next [TIMEFRAME]:

[PASTE ROADMAP ITEMS OR THEMES]

Our company strategy is: [STRATEGY SUMMARY]

Our primary metric this period is: [METRIC]

Write a roadmap narrative that:

1. Connects each theme to the strategy and metric

2. Explains the sequencing logic (why this order)

3. Acknowledges what we are deliberately not doing and why

4. Frames uncertainty honestly (what might shift this plan)

Audience: all-hands presentation. Tone: confident but not over-promising.

4. Stakeholder Communication

Product managers spend a significant portion of their week communicating not just informing, but persuading, aligning, and building trust. These prompts help you write communication that actually moves people.

Write a stakeholder update for [PROJECT OR PRODUCT AREA].

Period: [DATE RANGE]

Status: [ON TRACK / AT RISK / BLOCKED]

Key progress this week: [WHAT MOVED FORWARD]

Decisions made: [ANY CALLS LOCKED IN]

Risks or blockers: [WHAT COULD DERAIL PROGRESS]

What I need from stakeholders: [SPECIFIC ASK, IF ANY]

Next milestone: [WHAT WE ARE WORKING TOWARD]

Audience: [EXEC TEAM / CROSS-FUNCTIONAL LEADS]

Length: Three short paragraphs. Lead with status, end with the ask.

We have made a difficult decision: [DECISION]

Who is affected: [AFFECTED PARTIES]

Why we made this call: [HONEST RATIONALE]

What we considered before deciding: [ALTERNATIVES REVIEWED]

What we are doing to support those affected: [MITIGATION OR SUPPORT]

Write a message communicating this decision that:

1. States the decision clearly upfront — no burying the lead

2. Shows we thought carefully before deciding

3. Acknowledges the impact honestly without being dramatic

4. Explains what happens next and invites questions

Avoid corporate softening language. People respect honesty more than comfort.

5. Metrics and Experimentation

Metrics are only useful if they are measuring the right thing. Experiments are only trustworthy if they are designed well. These prompts help you think more rigorously about both.

Feature: [FEATURE NAME AND DESCRIPTION]

The user behavior we are trying to change: [BEHAVIOR]

Our north star metric: [METRIC]

Define a metrics framework for this feature including:

1. Primary success metric (what moves if the feature is working)

2. Secondary metrics (supporting signals)

3. Guardrail metrics (what we must not harm)

4. Leading indicators (early signals before the primary metric moves)

5. How we would distinguish a feature success from external noise

Flag any metrics that are easy to measure but likely to mislead.

We are designing an experiment to test: [HYPOTHESIS]

Current design:

- What we are changing: [TREATMENT]

- Control group: [CONTROL]

- Primary metric: [METRIC]

- Sample size plan: [SIZE OR DURATION]

- Success threshold: [WHAT COUNTS AS A WIN]

Review this design and flag:

1. Threats to internal validity (are we testing what we think we are?)

2. Metric choice problems (is this the right thing to measure?)

3. Sample size or duration issues

4. Ethical or experience quality concerns

Suggest the minimum changes needed to make this a trustworthy test.

6. Competitive Intelligence

Understanding your competitive landscape is not a one-time research exercise. It is an ongoing practice that sharpens your positioning and surfaces threats before they become problems.

Competitor: [COMPETITOR NAME]

Our product: [BRIEF DESCRIPTION OF YOUR PRODUCT]

What we know so far: [EXISTING KNOWLEDGE]

Analyze this competitor across:

1. Their apparent product strategy (who are they building for?)

2. Where they are stronger than us today

3. Where we are stronger than them today

4. What their recent moves (launches, pricing changes, hiring)

suggest about where they are heading

5. The scenario in which they become a serious threat to us

Close with the one thing we should be watching most closely.

Our product positioning is: [POSITIONING STATEMENT]

Our primary differentiator: [WHAT WE CLAIM SETS US APART]

Key competitors: [LIST]

Pressure test this positioning:

1. Which competitor could most easily replicate our differentiator

within 12 months?

2. Where are we winning on features rather than on a durable moat?

3. Where does our positioning ring hollow to a skeptical buyer?

4. What would we need to change to make our differentiation

genuinely defensible?

Be direct. Flattering analysis is not useful here.

Using These Templates Well

A template is not a form to fill out it is a thinking scaffold. The brackets show you what context matters, but the quality of what you put inside those brackets determines the quality of what comes out.

Three practices make these templates significantly more effective.

Iterate on the output, not just the input. When a prompt returns something almost right, do not start over. Tell Claude what is off: "The tone is too formal" or "The risk section is too vague go deeper." Most great outputs are the product of two or three turns, not one

Add your company context. The more Claude knows about your specific product, users, and strategy, the less generic its output will be. Keep a short context block you paste at the start of any complex prompt: who your users are, what your product does, and what you are optimizing for this quarter.

Save what works. When a prompt returns something you would actually send or ship, save it. That is your library entry. Over a quarter, you will have a collection that reflects how your team actually thinks, not how a textbook says product managers should think.

Prompt Libraries for Product Managers: Build Reusable AI Workflows