You are on page 1of 4

defmacro

How to build great products


Sep 26, 2013

If you believe that sales fix everything, it follows that most startups fail because they don’t ship a great
product in a growing market before they run out of money. Assuming you’ve picked an explosive
market, how do you go about building a great product?1

Building great products is hard, but the difficulty is greatly exacerbated if you have no good model for
analyzing products and features. Without a model you’re left with a never-ending stream of feature
ideas and half-informed shots in the dark. Some people can pull this off because they start out with a
phenomenal product intuition. But most people aren’t blessed with this superpower on day one.

I started out with terrible intuition (and didn’t even know it). Over the past three years I looked at our
user metrics every day, creating a feedback loop to train my brain on what makes a good product.
Eventually I got quite good at predicting the impact of any given feature, so I started thinking of a
model that captures the essence of what I’ve learned.

The three bucket model


The most important aspect of product management is categorizing features into three buckets:
gamechangers, showstoppers, and distractions. When I first started building products, all features
looked roughly the same. Over time, I formed the three bucket model and now my mind automatically
slots every feature into one of these buckets.

Here is an example. Suppose you are building a new mobile phone. It has to be able to call people, or
no one will buy it since it wouldn’t be much of a phone. But the reverse isn’t true — having voice calls
won’t make anybody buy your phone because every other phone already does that. So for your mobile
phone product, voice calls are a showstopper.

On the other hand, suppose your phone could project videos onto a surface. No other phone does that,
so this feature could be a gamechanger that excites a lot of consumers. Alternatively, it’s possible that
most people won’t care about it at all, in which case it’s just a distraction.

This example gives you three buckets to categorize any given feature:

A gamechanger. People will want to buy your product because of this feature.
A showstopper. People won’t buy your product if you’re missing this feature, but adding it won’t
generate demand.
A distraction. This feature will make no measurable impact on adoption.

Empirically, successful products have one to three gamechanging features, dozens of features that
neutralize showstoppers, and very few features that are distractions. Your job is to build an intuition
about your space to be able to tell these categories apart. That’s still pretty subtle (is a built-in phone
projector a gamechanger or a distraction?), but at least this model gives you a plan of attack.

Resource allocation
If you had infinite time, you could ignore these categories and blindly iterate on the product until it
resonates with the market. But your time is finite. The longer you take to find a great product, the more
likely you are to run out of cash, squander morale, or miss the market moving under your feet.
Modeling product management in terms of the three categories is extremely valuable because it allows
you to treat product management as a resource allocation problem.

If you put any effort into distractions, you’re wasting resources. That much is obvious.

If you’re doing more showstopper features than you absolutely need to, you’re wasting resources. Lack
of copy-pasting on the first iPhone might have been a showstopper for some people, but Apple
correctly determined that enough consumers would still buy the phone. There was no need to delay.

If you put more effort into any given showstopper than the absolute minimum you can get away with,
you’re wasting resources. The first iPhone had pretty bad voice quality, but it was good enough. Most
people were willing to live with it. It made calls, and it wasn’t terrible. Improving the voice quality by
another 10% would have made little measurable impact on adoption.
If you’re doing more than three gamechanging features, you’re wasting resources. Empirically, few
disruptive products are good at a dozen things. Shipping gamechanging features is hard. Three is
probably the most you can get away with, and even that is a stretch.

Finally, if you don’t pour enough creative energy into any given gamechanging feature, you’re wasting
resources. If a gamechanging feature doesn’t absolutely blow people away, it’s not much of a
gamechanger — it’s just a distraction. In this category you can’t go half way.

You can get away with making some mistakes. Very few products absolutely nail this on launch. But
most first time product managers break all of these rules all the time, probably because they’re not
aware of them. Break these rules at your own peril. The fewer mistakes you make relative to your
competition, the better. Every mistake can be incredibly costly. Make too many and someone else will
run circles around you.

Craftsmanship
The trickiest part of building products is learning how to tell the difference between the categories and
knowing when a given category is full. Is a built-in phone projector a gamechanger or a distraction? If
it’s a gamechanger, is it big enough to attract sufficient demand, or do you need another
gamechanger? If you invented the technology to increase voice quality by 50%, does that become a
gamechanger or is it still just a showstopping feature? How about 200%? How many showstoppers do
you have to neutralize to build a compelling phone?

I have no idea what the answers are for the mobile phone market, but in my area, unstructured data, I
can look at any given feature and tell which category it falls into quite easily. Sometimes I’m wrong, but
that’s ok. I just have to be wrong less often than my competitors.

The best way to build this intuition is to talk to a lot of people. Talk to potential users. What do they
think? Talk to people who tried to build a product in your space and failed. What can you learn from
their failure? Talk to competitors. How do they approach the problem? Talk to engineers in big
companies. What can they tell you about the state of technology? Talk to other entrepreneurs in
adjacent spaces, investors, journalists, grad students, professors, even the naysayers. The best way to
get a sense of taste in a given space is to inject yourself into the industry and talk to as many people as
you can.

Buyers, stakeholders, and pundits


The sooner you can learn about the history of the space, the state of the technology, the opinions of
potential users, and the direction of your competition, the sooner you can form a coherent view of the
space and develop a unique vision for your product. But be careful. It’s easy to start taking advice from
the wrong people.

Suppose you’ve decided to design your mobile phone in a form factor of a walkie talkie for construction
workers, and you’ve determined that the best way to sell it is to construction managers top-down. If
you talk to construction workers, they might be enamored by beautiful icons and an unusual color
scheme. You might determine that the unique design of your phone is a gamechanger. But ultimately,
it’s the construction manager who’s writing the check. For the construction manager, a beautiful design
is nice, but it isn’t a gamechanger. It doesn’t help him run the business any better than he did before.

For complex business sales, you have to pay attention to all the parties and make sure all the
stakeholders are satisfied. Are the construction workers strong influencers on the manager’s decision?
If so, spending time on a unique design might not be a bad idea. If not, you might be wasting your time.

It’s true even for consumer products. If you’re designing a luxury phone and pricing it above every other
phone on the market, do your customers have to convince their spouse? Do most families make shared
decisions about buying luxury items, or do people splurge on luxury items independently? If they have
to convince their spouse, can you add a feature to make it easier? Find out!

Beware of noise. Learn the difference between your users and people who are just commenting.
Everyone you talk to will have an opinion. Early on it can be tempting to design a product based on
feedback from industry pundits. But a feature is only a gamechanger if the person signing the
proverbial check recognizes it as one. Otherwise, it’s a distraction. Industry pundits can be extremely
useful for understanding the state of your field, but they’re rarely the ones to buy your product. If you
design your product around their feedback, you’ll find that there is nobody to buy it in the end.

A corollary of this is that you can’t design a great product unless you live, eat, and breathe like your
users do. You need to know exactly who your user is, what their problems are, how they perceive your
product, and who helps them make buying decisions. Your intuition has to mirror how the customers
will perceive your product. Categorizing features is only useful if it’s a good predictor of your actual
users’s response. Otherwise, you’re just wasting time.

Aggregate gamechangers
There is a subtlety to the model we haven’t discussed so far. Some features aren’t sufficiently
impressive on their own, but become gamechangers in aggregate. For example, suppose you design a
unique set of icons for your phone. Is that a gamechanger? Probably not. What about a unique color
scheme? It doesn’t seem like a gamechanger either. How about a unique family of phone cases? It’s
hard to imagine people buying a phone because of a pretty case.2 But what if you put these features
together? A unique design direction that combines a novel icon set, color scheme, and family of phone
cases sounds like it might be a sufficient gamechanger to attract consumers.

Features that become gamechangers in aggregate are dangerous for three reasons. Firstly, it becomes
harder to tell what combination of individual features is and isn’t a gamechanger. Secondly, aggregate
gamechangers are expensive — instead of making a couple of good decisions on a feature, you have
to make dozens or hundreds of good decisions for a whole family of features. Thirdly, it makes it easier
to convince yourself that if you add just one more feature, you’ll strike a gamechanger. Building great
products is already difficult. Introducing a subtlety like this makes it even harder.

Many products do succeed in exactly this way, but if possible, try to avoid it. If you have no choice but
to resort to aggregate gamechangers, it probably means you’re working in a relatively mature market.
Often, that’s ok, but it should prompt you to do some soul searching. Is it really worth being in this
market, or does it make sense to find another one where you can innovate more easily?

Product mission
Suppose you’ve developed product intuition to apply the three bucket model to your field. You can
easily (and correctly) categorize features. You’re now ahead of most product managers. But you’re still
not quite done. There are a few problems with this approach:

If you’re categorizing features ad-hoc, it’s easy to make mistakes and then construct a rhetoric in
your mind to convince yourself that you’ve done the right thing.
While you’re building the product, you’ll have to be a part of every single decision because other
people have no guidance.
Your engineers will get frustrated, because they’ll think you’re pulling decisions out of thin air.
Before the product is done you’ll have to convince many other people to help you — journalists,
investors, potential hires, and customers. Convincing people is hard if you’re making decisions ad-
hoc.

A great way to get around these problems is to write down a product mission. Think of it as a function
that accepts a given feature as an argument, and returns one of the three categories above. A good
function definition is concise, understandable, and repeatable. Ideally after reading it, most people on
your team will be able to categorize features themselves in the same way you would.

Here is a humorous product mission we came up with for RethinkDB that worked surprisingly well:

Database tools should be indistinguishable from magic


Surprise and amaze people with developer tools for building real-time, data-driven web
applications they could only dream of building, and bring sheer joy and simplicity to the process
of building great software.

On the surface these two sentences don’t say very much, but if you dig in a little, this product mission
has surprisingly high information density. It tells people we’re building a database. It tells people we
treat the product as a developer tool first. This resolves the tension between developer features (like the
query language) and operations features (like monitoring). All of our gamechanging features revolve
around developers. We treat operations as a showstopper. It explains what we expect our users to do
with RethinkDB (build real-time, data-driven web applications). It gives people a sense of how far we’ll
go on certain features (surprise and amaze). Being good enough for developers isn’t enough. These
people spend many hours a day using our software — we want to make the experience pleasant. It
suggests that we are willing to accept more complex implementations to make our users’s lives easier.
It guides us to build features that let developers build new types of applications, not just the ones that
already exist. It’s self-aware and leaks a healthy sense of humor we have as a team. This gives people a
sense of who we are. We can test feature proposals against this product mission, and with a bit of
additional shared knowledge it lets our team members independently categorize features in roughly the
same way.
It took us three years to understand what we’re doing well enough to come up with this product
mission. If we’d had it on day one, it would probably have cut development time in half — maybe more.
When you’re building a product, the mission should be the first thing you work on. If your mental model
is good enough to write a product mission that inspires everyone in your company, everything else will
fall into place.

1 I don’t mean to imply that picking a good market is easier than building a great product. In fact, the
opposite is true. It’s far easier to get a handle on product management, so I decided to tackle this
subject first. Aside from great products and market growth, there are also questions of distribution,
economics, regulated markets, and other subtleties. But the number of early stage software startups
that fail for these reasons pales in comparison to the number of startups that pick small markets or don’t
manage to deliver great products on time.

2 In practice it often turns out that people do buy phones because of unique colors or cases. But I’m
ignoring this subtlety to focus on a larger point.

Thanks to Michael Glukhovsky and Michael Lucy for reviewing this post.

Slava Akhmechet coffeemug Product at Stripe. Built RethinkDB.


coffeemug@gmail.com spakhm Computational neuroscience PhD dropout.
Dilettante economist, anthropologist, and
rationalist.

You might also like