Skip to content
PMcademy
Discovery

Discovery prompts

Research and talking to users, with a model doing the first pass.

The stage

The stage where a vague sense that something's wrong turns into evidence you'd defend in a room.

  1. 01

    Extract structured signal from raw feedback

    There's a pile of reviews, tickets, or open-text survey responses and it needs sorting before you can say anything defensible about it.

    The prompt
    You are a research analyst helping a product manager turn raw customer feedback into structured data. You will not summarise, interpret, or paraphrase. You will extract.

For each distinct piece of feedback in the text below, output one row with these exact fields:
- quote: copied character for character, including typos and grammar
- source: where it came from, if stated
- problem_label: pick from this fixed list only: [list your 6 to 10 labels here], or "other" if genuinely none fit
- user_type_guess: new, existing, or churned, with your reasoning in one clause
- severity_1_to_5: how much this blocks the user from getting value, not how angry the tone is

If a single review raises two distinct problems, split it into two rows. Return the result as a table, not prose.

Feedback:
[paste your reviews, tickets, or survey responses here]
    Where it lets you down

    It will summarise when you asked it to extract, folding a specific complaint into a tidy paraphrase, and the exact quote, the detail that would have told you which bug this actually is, is gone. Check the first ten rows against the source text before trusting the rest.

  2. 02

    Stress test a cluster before you report it

    A first extraction pass is done and one label holds far more rows than the others, which usually means two different problems got merged.

    The prompt
    I ran an extraction over customer feedback and got the label below with far more rows attached than any other. I'm going to paste a sample of the actual quotes. Your job is to tell me if this is really one problem or two or more problems that share vocabulary.

For each quote, note what specifically is broken, described as a mechanism (what fails, not how the user feels about it). Then group the quotes into sub-clusters based on the actual mechanism, not the words used to describe it. Tell me if any sub-cluster looks large enough to be its own problem, and name what would separate it from the rest.

Label: [your label]
Quotes:
[paste 15 to 20 quotes from that cluster]
    Where it lets you down

    It tends to agree the cluster is coherent, because the quotes really do share vocabulary, which is exactly the surface signal that caused the merge in the first place. Push it to look at mechanism, not wording, or it will just confirm your first pass.

  3. 03

    Turn a support inbox into a jobs to be done statement

    There are weeks of support tickets about one area and the underlying need has to come out of them, not just the list of complaints.

    The prompt
    You are helping me write a jobs to be done statement from support tickets. A JTBD statement has this shape: "When [situation], I want to [motivation], so I can [expected outcome]." It describes the underlying need, not a feature.

Read the tickets below. Identify the situation that keeps recurring (not the bug, the moment in the user's life when they reach for this), the motivation underneath it, and the outcome they're actually trying to reach. Draft three candidate JTBD statements ranked by how many tickets they explain. For each, name a ticket that fits well and one that doesn't quite fit, so I can see the edges of the statement.

Tickets:
[paste 20 to 30 support tickets from the same area]
    Where it lets you down

    It writes a JTBD statement shaped like a feature request wearing the JTBD template, for example "I want to link my bank so I can budget," which just restates the feature. Push back until the situation and outcome could be true even if your product didn't exist yet.

  4. 04

    Draft a screener from a research question

    Recruiting for a round of interviews, when it's tempting to screen on who says they're interested rather than who actually did the thing.

    The prompt
    I'm recruiting for user interviews on this research question: [your research question].

Draft a screener survey of 5 to 7 questions that qualifies people based on specific, checkable actions they've taken in the last 30 days, never on stated interest or hypothetical willingness. Each question should have a factual answer I could verify against our product data if I had access to it (a date, a count, a specific action taken).

After the questions, list the answer combinations that would qualify someone, and flag any question in your draft that is actually asking about interest or intent rather than a past action, so I can rewrite it.
    Where it lets you down

    It drifts into intent-based screening despite the instruction, phrasing a question like "how likely are you to use budgeting features" because that's the default shape of a screener in its training data. Read every question and confirm it has a factual, checkable answer, not an opinion.

  5. 05

    Build an interview guide anchored to past behaviour

    A guide is drafted but keeps sliding into asking people what they'd want next instead of what they actually did.

    The prompt
    Help me turn this research question into an interview guide built entirely on past behaviour: [your research question].

Structure it as:
1. An opening question asking about the single most recent specific instance of the behaviour, not "usually."
2. Three to four follow up questions that dig into friction or hesitation at each step of that instance.
3. A closing question about what happened immediately after, to capture the real consequence.

Do not include any question phrased as "would you," "how interested are you," or "what would make you." If you catch yourself about to write one, rewrite it as a question about something that has already happened.
    Where it lets you down

    It defaults to future-facing phrasing anyway, because that's the common shape of interview questions online, and slips one or two "would you" style questions in even after the instruction. Read the final guide line by line and rewrite any question you could answer with an opinion instead of a memory.

  6. 06

    Simulate a skeptical stakeholder before the readout

    Before presenting research findings to the team, to find the holes in the argument while it's still just you and a draft.

    The prompt
    You are a skeptical engineering lead at a 40 person startup. You have seen research readouts before that overclaimed based on a handful of interviews, and you will not accept a claim just because it's stated confidently. You will ask about sample size, about whether the researcher is hearing what they wanted to hear, and about what evidence would have to exist for the opposite conclusion to be true.

I'm going to give you my research findings and how many people I talked to. Ask me the three hardest questions a genuinely skeptical person in the room would ask, one at a time, and wait for my answer before asking the next. Do not soften your questions to be encouraging.

Findings: [paste your summary of what you found and how many people you spoke with]
    Where it lets you down

    Left to run freely it turns encouraging after your first answer, congratulating you instead of pushing further. Tell it explicitly not to concede until your answer addresses the specific concern, and to ask all three questions regardless of how good the first answer sounds.