Photo from doctyper, available here.

Do you need to fail to build Product?

Ellen Chisa
Ellen’s Blog
Published in
3 min readOct 17, 2016

--

One of those cases I think back often from HBS is Compass Box Whiskey.

While the finer details don’t stick with me, the concept of “Angel’s Share” does. Angel’s Share is Whiskey that is lost to evaporation in the aging process (i.e. the angels get to drink it). One question raised by the case was “how do you account for Angel’s Share?”

Through discussion we came to two possible options:

  1. Angel’s Share as “loss” — you start with more, and end with less, the same way as you’d have less if you broke a case of whiskey.
  2. Angel’s Share as “Cost Of Goods Sold” (COGS) — a portion of the cost because it’s required to make whiskey.

Long story short, Angel’s Share counts as COGS. You can’t get whiskey without it.

It reminds me of how we talk about failure for startups. We sense it’s necessary as an industry. We love to analyze and share it (here’s a good roundup on all those pieces from Ryan Hoover).

But what about within a Product? You can launch a failed feature and not sink the company. I see the same two ways to think about it.

  1. Failure as loss — a mishap that sometimes happens while making products, but should be avoided.
  2. Failure as COGS — because it’s required to make progress. (For the accountants among you, yes, technical costs often aren’t linear and we’d probably count it as R&D. It’s just an analogy.)

I don’t think it’s one or the other here, the way it is for Whiskey. There are loss failures and COGS failures.

We should try to minimize loss failures — if you launch something without ever talking to a user (or collecting any data), that’s a loss failure. You could have avoided it. We all know what those feel like.

But some failures you won’t avoid, and that’s a cost of building a product.

You need failure to build product, just like you need Angels’s Share to make Whiskey.

So when I’m doing a postmortem, I try to decide if the failure was a “loss” failure, or a necessary one. For me, it was necessary if:

  1. If I had the same information, I’d do the same thing. Hindsight is 20/20, but there’s a big difference between “I ignored the data because I was arrogant” and “I made the best call I could based on the information I had.”
  2. I couldn’t go further without trying it. If the cost of learning was higher than just doing it, just do it. Talking to one user — an easy way to de-risk. Talking to all of your users? Not feasible.

Do you have another way to tell what a necessary failure is? Write a response and let me know.

I talked about this and a lot more on the Design Your Thinking podcast with Karthik here.

--

--