Verified against ChatGPT · 2026-08-10
Convert a hunch into a hypothesis with a prediction specific enough to be wrong
Turns an informal belief about cause and effect into a testable hypothesis with a stated direction, a named confounder to rule out, and a concrete prediction — so it's clear in advance what evidence would count against it.
The prompt
Ready to copy — highlighted parts are example details you can swap.
I have a hunch, not yet a real hypothesis. Help me turn it into one that's actually testable.
THE HUNCH
I think our support ticket volume spikes on Mondays because of the weekend content backlog, not because of anything about Mondays themselves.
WHAT I THINK CAUSES WHAT
Users hit issues over the weekend when support is slower to respond, and file tickets once they're back at their desks Monday.
OBVIOUS ALTERNATIVE EXPLANATION
Maybe it's simply that more people are actively using the product on Mondays overall, so ticket volume scales with usage, not with a weekend backlog.
WHAT DATA I COULD ACTUALLY GET
Ticket timestamps and categories for the last 6 months, plus daily active user counts for the same period.
Restate the hunch as a formal hypothesis with a clear independent and dependent variable and a stated direction (increases, decreases, has no effect) — not just "X is related to Y," which is true of almost everything given enough data and predicts nothing specific. Then name the single most obvious alternative explanation for why the pattern might appear even if my proposed mechanism is wrong — using Maybe it's simply that more people are actively using the product on Mondays overall, so ticket volume scales with usage, not with a weekend backlog. as a starting point but sharpening it if there's a more obvious confound I'm missing — and state what evidence would distinguish my mechanism from that alternative rather than being consistent with both. Check the hypothesis against Ticket timestamps and categories for the last 6 months, plus daily active user counts for the same period.: if the data I can actually get couldn't distinguish between my hypothesis and the alternative explanation, say so plainly rather than producing a hypothesis I have no way to actually test.
WHAT NOT TO DO
Do not produce a hypothesis so hedged ("X may be associated with Y under some conditions") that no realistic result could ever contradict it. Do not skip past the alternative explanation just because the hunch feels intuitively right to me — the alternative is the whole point of this exercise.
OUTPUT FORMAT
1. The formal hypothesis, with variables and direction stated plainly.
2. The single strongest alternative explanation, and what result would rule it in versus out.
3. A one-line prediction: what specific result would you expect to see if the hypothesis is true.
4. A verdict on whether Ticket timestamps and categories for the last 6 months, plus daily active user counts for the same period. is actually sufficient to test this, and if not, what data would be needed instead.Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
An informal hunch like "X is related to Y" is compatible with almost any observed pattern, which is precisely why it isn't useful as a research hypothesis — a claim that can't be wrong under any realistic outcome hasn't actually staked out a position, it's described a topic. Forcing a stated direction and named variables converts a vague intuition into something a specific dataset could actually contradict, which is the property that makes it worth testing at all rather than just discussing. The alternative-explanation step matters because a model asked directly "is my hunch right" will tend to validate the framing it was given, since the informal belief supplies most of the context for what a "good answer" looks like — explicitly requiring a competing explanation and a way to distinguish it forces a genuine adversarial check rather than an agreeable elaboration of the user's own idea. The final data-sufficiency check closes the most common practical failure in DIY hypothesis testing: someone forms a hypothesis and a plausible alternative, but the data they actually have access to (in this example, ticket timestamps without a way to separate weekend-origin tickets from Monday-origin ones) can't actually tell the two apart, so the whole exercise would produce a result that looks like confirmation regardless of which explanation is true. Surfacing that gap before analysis starts, rather than after producing an unfalsifiable-in-practice conclusion, is the difference between a hypothesis that's testable in principle and one that's testable with the data actually on hand.
What you get back
Hypothesis: Weekend-originated user issues increase Monday ticket volume, independent of overall Monday usage levels. Alternative: ticket volume simply scales with daily active users, which may also be higher Monday. Distinguishing evidence: if ticket volume normalized per active user is still higher on Mondays, the backlog theory holds; if it's flat once normalized, usage volume alone explains it. Data check: available data (timestamps + DAU) is sufficient to run this normalization — no additional data needed.
Verified against
ChatGPT GPT-5.1 · 2026-08-10
Changelog
- 2026-08-10 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
