Fail Fast and Fail Often

broken plates
fail fast and fail often

This is a part of the User-Driven Programming Series.


One of the most important lessons I’ve learned, not just as a person but also in developing a user-driven programming model, is to fail a lot. Trying, experimenting, and testing results in a ton of failures. These failures are extremely valuable. In fact, failing fast is central in creating good programming on the long-term.

Loving to fail can lead to lean and low-cost programming.

There is a simpler version of every idea that we can come up with or that the users can come up with. In fact, we tend to overcomplicate most things in our lives. By testing out new ideas in a low-cost or lean way, we can spend our energies on the right things. We want to validate the ideas that will work and put aside the ideas that won’t work right now.

We want to create the Minimum Viable Product. What is the simplest viable version of the idea to see if it can grow to something better? By focusing our energies on these smaller versions of programs, we can test and see if they will be successful.

Fail to lower the stakes.

This is a hard earned lesson in my life and it is true here as well, most things aren’t that important. By lowering the stakes of “success” we can try out many more ideas and see what is going to work best for our organizations and communities.

A series of programs can be tested by trying one, or a speed-dating version, or a zoom call instead of an in-person encounter. You can test a fellowship program with three participants instead of thirty. There are many ways we can lower the stakes so that failure doesn’t seem so scary.

The learning is most valuable asset.

The value in testing new ideas, programs, and experiences is to learn about the projects and the audience. We want to understand why something did or did not work, why people were attracted to one part instead of another part, or when a program might be best for a particular group. The evaluation of the tests, the learning from our failures is far and above the most important thing.

If I run a program and it doesn’t work, that’s ok, we lowered the stakes from the outset. But if I don’t learn anything about why it didn’t work, then we missed a huge opportunity to do better next time. Experiments are useful when we are testing an idea and can discover something new.


Have a question on how to implement this? Want me to help you set it up? I’m available for consulting and I’d be happy to work something out for you and/or your organization! Reach out!

Leave a Reply

Hi! Thank you for visiting The Rabbi’s Manual.

This project is currently on hiatus.
You can find more current information about me and my work at the links below: