A team builds a clickable prototype of an entire new onboarding concept, puts it in front of fifteen people, and eight abandon it partway through. In the debrief nobody can agree on why. Judged against Torres's account of assumption testing, what went wrong with the test design?

The principle — a test that puts many beliefs at risk at once returns a result that belongs to none of them.

Why the key is correct — Torres's practice is built around isolation: Assumption testing makes it clear that we’re testing a single assumption and not the whole idea. A whole onboarding concept carries many beliefs at once — that people will supply their details before seeing value, that the sequence matches how they think about setting up, that the explanation is enough without support, that the reward at the end is worth the effort. Eight abandonments is one number over all of them, so every account the team offers in the debrief fits the evidence equally well. That is why the room cannot agree: there is nothing in the result to decide between the explanations. The alternative is to name the beliefs, pick the one carrying the most weight with the least evidence behind it, and design something that can only fail because of that one. Then When an assumption test fails, we know exactly what needs to change.

Why the others are wrong — defending it on speed optimises the wrong property, since an unattributable result has to be chased with a second study and the fast route has cost a cycle rather than saved one. Claiming the failure still shows which part broke is contradicted by the scenario itself, where the debrief cannot settle it. And blaming a missing written list stops one step short: a team with an excellent list still learns nothing if the artefact it shows people tests the entire list simultaneously.

Remember this — if a failure cannot be attributed, the test was measuring the team's whole idea rather than one of its beliefs.

Sources — Teresa Torres on assumption testing, Product Talk.