Turn Raw Observations Into Testable Hypotheses

Introduced in “Watch Users Work to Find What Causes Their Complaints.” Use it on a pile of tickets, CRM notes, and interview or observation notes when you want testable hypotheses without anyone quietly promoting a request to a requirement. Paste the prompt, then paste the observations below it.

You help a product team turn raw observations about users into testable hypotheses.
The observations are below this prompt.
Each observation is a complaint, a request, a support ticket, a note from watching work, or a telemetry finding.

Rules:
- Use only the observations below.
- Do not invent requirements, users, quotes, or numbers.
- Quote each observation exactly. Do not paraphrase a quote.
- Treat a complaint as proof of pain. Do not treat it as proof of cause.
- Treat a request as an observation. Do not treat it as a requirement.
- If the input does not state a fact, write “not stated.”

Steps:
1. Number each observation.
2. For each observation, record the source, the user role, and the date.
3. Label each observation with one User Evidence Ladder level:
   0 Opinion, 1 Anecdote, 2 Repeated independent reports,
   3 Behavioral evidence, 4 Observed user research, 5 Validated intervention.
4. Give the reason for each label in one sentence.
5. Group the observations that describe the same pain.
6. For each group, state the pain: what hurts, for which role, and how often.
   Write “unknown” for each part that the observations do not show.
7. For each group, write at least three candidate causes.
   Include the cause that the users named, if they named one.
8. For each candidate cause, state the evidence that would tell it apart from the other causes.
9. For each group, write one hypothesis in this form:
   “We believe [cause] makes [user role] experience [pain].
   We will know we are right if [observable result].”
10. For each hypothesis, write the smallest test that would raise the evidence one level.
11. List each question that the observations cannot answer.

Output:
A table with these columns: group, observations (by number), pain, candidate causes,
distinguishing evidence, hypothesis, smallest test.
Then the list of questions that the observations cannot answer.

Do not write requirements, user stories, or feature proposals.
Do not recommend a solution.
Do not rank the groups by priority.

Check the output before you use it. Every quote in the table should match the input word for word; search for two or three of them. Any number in the output that isn’t in the input is a fabrication, so delete it and treat the rest of the output with suspicion. Look at the User Evidence Ladder labels: an AI working from a pile of tickets should almost never assign Level 4 or 5, because nobody watched anything. And read the candidate causes for the cause the users named: if the AI listed only that one, or only variations of it, run the prompt again on that group.