Designing for the 80% case is especially important in mobile, where cluttering the user experience with small, seemingly nice to have "features" ends up turning a smart, functional application in to a confusing piece of software.
Whether you can get away with building 20% depends on what kind of software you're selling and who is buying it. In the enterprise software world your customers are going to have a check-list of features, some of which are useless or redundant, but they happen to have been implemented by your competitors. If you don't implement those features, you may not even get your foot in the door.<p>There are lots of other areas where you would be killed if you tried to sell just the 20% of core features. For example, a "20%" smart phone probably couldn't compete against a fully-featured iPhone or Android phone.
Putting aside the kind of silly hypothetical exercise of trying to figure out which 20% of features to develop, the rest of this I feel is spot on. As a developer, so often I either come into applications with redundancy or get directed to build redundant features in. Often the person who makes that decision has no real basis, they just want to make sure people can use feature X, so it seems like putting in 3 different ways to do X makes sure everyone will use it. In reality, you are just adding overhead for your team and confusion for your users.
One way to mitigate this is to reduce the cost of maintaining those little-used features.<p>I've been doing this by (a) having a huge automated test suite that covers just about every feature (you don't get a feature in unless it has a test), and (b) being very aggressive about generating code, and (c) using Coverity to automatically find bugs.<p>The automated tests (a) let us know if a little-used feature breaks because of an unrelated change. That lets us decide whether to remove or fix the feature without the feature being a constant burden. Generating code (b) lets us make global changes to boilerplate without micro-managing each feature. And using code quality tools (c) is self-evidently better when you have a large codebase.
This reminds me of Alan Cooper's "The Inmates are Running the Asylum," where he argues that you can't please everyone and you should not be designing an application to solve all possible use cases because that's doomed to failure (or, at best, mediocrity). You can do better making a killer solution for 80% of your potential users than you can trying to address the needs of all potential users.
Yeah this is an interesting discussion. I usually stand on the side of one or two features done really well at first, then adding more as time goes on and needs arise, but always make these less used features more hidden in the UI.<p>However I think most people tend to use that train of thought, not so unique.
There's a follow-up post addressing some of the arguments given in the comments to the first post: <a href="http://www.johndcook.com/blog/2012/07/23/80-20-software-ii/" rel="nofollow">http://www.johndcook.com/blog/2012/07/23/80-20-software-ii/</a>
Of course, you might just find that 80% of the users you have left still only use 20% of the remaining features, so you should naturally recurse until you've left with just an empty <html> tag.