| PromptSharp Product | SAMPLE ISSUEPRO EDITION |
Copy-paste AI prompts for discovery, PRDs, prioritization, and experiment readouts. Wednesday, July 8, 2026 · For Product Managers · Product Leaders · Product Ops & Analysts | SAMPLE ISSUE — a representative edition of PromptSharp Product prepared for launch. This is what every issue looks like. Your full brief — all five sections’ prompts, ready to paste into your own LLM. Plus the searchable archive of every prompt we’ve shipped. One ready-to-run prompt a day for the exact work PMs do — interview synthesis, PRD drafting, backlog stack-ranking, decision memos, and experiment readouts. Paste into your own LLM. No news, no fluff. | Continuous Discovery Discovery & Research For: PMs running user interviews and synthesizing feedback 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. Why it works: Translating feature asks back to needs is what separates discovery from order-taking. Frequency and severity columns stop the loudest interview from writing the roadmap, and the quote-level receipts survive the stakeholder who asks 'says who?' | | Write the Contract PRDs & Specs For: PMs drafting specs engineering will actually build from 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. Why it works: PRDs fail at the edges, not the happy path. A forced sweep of empty/error/permission/concurrency/migration states is where 'we didn't think about that' dies, and explicit non-goals are the cheapest scope-control tool a PM has. | | Sequence With Receipts Prioritization & Roadmaps For: PMs force-ranking backlogs and defending roadmaps 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, impact, confidence, effort, and score for each item — with every input labeled measured / estimated / guess and its source named.
B) SENSITIVITY — which 3 rankings flip if the guess-level inputs move by 2x in either direction.
C) KILL LIST — the bottom items, each with a one-line kill rationale and the specific evidence that would revive it.
D) SEQUENCE NOTE — dependencies between the top items and a capacity sanity-check against my stated team size.
Inputs: [PASTE BACKLOG: ITEM, PROBLEM IT SOLVES, EVIDENCE, EFFORT ESTIMATE] · [TEAM CAPACITY] · [CURRENT STRATEGY PRIORITIES]
Rules: Do not invent reach or impact numbers — inputs without a source default to "guess" and cap that item's confidence at 50%. Verify effort with engineering leads before publishing the rank. Strip customer-identifying data from the table. Why it works: RICE without input provenance is false precision. Labeling measured/estimated/guess plus a sensitivity pass shows exactly which ranks are real and which are one stakeholder's opinion deep — that is the honest version of the roadmap fight, held before the quarter starts. | | Manage the Room Stakeholder Comms For: PMs driving cross-functional decisions and updates 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 sentences max), the decision needed (one sentence, with a deadline and an explicit default-if-no-decision), an options table (option, cost, risk, reversibility, recommendation), and what we are explicitly NOT deciding today.
B) STAKEHOLDER MAP — for each stakeholder I name: what they care about, their likely objection, and the exact line in the memo that addresses it.
C) ESCALATION — the path if no decision lands by the deadline, stated without drama.
Inputs: [DECISION + CONTEXT] · [OPTIONS CONSIDERED + SUPPORTING DATA] · [STAKEHOLDERS: NAME/ROLE + KNOWN POSITIONS] · [DEADLINE]
Rules: Do not invent stakeholder positions — where I gave none, write "position unknown: ask before circulating". Verify every data point cited in the options table against its source. Keep confidential personnel and customer data out of the memo. Why it works: Default-if-no-decision is the forcing function — silence becomes a choice with a stated cost. Mapping each stakeholder's objection to the exact line that answers it turns the review from re-litigation into ratification, and 'not deciding today' kills scope sprawl in the room. | | Evidence Over Opinions Metrics & Experiments For: PMs and analysts turning test results into ship decisions 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 registered, primary-metric result with its confidence interval, guardrail metrics, and actual duration/sample vs plan.
B) VALIDITY CHECKS — a table: check (sample-ratio mismatch, novelty effect, seasonality overlap, peeking/early stopping, segment reversal), status (pass / fail / cannot assess), and the evidence.
C) DECISION — ship / iterate / kill, with confidence labeled high/med/low and the reasoning in 3 sentences. If iterate: the single next test.
Inputs: [EXPERIMENT DESIGN + REGISTERED SUCCESS CRITERIA] · [PASTE RESULTS: METRICS, SAMPLE SIZES, INTERVALS OR P-VALUES] · [KEY SEGMENTS]
Rules: Do not invent statistics or infer significance the data does not support — if the model cannot compute it from my paste, say "insufficient data"; that is a valid readout result. Verify metric definitions with the analytics team before publishing. Keep user-level and confidential data out of the readout. Why it works: Most experiment 'wins' die under three questions: was the sample ratio right, did you peek, does it hold by segment. Building the validity table into the readout means you ask them before your CPO does — and labeled confidence keeps a marginal result from shipping as a sure thing. | | | | Prompt of the Week (Pro) This week's bonus: a churned-user postmortem prompt that turns exit-survey verbatims and usage timelines into a ranked churn-driver table — with a strict quote-or-it-didn't-happen evidence rule. | Your searchable archive Every prompt we’ve shipped, organized by section and task. Open archive → | Prompts reflect real product-management workflows. We make no roadmap or metric guarantees — you own the output and must check every number against your own analytics. Never paste user-identifying data or confidential roadmaps into any LLM without approval. PromptSharp Product is part of the PromptSharp family — an educational product. Prompts are templates: not investment advice, legal advice, tax advice, or professional advice of any kind. You are responsible for verifying every output. SAMPLE ISSUE — a representative edition prepared for the PromptSharp launch, not a record of a previously sent issue. Subscribe · Prompt archive · Go Pro · Unsubscribe |
|