Page 65

One tool to make this easier is to reframe decisions as experiments. You’re no longer a perfectionist frozen on stage with everyone watching your every move, you’re a curious scientist in a lab trying to test a hypothesis.

Treating any captured item as a “possible experiment” can help us detach ourselves from the necessity of the project’s completion. Although this is pretty much what the #GTD Someday/Maybe is: It lets an idea sit until you (a) see clear learning value and (b) have bandwidth to run it.

Instead of finding the perfect solution, make experiments, and analyze them by success factors.

1. Hypothesis – What do I expect to learn or prove?
2. Metric of success – How will I know the experiment taught me something?
3. Next action – The first, smallest, concrete step that moves the experiment forward.

If you can’t write all three in <60 s, it probably isn’t worth experimenting yet.

Adding “as experiment” alone will not automatically convert the meaning of a project into an experiment. A project should still be an outcome. An experiment is more like a subproject.

Experiments-based projects should work pretty well with work-related projects, where POCs are like experiments. We could call this “Experiment driven programming”.