Skip to content

Instantly share code, notes, and snippets.

@tyre
Last active December 17, 2015 05:59
Show Gist options
  • Star 3 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save tyre/5561992 to your computer and use it in GitHub Desktop.
Save tyre/5561992 to your computer and use it in GitHub Desktop.
Stop developing for the 90% use case

TLDR:

Please stop overvaluing your time at the expense of your users. It is easy to get caught up in a features pissing contest with that other startup down the road, but don't lose sight of your mission. Take one problem that people have and solve it. Well. All of it. All of the time.

Last year I read the wonderfully concise essay Half, Not Half-Assed by the 37 Signals team.

It took me more than five minutes to figure it out, but the time spent thinking was definitely worth it. Talking with coworkers, friends, or conference attendees about those handful of paragraphs reinforces this.

Everyone gets it. And promptly ignores it.

You've all heard the phrases:

  • "We're designing for the 90% use case."
  • "It's good enough for now."
  • "What will the average user do?"

So you go off and solve the problem for 90% of users, for the common and somewhat-out-of-the-ordinary use cases. Believe me, I've said this shit too.

What's wrong with this? You're avoiding over-engineering; you're #shipping features faster; you're a productivity machine! But you are also making assumtions that make your product worse over time and presents a half-ass product to everyone.

So you build feature X for 90% that covers of users. The extra 10% is disproportunately more expensive to cover. So you build feature Y in the time it takes to implement that extra 10%. Again, you hit the 90% use case and, again, that 10% just isn't worth the time. You do the same for features C & D.

At this point, you have 4 features that cover 90% of people instead of, say, 2 features that cover 99.9% of people.

Nope.

The 10% of users who have special circumstances for a given feature are not necessarily (nor statistically likely to be) those in the 10% for another feature. It isn't that there 10% of the population who are just a pain in the ass, so we can make the decision to ignore them and still go after 90% of the market. And yet, that is how many companies, and even open source projects, operate.

Companies that execute this way:

Twitter

It took people a while (and many still are) to understand Twitter. "So you just post 140 characters?" For most of Twitter's life, yup. They did one thing (users posting small messages) and they did it very, very well. All of the amazing conversations and idea sharing that go on are powered by a platform that handles 140 characters. That is all users needed.

Square

Square processes payments. They don't handle group payments, they won't auto pay your bills, and they have no presence online to compete with PayPal. So why are they so successful? Because they took a problem and solved it. And continued to solve it. You don't think they know how many other amazingly lucrative ways they could have gone by now to expand? Of course they do, but they are making one thing, in person payments, as awesomely well as they can.

Apple

The first iPhone didn't have 3g. The 3rd and 4th editions eschewed 4g. You cannot expand the memory, which is profoundly marked up, you cannot run flash (which used to mean something), and the software customization options are... scant. There are products that have been shitshows, but the large majority of hardward sold out of Cupertino/China do a limited subset of everything very well.

As a user, I complain about things that don't exist (sorry), but I almost never leave a service that is solving one of my needs – no matter how small – well. I do leave services that send me monthly emails of all the crazy bananas features/things-in-the-pipeline stuff going on when core pieces of their experience is broken.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment