The Meat and Potatoes

5 Things Application Designers Can Learn from Gambling

Gambling involves betting a portion of money towards the goal of a larger return. This is not unlike what we do when building an application. We select the features we will implement with the hope that those features will form a valuable tool that is greater than the sum of its parts. But the similarities extend further than this. Here are 5 things every application designer could learn from gambling…

Lesson 1: Features Are Currency

You should think of features as currency, in that there is a finite amount of it. Every application has a “bankruptcy” point where the product begins to bloat due to an excessive number features. How you choose to spend that currency is the deciding factor in how your application will take shape.

Lesson 2: Define a Budget

When gambling it is very important to know your budget. You need to define the magic point where minimum investment meets maximum reward. Projects have “feature budgets” which vary in size depending on the project. The point at which Basecamp begins to bloat, is very different from the point where World of Warcraft begins to bloat. Look at the size and genre of your application and determine what that point is. Are you creating a productivity application that needs to stay out of the way while assisting the user in achieving a higher level goal? Or are you creating a game, where the journey to the goal is more important that the goal itself. These two genres imply very different “feature budgets”.

Lesson 3: Don’t Bet Big

The worst thing you can do in Vegas is walk into a casino and drop all your money on the first bet. Putting all your eggs in one basket sets you up for big failure. If you release a new component and find that only half of the feature set was successful, you’re stuck with the remaining half. If you make small bets, you eliminate the chance of making big (and costly) errors. Strip away from your “big idea” until you have the very minimum needed to get it off the ground. Once you’ve pushed that initial release you can then iterate towards the final vision, while testing those incremental changes toward real usage data. The goal is to maximize your return on investment with each feature.

Lesson 4: There are No Refunds

Next time you’re at the blackjack table and you lose the round, try asking the dealer for your money back. Features are difficult to take back once they’ve been implemented. Not having a feature in the first place is going to make users much less hostile than taking a feature away that has been adopted by even a small group of users. Make all your decisions with the mindset that once you’ve placed the bet, you’re in.

Lesson 5: Only Good in Moderation

Gambling can quickly become out of control if not practiced in moderation. The same is true with the addition of features. Step back and take some time to let your releases sink in and gather usage data. Growth isn’t defined by how much you add to a product.

  1. Tom Watson
    December 10th, 2007

    Great tips Mike! I especially like the no refunds analogy. You definitely have to tread lightly when introducing new features.

  2. Mike Gowen » Blog Archive » Defining the Initial Release
    January 12th, 2008

    [...] has a fair shot at succeeding. If you release too much, you may be stuck with a product that has placed too many big bets and ultimately ends up being off target once the user’s get a hold of it, not to mention you [...]

Post a Comment

This address is not shared or displayed
Your name will be linked to your website
or Preview