--- schema: project/1 layer: garden roles: - programme coordinator - team lead - operations staff tool_access: Any general AI chat assistant. Use the synthetic notes or information you are authorized to share. No connected apps or paid feature is required. practises: - cmp-frame-the-outcome - cmp-describe-the-task - cmp-check-the-result - cmp-use-responsibly concepts: - con-verification - con-hallucination - con-human-in-the-loop - con-privacy-and-data skills: - frame-the-problem - build-brief - prove-it resources: [] origin: kind: ai-proposed by: work-map authoring agent 2026-10-18 rationale: Original synthetic worked starter with explicit human decisions, evidence checks and a changed-input second use. id: prj-discovery-brief-from-notes title: Turn discovery notes into questions you can test outcome: A one-page discovery brief separating observations, hypotheses, counterexamples and the next research decision. time_box: 30 minutes source: url: https://www.chatprd.ai/how-i-ai/workflows/how-to-conduct-rapid-market-research-and-competitive-analysis-using-ai claim: Research workflows can connect source-backed findings to decision questions while keeping uncertainty visible. 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. 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. workflow: version: 0.1.0 activity_ids: - act-investigate-user-needs - act-summarise-evidence - act-test-an-idea trigger: A few observation notes are available and somebody wants to choose what to prototype next. inputs: - A research question and decision owner. - Source-labelled, authorized observations with the product version and sampling limits. - Known counterexamples and the smallest next step that could change the hypothesis. output: A one-page brief with observations, hypotheses, counterexamples, unanswered questions and one proposed next study. steps: - id: frame title: State what needs to be learned human: Choose a question before choosing a feature and identify the limits of the notes. ai: Ask what decision the brief should inform. checks: - The question is not a disguised feature request. - Synthetic examples remain labelled. - id: separate title: Separate observation from interpretation human: Read the notes and mark one observation and one interpretation yourself. ai: Group observations with source IDs and label possible explanations as hypotheses. checks: - Messages are not counted as distinct people. - The easy-confirmation counterexample remains visible. - id: challenge title: Challenge the first explanation human: Decide what evidence would change your mind. ai: Suggest competing explanations and non-leading questions; do not invent responses. checks: - No majority or universal prevalence claims. - No simulated participant is presented as real research. - id: next title: Choose the next small study human: Choose whom to learn from next and what would count against the hypothesis. ai: Draft a brief and a changed-input revision for review. checks: - The changed receipt updates the hypothesis. - A single new walkthrough does not establish success for everyone. human_judgments: - Whether the evidence addresses the question. - Which competing explanation matters enough to investigate. - Who is missing from the sample. - Whether to prototype, investigate further or stop. ai_options: - Ask AI to group labelled notes and suggest alternative explanations. - Ask AI to draft neutral questions; a person must run any real research with appropriate consent. quality_checks: - Observed facts, hypotheses and open questions are clearly separated. - Every observation cites an active source ID. - Counterexamples and sampling limits are retained. - A changed product version invalidates stale claims. linked_practices: - frame-the-problem - brainstorm - prove-it improvement_targets: - quality - judgment - capability - time evidence: status: authored fixtures: - evals/fixtures/workflows/prj-discovery-brief-from-notes.json tested_on: unknown limitations: - Original synthetic inputs and authored reference outputs only; no model execution or independent human review. - Deterministic fixture checks cover the explicit claim contract, not semantic truth or usefulness. - Time savings, learning gains and performance on real work are unmeasured. second_use: Use the changed-prototype case, revise the brief and explain which prior conclusion no longer applies. Later compare with consented, authorized evidence gathered by people; do not treat generated interviews as validation. --- 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](/fixtures/prj-discovery-brief-from-notes.json). ```text 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. ```text 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.** ```text 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.** ```text 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. ```text 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: ```text 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](https://www.chatprd.ai/how-i-ai/workflows/how-to-conduct-rapid-market-research-and-competitive-analysis-using-ai). The source concerns market research; this discovery exercise, notes and prompts are original.