The hidden cost principle

Do you take into account the hidden cost when making decisions? It's one of those areas where I used to fail miserably. I've learned to take it into account over the last couple years, but only recently was able to formulate the concept properly.

The idea goes something like this: Behind most obvious decisions is a non-obvious hidden cost, which can often outweigh the benefit of the "obvious" decision.

I stumbled upon a great real-world example in the drive-through to Taco Bell a few days ago. I realized that there was a flaw in the system: I could order, then drive up to the payment window, and not be able to pay. Taco Bell would likely throw away the food, and have to eat the cost. The system had a flaw. Engineers like fundamentally perfect systems, and that's a good thing.

But if an engineer had designed the drive-through, you would probably have to pay before they started making your food. Impossible to game, flaw destroyed. The problem is, what's the cost of the extra time involved in waiting until you receive payment before you start making the food? And what's the cost per meal wasted times the number of times that the customer is not able to pay? There's a reason they start making your food right away: It saves a ton of time, and people are able to pay most of the time.

Seems obvious, right? Then why do we still insist on requiring two password fields, one for verification? Or two email fields? Sure, a banking application might require this... but your average web app? You could look at it this way: What's the chance that someone will mistype both their email AND password, weighed against the drop-off in signups because of the extra form fields. You will drop a significant number of sign-ups with the added fields, but there will be a very small percentage of people who get both their email and password wrong.

Another pet peeve that PG originally pointed out to us: requiring email confirmation as part of the sign-up process. Email is notoriously unreliable, and often gets flagged as spam or not delivered. Why would you require an email confirmation as part of your sign-up process when there is a high probability that the email will never be received, and the user won't be able to sign-up? Maybe I'm in a computer lab and I get email on my laptop. Tough luck, I can't use the website now, when I want to -- I have to wait until I can check my email. Does that high of a percentage of people not supply their correct email address, that you need to require confirmation? And does having a confirmed email address outweigh the big drop-off in signups?

We've learned to take the hidden cost into account with Weebly. It can apply to across the board: Adding features weighed against the added complexity to your application, bootstrapping weighed against the loss in growth momentum, increased security weighed against the increased difficulty in using the application.

In a nutshell: each decision you make will have a negative counterpart. Even (and especially) the most obvious decisions. Figure out what that hidden cost is, and make sure it doesn't outweigh the original benefit.