How to Handle a Negative or Inconclusive Result

Pick the last experiment your team ran that lost. A clear loss. Now answer three questions: What did the team learn from it? What decision was made about what to do next? Where is that learning documented so that future teams can find it? If the answer to the third question is 'it is in someone's head', then every negative result your programme has ever produced is functionally invisible.

When a Test Loses

Confirm the result. Refer to the decision protocol.

Checkpoint: Does the experiment have a decision protocol written before launch? If not, the team has to make an ad-hoc decision right now, which introduces bias, politics, and the preferences of whoever is loudest in the room.

Investigate why. Record the learning.

Checkpoint: Where would you record this right now? Is there a structured place where the result, the learning, and the decision all live together and can be found by someone who searches for experiments in this product area?

Communicate the result with the same visibility as positive ones.

Checkpoint: Does your team share negative results with the same frequency and visibility as wins?

When a Result Is Inconclusive

Understand why: insufficient sample size, smaller effect than expected, or genuinely no difference.

Checkpoint: When your team gets an inconclusive result, is there a default process or does someone have to decide in the moment what to do?

What Good Looks Like

A mature programme treats wins, losses, and inconclusive results with the same rigour. If the checkpoints exposed gaps, they almost certainly come back to the same root cause: results, learnings, and decisions are not stored together in a structured, searchable way.

Checkpoint: Think about the last three losses your programme produced. Can you state what was learned from each one?