We build too many things that don't matter. We don't set a stake in the ground about what does. And that gets in the way of delivering great products.I've seen dozens of seemingly promising products come to existence. And I've seen almost as many fail to gain traction with users. Something that has often perplexed me is figuring out what differentiated products that got mass consumer adoption overnight from ones that didn't. One of the things that stands out in my mind is that products tend to succeed thanks to a single core use case that really mattered to users. As developers and product people, we have a tendency to think through all of the angles, all of the potential use cases and edge cases. We are then imagining Jane user, who has some use case and feel compelled to address her need. Even worse, we'll consistently have someone on the team that *is* Jane user - and we can't bring ourselves to tell her 'sorry - your use case isn't going to be solved for today.'
What invariably happens is that we develop products in a capacity-constrained fashion because that's the easiest way to decide what's getting built and what isn't. Here's what most of my projects have looked like:
- Make a list of all potentially interesting and imaginable features
- Clump them into logical groups (label them as "releases" to make myself feel smart)
- Sort the clumps in order of priority (usually based on some bullshit set of metrics)
- Look at the number of engineers on the team and see what we can "fit"
Why is this bad? The two reasons this approach sucks are:
(1) It's not a ranking problem: Implicit in this approach is that we never take a real stance about what will make us succeed. Ranking features is not a statement about what is core (quite the opposite). Ranking puts all of the features on a continuum, whereas in most cases, the one or two things that make something work are in a league of their own. Even putting them in the same list as everything else is a mistake. Big category winners (Google, Twitter, etc...) have often done non-core things pretty poorly. We say they did well despite lacking xyz - maybe it's just the opposite...
(2) Engineering is the least of the costs: Users don't give a rat about how much effort went into building something (to my greatest chagrin). For many consumer products that I've seen work, a fundamental characteristic is that they claim a piece of "mental real estate" in users' minds. Google is the place I search. Facebook is where I find my friends. Evite is where I send invitations. Twitter is where I make statements. Reddit is where I procrastinate. YouTube is video. Etc... Usually, claiming this real estate is around a simple, eminently repeatable use case / interaction. Fundamentally, 99% of my searches, tweets, view views, etc... are identical (different content, but identical tasks). My claim here is that if we make a thesis about what matters, as long as we haven't nailed that one thing, all other "features" are actually destructive, as they get in the way of the one feature that matters (even calling it a feature is a mistake IMO :). If 99% of my visits to Google are to do a simple search, showing me a home page like Yahoo's means that you doubled the cost (in time) of using your search engine to give me features I never use. Free doesn't come at zero cost ;).
After going on this rant, I will clarify that most of my projects have not been an example of the above, but it's something I've become more and more convinced of as time goes by. Perhaps the sequence for planning should look more like:
- Make a list of the pieces of "mental real estate" we may want to conquer
- Make a hypothesis about which one piece of mental real estate we're going after
- Build purely for that piece of real estate
- If we win, good job, now we can start adding all the little bells and whistles
- If we don't get the piece of real estate, change our hypothesis, shed the junk we just built as much as possible and start over
