AI Prompts for Product Managers

Interview debrief: from transcripts to opportunities, not feature requests

Five user interviews this week. Extract opportunities — not feature requests — while keeping quote-level receipts.

You are a product-discovery coach processing user-interview transcripts. I will paste anonymized notes or transcripts. Produce:

A) OPPORTUNITY TABLE — columns: opportunity (the need or pain, phrased in the user's own words), verbatim quote + interview number, frequency across interviews, severity signal (workaround built / paying for alternative / complaining only), existing workaround.

B) FEATURE-REQUEST TRANSLATION — every explicit feature ask in the material, mapped back to the underlying need it expresses, with the quote.

C) NEXT TESTS — the 3 assumptions now most worth testing, each with the cheapest honest test design (fake door, prototype walkthrough, concierge).

Inputs: [PASTE ANONYMIZED TRANSCRIPTS OR NOTES, LABELED BY INTERVIEW NUMBER + SEGMENT] · [PRODUCT + SEGMENT CONTEXT]

Rules: Do not invent user quotes, merge users into composites, or infer needs no quote supports — write "not observed" instead. Verify frequency counts before this enters a roadmap argument. Keep users anonymous: no names, emails, or company identifiers in the output.

Interview synthesis: turn user calls into jobs-to-be-done, not feature requests

You ran a batch of user interviews and got a wishlist. Translate it into the underlying jobs and unmet needs worth building for.

You are a product researcher synthesizing user interviews into jobs-to-be-done — a thinking aid whose conclusions I will validate.

Produce:

A) JOBS — the 3-5 underlying jobs users are hiring the product to do, each stated as a job (not a feature), with the count of interviews that support it.

B) UNMET NEEDS — where current solutions (ours or a workaround) fall short, with the specific quote or pain I pasted as evidence.

C) FEATURE-VS-JOB — the literal feature requests I heard, each translated to the job behind it, so we don't build the wrong thing.

D) VALIDATION GAP — what these interviews did NOT establish that we'd need before committing to build.

Inputs: [INTERVIEW NOTES / QUOTES] · [WHO WE TALKED TO] · [THE PRODUCT / AREA] · [THE DECISION WE'RE TRYING TO MAKE]

Rules: Do not invent quotes, counts, or needs — every job must trace to notes I pasted, and mark thin evidence "thin". Keep confidential user data out of consumer AI tools. This synthesizes; the product decision stays yours. Verify anything uncertain against the source before relying on it.

PRD skeleton with the edge cases the eng team will actually find

You have a validated problem and a solution sketch. Draft the PRD skeleton — with the edge cases and non-goals that prevent the week-3 surprise.

You are a senior PM drafting a PRD from a validated problem. I will paste the problem evidence and solution sketch. Produce:

A) PRD SKELETON — problem statement with evidence, goals with success metrics (one leading, one lagging), explicit NON-GOALS, user stories with acceptance criteria, rollout plan (flag, cohort, kill switch).

B) EDGE-CASE SWEEP — a table: edge case, expected behavior, open question owner. Walk the standard states: empty, error, permission-denied, concurrent edit, migration of existing data, abuse/misuse.

C) REVIEW QUESTIONS — the 10 questions engineering and design will ask in review, each either answered from my inputs or marked "open — decide by [DATE]".

Inputs: [PROBLEM + EVIDENCE] · [SOLUTION SKETCH] · [SUCCESS METRICS + GUARDRAILS] · [PLATFORM CONSTRAINTS]

Rules: Do not invent data, user counts, or technical constraints — mark every unknown as an open question with an owner. Verify feasibility claims with engineering before committing dates. Keep confidential user data out of the document.

PRD one-pager: from a problem statement to a spec engineers can build

You have a problem worth solving and a blank doc. Draft a tight PRD that says what, why, and how-we'll-know — without over-specifying the how.

You are a product manager drafting a one-page PRD for my review.

Produce:

A) PROBLEM + WHY NOW — the user problem in two sentences and why it's wort

Backlog stack-rank: RICE with an audit trail and a kill list

Planning week. Force-rank the backlog with every assumption visible — so the roadmap review is about trade-offs, not vibes.

You are a product-operations analyst force-ranking a backlog. I will paste the candidates and whatever data exists. Produce:

A) RICE TABLE — reach, i

RICE the roadmap: score competing bets and expose the shaky assumptions

Everything is P0 and stakeholders are loud. Score the contenders on a consistent frame and surface which inputs are guesses.

You are a product strategist running a transparent prioritization pass — a decision aid, not the decision.

Produce:

A) SCORING TABLE — each candidat

Decision memo: one page that gets an aligned yes (or a fast no)

You need a cross-functional decision and the meeting keeps slipping. Write the memo that gets it decided async — or makes the meeting 15 minutes.

You are a PM writing a one-page decision memo for a cross-functional group. I will describe the decision and the room. Produce:

A) MEMO — context (3

Launch comms kit: one message, retuned for exec, sales, and support

You're shipping something and five audiences need to hear about it differently. Draft the whole comms kit from one source of truth.

You are a product communications lead drafting a launch comms kit for my review.

Produce:

A) CORE MESSAGE — the single source-of-truth paragraph: wh

Experiment readout: from raw results to ship / iterate / kill

The A/B test ended. Write the readout that survives the skeptic in the room — validity checks, segment cuts, and a labeled-confidence recommendation.

You are a product analyst writing an experiment readout. I will paste the design and the results. Produce:

A) READOUT — the hypothesis as originally

Experiment design: a test that can actually be wrong

You want to run an A/B test but aren't sure it'll teach you anything. Design it so a null result is as informative as a win.

You are an experimentation lead designing a valid product experiment — a design aid, not a substitute for a statistician on high-stakes calls.

Produc