Skip to content
AI Work
Commons
Try an example
Early preview Nothing here is released yet. Pages marked Garden are drafts that no person has reviewed. How review works

Turn discovery notes into questions you can test

Garden · not yet reviewed Time: 30 minutes Good for: programme coordinator, team lead, operations staff

You'll end up with: A one-page discovery brief separating observations, hypotheses, counterexamples and the next research decision.

Tools: Any general AI chat assistant. Use the synthetic notes or information you are authorized to share. No connected apps or paid feature is required.

Garden starter · AI-proposed · Synthetic example · Not independently reviewed or model-tested.

Why this matters

A few notes can suggest a useful question. They rarely settle how common a problem is or which feature will solve it. Use AI to make the evidence easier to inspect while you choose what to learn next.

Smallest useful build

One page with five sections: observations, hypotheses, counterexample, unknowns and a proposed next study. Allow 30 minutes. You decide what counts as evidence and what action it warrants. AI can group notes, suggest competing explanations and help phrase questions.

All observations below are invented. There were no actual interviews, participants or research sessions. Generated role-play can help you rehearse questions; it cannot validate a user need.

Sample inputs

These notes are also in the synthetic fixture.

Question: What should we learn before choosing a prototype for community tool requests?
d1 Synthetic observation A: after submitting a request, the participant reopened the form because they could not find confirmation.
d2 Synthetic observation B: the participant copied the pickup deadline into a calendar because they expected to forget it.
d3 Synthetic observation C: the participant found confirmation immediately and said the process was sufficient.
d4 Study design: three invented active-user walkthroughs. Not representative; no evidence about nonusers.
d5 Synthetic inbox tally: three of eight sample-week messages asked whether a request was received. Distinct people were not counted.

Steps

  1. Write the learning question. Avoid starting with “How do we build an app?” Write what you need to understand before deciding on a feature.

    I need to decide what to learn before choosing a prototype. Here is my question: [question]. Help me make it specific without assuming a solution. Ask one clarifying question if needed.

  2. Separate what happened from what it might mean.

    Group d1–d5 into observations, hypotheses and unanswered questions. Cite source IDs for observations. Label interpretations as hypotheses. Keep counterexamples and sampling limits. Do not invent interviews, quotes, demographics, prevalence or requests for features.

  3. Look for a competing explanation.

    For the strongest hypothesis, suggest one alternative explanation and one neutral question that could distinguish them. Do not answer as a pretend participant. Explain which missing evidence a person would need to collect.

  4. Choose one next study. Keep it small enough that the answer could change your plan.

    Draft a one-page brief with Observations, Hypotheses, Counterexample, Unknowns and Proposed next study. Use only the notes. I will choose the next study and recruit people separately. Include what finding would count against the main hypothesis.

Authored example to inspect

This is an original reference brief, not a model run or a research finding:

  • Observations: A could not find confirmation; C found it easily. [d1, d3] B used a calendar to remember a deadline. [d2] Three of eight messages concerned receipt of a request, but distinct senders were not counted. [d5]
  • Hypothesis: Making confirmation easier to notice may help some people. [d1, d5] An alternative is that people notice confirmation but do not trust that it means the request was recorded. The alternative is a proposed explanation, not an observed fact.
  • Counterexample: C found confirmation immediately and did not need a change. [d3]
  • Unknowns: We do not know prevalence, whether the same people sent repeated messages, or how nonusers experience the process. [d4, d5]
  • Proposed next study: Observe a small, deliberately varied set of people completing the current request flow, with consent and appropriate data handling. Ask, “What would you do next?” and “How would you tell whether the request reached us?” Keep the prompts neutral. If people consistently find and understand the confirmation but still ask for help, the visibility hypothesis needs revision. Decide recruitment and the study’s scope before running it.

A separate deadline question remains open. The calendar workaround does not prove that reminders are wanted or that a new app is needed.

Check it

  • Trace every observation to an active note.
  • Keep the person who found the process easy in the brief.
  • Do not turn three messages into three people, or three examples into “most users.”
  • Keep alternative explanations visibly hypothetical.
  • Make sure the proposed study could produce an answer you do not want to hear.
  • Stop before collecting or uploading real personal information without the necessary consent and permissions.

Break it

For the next case, use d2 and d4, remove d1, d3 and d5, and add:

d6 Changed prototype: a visible confirmation receipt was added. In a new walkthrough A found it without help.
d7 New synthetic observation: A could not find the pickup deadline on that receipt.
d8 Only this one invented active-user walkthrough has been recorded for the new version.

The revised brief should investigate the deadline on the receipt. It must not claim that the current prototype lacks confirmation, reuse the old inbox tally as current evidence or declare the issue solved for everyone.

Reflect

  • Which sentence in the first brief was your interpretation rather than an observation?
  • What did the counterexample change?
  • Could you name evidence that would make you abandon your preferred feature?
  • Did the assistant make gaps easier to see, or only make the brief look finished?

Next iteration

Use the changed case before trying another question. Keep the question, source IDs, product version and an explicit “what changed” note. Any real trial needs people, consent and context; it cannot be replaced with generated interviews.

Research-workflow inspiration: How I AI at ChatPRD. The source concerns market research; this discovery exercise, notes and prompts are original.

Connections

Skills it uses

Concepts it practises

Competencies

How we know

The claim
Research workflows can connect source-backed findings to decision questions while keeping uncertainty visible.
The evidence
The linked How I AI guide is a practitioner example of market research and synthesis. This Commons starter instead uses original invented user-observation notes.
The limits
Market research is not user discovery, and the source does not validate this starter. AI-generated personas are not participants or evidence. No model execution or independent human review has been recorded.

Plain Markdown for agents: /projects/prj-discovery-brief-from-notes.md