How to Fail (like Edison) Without Failing Horribly

“I have not failed. I’ve just found 10,000 ways that won’t work.”
― Thomas A. Edison

“Failure is the condiment that gives success its flavor.”
― Truman Capote

“Success is stumbling from failure to failure with no loss of enthusiasm.”
― Winston Churchill

Famous quotes that you see on posters in your classrooms and on bumper stickers. The message: failure is awesome; failure is necessary; i’m successful cuz I failed!!

It’s a wisdom that’s becoming ever more conventional, and it’s scary, because still, many of us still associate failure with

  1.  throwing an event and having 5% of Facebook RSVPs actually attend
  2.  promising an outcome and not achieving it
  3.  recruiting a team for the fall semester and it turns out they all suck

Trust me, we get how hard it is to translate the advice on failure into actual actions within your organization. So here’s a different way to think about it:

Experiment and Prototype. There are ways to fail on a very small scale. Remember in chem lab when you had to do titration, and you thought that turning the lever on your buret degrees would get the perfect flow of acid/base and then BOOM you’re wrong and all you’re left with is really pink liquid and disappointment? Do you remember what you did next?

You started all over and turned the lever (x-3) degrees.

Whether you’re running a 2000-person conference, building solar lamps for a small village, planning a small dialogue on social justice issues, YOU CAN EXPERIMENT. Before waiting until the final product to test whether everything your team has planned is viable, start modeling smaller,  beginner versions of the actual goal. You can

-attend similar events and observe the dynamic + outcome

-ask 5 friends of friends to sacrifice 2 hours to participate in a beta-version. Promise them pizza.

ETC. You’ll learn so much about what can go wrong and what can go right, without sacrificing your org’s dignity or time.

Collect Feedback. You’ve probably sent out user feedback surveys of some sort after completing a project. Don’t just reserve the feedback for post-production! Start collecting some data during the decision process.

You’ll have to decide on logos and designs.

You’ll have decide what your audience values more: x, y, or z? (let x= expert speakers, y=networking z= food, etc.)

You’ll be deciding on a lot of things. And it’s easy to get into stagnant debates with your team about what will work, or what the most “effective” plan is, but honestly, testimonials and unfounded statements are a thing of the past. Since when were you an expert and representative for the hundreds/thousands of people you’re catering to?

Drop your emotional attachments and SUPPORT. WITH. EVIDENCE. You’ll discover that a. you were totally wrong about your assumption, b. you were totally right about your assumption c. whoa didn’t even realize ___ was possible!

Identify Worst-Case Scenarios. Sometimes it’s not feasible to do any of the above. Now you find yourself in a hour-long + counting discussion with your team, and honestly, it’s going nowhere.

Once upon a time, in an MPowered exec meeting, we had been arguing about whether or not to contact an important leader on campus. Chris gave his reasons for no. Cathy gave her reasons for yes. I said, “but couldn’t so-and-so happen? There’s no point.” Shreyas and Lucy tried to mediate and structure the conversation. We weren’t getting anything done.

So, instead of flooding our senses with millions of outcomes and arguments, we distilled the discussion into two parts:

best-case scenario  || worst-case scenario

These are two blatant extremes that rid your conversation of fallacy-filled statements. Getting everyone to understand that BOTH are possible, maybe one more likely than the other, and then moving onto how to ensure the best-case scenario.


These techniques for small-scale failure can help your organization be smarter, faster, and more relevant.