5 pennies or 1 dime

By | April 6, 2009

Ask any 5 year old:  Which is better?  5 pennies or 1 dime.


Any 5 year old will tell you the 5 pennies are better.  There are MORE of them, of course.  They don’t care that the dime is more expensive.

OK, now consider your software product.  Which is better?  5 small features or 1 giant one?  (assume the same proportions as the pennies/dime)

Surprisingly (or not), most companies think too logically.  They think the 1 giant feature is better than the 5 small ones.  They are wrong.  People will always enjoy a long series of little improvements over one big honking feature.

According to the 80/20 principle, 80% of all of the users time is spent on 20% of the functionality.  Giving them another big thing to use misses the point; that is giving them more stuff in the 80% unused bucket.  Rather, you should improve the 20% that they use all the time.  They will love you for it.

I know that sometimes you need to build something big.  Just balance that out with attention to the details.  A bunch of minor improvements actually gets more love than one big improvement.

7 thoughts on “5 pennies or 1 dime

  1. Glen Lipka Post author

    Thanks Avinash. I imagine this goes for lots of other topics. Like Analytics for example: Sometimes low-hanging fruit metrics are more helpful than working towards a giant end-all-be-all chart. I think I read some of that on your blog at some point.

  2. Dan

    I think that only works if the multiple programs have a similar UX. I don’t want to learn how to use five new programs, when I can learn one. The Microsoft office suite is a good example of this. To create a graph in Excel, PowerPoint, or Word, you use basically the same process; however, they each get to focus on their core functionality as well. On the other hand, I am very happy that all computer maintenance programs (spyware, clean-ups, start-ups, defrag, etc.) are now bundled together into one piece of software. Perhaps there is a live cycle to these things. First a large companies add in new functionality to their existing software, but it is not great since it is not at the heart of their mission or expertise. Second a new company forms to focus just on that new functionality and makes it much better. Finally, the large companies either buys or copies the improved design and implements it back into their larger software package.

    Ohhh, and I hate pennies. Get rid of pennies. Damn the pennies. And start the phase out of nickels for 2015.

  3. Glen Lipka Post author

    @Dan: I’m not sure if you and I are talking about the same thing. I am talking about how a single software product evolves. Choices are often presented to the product manager to build either one big feature or several smaller features.

    The point is that several smaller features have a disproportionate positive impact based on their investment in effort. In other words, they have a better ROI.

    I am not talking about multiple products. That is a different issue.

  4. Dan

    I see. Well, in that case I would think that the most important thing is to choose the feature(s) that best compliment the 80% that people are using. And that might be one big thing or lots of little things, I guess it would just depend. One example I can think of in MS Access, one of my most hated pieces of software. They seem to be making lots of upgrades and additions, but the main functionality still sucks balls. I’d rather they evolve the software with a large feature to make it work fundamentally better. On the other side, I love Excel. The 80% that I use all the time works great. Therefore I want lots of other small features all over the place. Of course, I have no idea what this means from a true design perspective, but just from a user perspective. Of course there is the sales perspective, in which we might believe the more features in there, the more selling points there are.

  5. Rachel Luxemburg

    It also depends on your business model and market expectations.

    Foe example, shrinkwrap software providers need to include enough new “wow” features to let customers cost-justify purchasing the newest version. A release that doesn’t have enough new stuff runs the risk of being denigrated as “just a bugfix that should be a free patch”.

    On the other hand a SaaS provider might find it more effective to add multiple smaller, “cheap and cheerful” feature improvements that will keep users happy enough to continue subscribing with fewer big new features that require more time and money (and risk) to create.

    Different markets, different expectations, different outcomes.

  6. Glen Lipka Post author

    Human psychology works for all markets. You are making assumptions about exactly what kind of feature a penny is and what kind of feature a dime is.

    You can try to buck human psychology all you want, but people are hard-wired to like 5 new things versus one new thing. Think of it this way…you are on a game show and you DON’T KNOW what are in the secret boxes. The guy says, “do you want the 5 boxes? or the 1 box?” any idiot would choose the 5 boxes over the one with no further information.

    Users have no idea how hard a feature is to build. And often “easy to build” features have an enormous impact. Don’t just assume that because it takes you a long time to build them, the user will like them more.

    Feel free to disagree with everything written here.


Leave a Reply