How to Avoid Running the Same Experiment Twice

Try this right now. Think of an area of your product that your team has tested repeatedly. Now search for every experiment that has been run in that area. All of them. How long did that take? How many places did you have to look? Are you confident you found everything?

Why Duplication Happens

Checkpoint: Where does your experiment history live right now? List every place. If the list has more than one item, that is how many places someone would need to search to do a thorough duplication check.

People leave. Poor naming and tagging. Teams working in silos. Time erodes memory.

Checkpoint: Search your experiment history for 'checkout'. Now search for 'purchase flow'. Now 'basket to confirmation'. Do all three searches return the same experiments?

How to Prevent It

Make the duplication check a formal workflow step. Maintain a searchable experiment history. Tag and categorise consistently. Link related experiments. Include the duplication check in the review board. Share results broadly.

Checkpoint: Is the duplication check currently part of your workflow? Not 'people usually check' but an actual required step that is enforced?

Checkpoint: Does a single, searchable experiment history exist in your programme?

When Duplication Is Acceptable

When the product has changed significantly, the user base has shifted, the original test was flawed, or enough time has passed.

Checkpoint: When your team intentionally retests something, do they cite the original experiment and explain what has changed?

What Good Looks Like

The method for preventing duplication is simple. Search before you plan. The question is whether searching is a five-second action or a thirty-minute excavation. That is not a discipline problem. It is an infrastructure problem.