Stop overthinking the idea. Design the experiment.

Here is the pattern. Somebody proposes an idea. Somebody else raises a concern. A third person has a theory about why the concern does not apply. The meeting ends, the thread continues in Slack, and the whole thing reconvenes next week with the same information and slightly harder positions.

Nobody in that room is doing anything wrong. They are just trying to reason their way to an answer that reasoning cannot produce, because the answer lives outside the building.

Part of why this happens is that most teams only run half of product discovery. Discovery gets treated as interviews and exploratory research, which is the exploring half: figuring out which customer problems are worth solving. The validating half, where you create ideas for those problems, name the risky assumptions, and test them with real customers, is the part that quietly gets dropped. So teams end up with good problem understanding and no mechanism for settling solution arguments.

The mechanism is one well-designed experiment. Here is how to build it.

1. Start from an opportunity, not from the idea

The idea on the table came from somewhere. Before you test it, say out loud which customer problem or unmet need it is meant to serve, and where that came from: an interview, a support pattern, a drop in a product metric.

If nobody can name the opportunity, that is your finding. You are about to spend a week testing a solution to a problem you have not evidenced, and the cheaper test is five customer conversations, not a prototype.

2. Write the hypothesis down

One sentence, and it has to be falsifiable. "We believe that [this specific group] will [do this specific thing] because [this reason]."

The value of writing it is not documentation. It is that half the disagreements in the room dissolve the moment people see that they have been arguing about two different hypotheses. The other half get sharper, which is also progress.

3. Decide the metric and the success criteria, before you run it

This is the step teams skip, and skipping it is what turns an experiment into a story.

Name the metric that will move. Then name the number that counts as a pass, in advance. Not "we will see how it goes." An actual threshold: 15% of the people who see it click through, at least 6 of 10 testers complete the flow without help, conversion moves by 5 points.

If you set the bar afterwards, you will set it wherever the result landed. Everybody does. That is not dishonesty, it is how people read ambiguous data about their own ideas, and the only defence is a number written down while you still do not know the answer.

4. Name who you are testing with

Not "users". A specific segment, matching the persona the opportunity came from.

Test a feature for power users on whoever answers first in your community channel and you will get a clean, confident, useless result. The audience is part of the experiment design, and getting it wrong is the most common reason a test produces a number nobody trusts three weeks later.

5. Match the method to the risk

The method depends entirely on which risk you are actually worried about, and the two most common are different questions.

Demand risk. Will anyone want this at all? Landing pages, smoke tests, and the fake door test answer this cheaply, because they measure intent before anything is built.

Value risk. Will it actually work for them once they have it? Human-operated tests get you there without engineering: a concierge test where you deliver the outcome manually, a Wizard of Oz test where the interface is real and the machinery behind it is you, a single-feature MVP, a beta pilot with a handful of accounts.

Then there are holdback tests and A/B experiments, which are excellent for optimising something that already exists and close to useless for deciding whether to build something that does not.

Pick the cheapest method that could actually change your mind. That last clause does the work: a test that cannot produce a result you would act on is theatre, however rigorous it looks.

6. Analyse against the criterion you set

Proved, disproved, or inconclusive. All three are useful and only the third is annoying.

If it passed, build it, and keep the number so you can check later whether reality matched the test. If it failed, you just saved a sprint, and the interesting question is which part of the hypothesis was wrong: the group, the behaviour, or the reason. Usually it is the reason, and that sends you back to step one with a better opportunity than you started with.

If it was inconclusive, the design was probably at fault rather than the idea. Wrong audience, too few people, or a success criterion invented after the fact.

What this actually changes

Running one experiment properly is not a big organisational shift. It is a week. But it changes the shape of arguments, because the team now has a way to convert an opinion into a test result, which is the strongest evidence there is. That is the whole logic of scoring how strong your evidence is before you argue about the idea.

The second experiment is easier than the first, and the fifth is a habit. That progression is not automatic though, and expecting it to spread on its own is how most teams end up with one enthusiastic squad and no change anywhere else. It is worth being deliberate about the order, which is what building a culture of experimentation in four steps is about.

Getting a team through its first few properly designed tests, on their own live product decisions rather than a case study, is most of what we do in a Product Discovery Workshop.

So the next time an idea meeting reconvenes for the third week running, stop arguing and take fifteen minutes to answer six questions instead. What opportunity is this for, what do we believe, how will we measure it, what counts as a pass, who are we testing with, and which method. Then go and find out.