
How to build great products - coffeemug
http://www.defmacro.org/2013/09/26/products.html
======
badclient
Wow. One of the best articles I've ever read on HN. I wish you'd also do one
titled "How to find great markets":)

~~~
coffeemug
_I wish you 'd also do one titled "How to find great markets"_

I'm working on a blog post on this now. Unfortunately I understand this piece
a lot less. If you point me at a market and say "build a product for this
market", I'm pretty confident I could do that and be the best. But if you
asked me to pick a great market, I'm not confident that I could do a great job
at all.

I think finding and analyzing market opportunities is much, much harder than
building great products. There are hundreds (thousands?) of phenomenal product
managers, but only a handful of people that _really_ understand markets. The
few that come to mind are Marc Andreessen, Peter Thiel, Elon Musk, Jeff Bezos,
and Steve Jobs (unfortunately he's gone now). I've read all I could find from
them, but even they are having trouble articulating this, which suggests they
don't have it entirely pinned down.

I'll see if the blog post goes anywhere in the process of writing it. I'd
really like to understand this better.

~~~
sashagim
_If you point me at a market and say "build a product for this market", I'm
pretty confident I could do that and be the best._

That's quite a bold statement! Any market? A social network, an online
retailer, a search engine, a mobile phone, a browser, an electric car? Give me
a list of those books you've been reading! But then of course, we could create
a paradox - we can't both be best, can we? :)

I believe creating the best product has an amount of luck in it. The better
work you're doing - the better are your odds, but at the end, like making an
Oscar winning movie, like writing a top of the charts song, like writing a
bestselling book, like a perfect storm, a lot of the right things need to
happen. But that of course shouldn't stop us from trying!

~~~
coffeemug
_Any market?_

It would have to be a market where I can get a handle on the state of
technology and its economics relatively quickly. I couldn't do it for biotech,
or cleantech, or surgical instruments, for example. I'd also need to be able
understand the users and their culture extremely well. I probably couldn't
design a great breakfast cereal, or sneakers for teenagers in Japan.

I really meant this comparatively. Understanding markets is an order of
magnitude harder than understanding products (at least to me), and is probably
more important.

------
johnrob
The conclusion is very reminiscent of
[http://www.paulgraham.com/13sentences.html](http://www.paulgraham.com/13sentences.html)
(see the last two paragraphs). As it should be, because identifying game
changing features is tantamount to understanding what people want. And nobody
knows what users want until they have feedback from product iterations.

------
calinet6
This is excellent for the high level view of things, to plan a successful
product for a market.

Keep in mind that a successful product for a market does not necessarily
equate to a high quality product. Internal product design should be user-
centered and cohesive with itself, not just within the market.

Thus I only further advise you to hire a UI/UX person to ensure this disjoint
product planning approach has some coherence in the bigger picture.

The overall picture here is excellent, especially the last bit. It reminds me
of this quote that I've always thought was one of the best pieces of business
wisdom ever conceived:

"If you want to build a ship, don't drum up people to collect wood and don't
assign them tasks and work, but rather teach them to long for the endless
immensity of the sea." \- Antoine de Saint Exupéry

~~~
coffeemug
_Keep in mind that a successful product for a market does not necessarily
equate to a high quality product._

I know what you mean, but I'm pretty convinced that it's not fruitful to make
this distinction when building products. To quote George Orwell's response to
Tolstoy's critique of Shakespeare "Ultimately there is no test of literary
merit except survival, which is itself an index to majority opinion."

[http://orwell.ru/library/essays/lear/english/e_ltf](http://orwell.ru/library/essays/lear/english/e_ltf)

~~~
calinet6
I think you have a point, but the greater point is that both are false
proxies. Survival is a proxy to majority opinion, which itself is another
proxy to quality.

Quality itself is not equal to survival. Survival does not determine quality,
nor does public opinion, each having far more variables and influences than
just pure product quality.

However, quality can of course influence public opinion, and public opinion
can greatly influence survival.

I think it is important to make this distinction—perhaps not to work by it at
all times, but you must realize that you're not working only by requirements
and measurements and proxies, but also by some intrinsic essence that your
product has, some idea that it stands as a cohesive tool, not just a set of
parts. Furthermore, sometimes people don't know what they want until they see
it, and use it, and realize its potential; and you'd never get there by simply
following a market. This is where the game-changing product creators of this
century have surprised the world with a vision.

I'm not saying the OP didn't realize this, just that I think it's more
important than many product teams realize to create more than just a set of
features that meet a market in the middle. Quality is a thing in itself.

------
nostrademons
Interesting. This formalizes a bunch of the intuitions about product design
that have been running around in my head lately.

I would extend the model a bit and divide the Gamechangers into two
categories: one (and only one) Hook and 1-3 Painkillers. Your Hook is the
feature that your market didn't know was possible, but thinks is awesome now
that it exists. Your Painkillers fix long-annoying problems in the problem
space. If you think of an individual's psychology when they encounter your
product, the Hook is what catches their attention, the Painkillers feed into
their confirmation bias to make them absolutely sure they want to purchase,
and then the lack of Showstoppers prevent any monkey wrenches from jamming the
sales channel.

Some examples from famous consumer web projects:

Google Search: Hook = pagerank. Painkillers = clean, uncluttered UI; fast
loading

GMail: Hook = 1 gig of email space! Painkillers = search over email, threaded
conversations

Google Maps: Hook = satellite imagery! Painkillers = Smooth AJAX UI, local
search results directly on the map.

YouTube: Hook = easy upload of all formats, even from cell phone video.
Painkillers = in-page embedding, Related Videos.

DropBox: Hook = Just drag to a folder to share! Painkillers = easy web viewing

FriendFeed: Hook = real-time updates. Painkillers = centralizes all your major
social networks, supports in-depth commenting.

Apple: Hook = Integrated beauty. Painkillers = good device performance, high
DPI screens, long battery life.

One easy way to categorize features into Hook, Painkillers, Showstoppers, and
Distractions is to put yourself into the position of the user and try to
accomplish the task they want to accomplish. Distractions are anything you
grumble about but then go about your business. Showstoppers are anything that
you drop what you're doing to fix, because you can't accomplish what you want
to otherwise. Painkillers are things that make you so depressed about your
task that you think about doing another task entirely. The Hook is
interesting, because by definition it's outside of conscious awareness and
requires an outsider's perspective to see. But if your cofounder is doing the
same exercise, putting himself in the mindset of a user, then you can use that
to illuminate it. The Hook is the feature that convinced your cofounder that
this was a company worth starting.

An interesting thing is that though the bulk of your engineering time will be
spent on eliminating showstoppers, basically all of your marketing should be
spent on the Hook. Let customers discover the Painkillers for themselves; if
you try to market yourself as solving more than one problem, your customers
will get confused and you won't solve any.

Another interesting corollary: this may be why big companies are seemingly
incapable of pushing out great innovative products unless they have an
experienced product person with wide discretion at the helm of the division.
When you market to executives, they will - of necessity - focus on the
Showstoppers. If your attention is focused on their attention (which is the
usual formula for advancement in a big company), then you will focus on the
Showstoppers too and develop a "feature mentality", where you just try and
list out features as a way of distinguishing yourself to your VP instead of to
users. You'd think the way to solve this is for the executive to focus on the
Hook instead, but when they do this, the Showstoppers tend not to get fixed,
because their underlings naturally tend to focus their attention on the VP's
attention.

~~~
aytekin
Additional ideas:

\- There are some showstoppers that apply to all products: Reliability,
security, trust, ease of use, speed, customer support.

\- To find gamechangers you need to think outside the box. Most people accept
things as they are. Most people run away from schlep work. The only way to
find gamechangers is to question everything and add a question mark when you
find yourself saying "that's not possible".

~~~
nostrademons
I'm not sure that it's actually true that showstoppers apply to all products.
Reliability and security, for example, are not showstoppers for Zynga games.
Security evidently was not a showstopper for Microsoft. Customer support is
not a showstopper for Google. Speed is not a showstopper for Gumbo (the HTML5
parsing library I just released).

Remember that a showstopper is defined as "Something that will _prevent a
customer from buying your project_." Sure, reliability, security, trust, ease
of use, speed, and customer support are always nice to have. But part of
building a startup on limited resources is knowing what's nice to have and
what will _prevent a customer from buying_ , and not spending resources on the
former. You can always go back and fix the nice-to-haves later when you have
more resources; you can't go back and resuscitate a company that runs out of
money.

~~~
mindcrime
This gets to the whole issue of "product/market" fit. For some hypothetical
market, security _is_ a show-stopper: Eg, there are people who chose not to
use Windows largely based on security concerns.

So for any combination of product attributes, you appeal to some market of
size _n_ , and are unappealing to some other market of size _z_. The question
is how do you build a product for which _n_ is sufficiently large,
acknowledging that you can't satisfy everybody at the same time.

Expanding beyond just product attributes, this whole discussion aligns with
the thinking from _The Discipline of Market Leaders_ which talks about how you
can choose to construct your value proposition based on optimizing one of
three possible axes (where product excellence is one), while striving for
merely "acceptable" on the other two.

Since different markets will purchase based on different value propositions,
the important thing (or so the authors argue) is just that you be really good
at one of the three, and just good enough at the others.

~~~
aytekin
Just started reading "The Discipline of Market Leaders", and it seems to be a
great book I've never heard before. Thanks for the recommendation.

~~~
mindcrime
Cool, I hope you find it helpful. I only just discovered it recently as well,
and haven't even finished reading it all the way through. But my initial
impression is very favourable and I suspect that TDOML will become a "go to"
book for me, much like _The Four Steps To The Epiphany_.

------
comatose_kid
This is an excellent framework Slava. Succinct and pragmatic. Thanks for
sharing it.

As you state, a big problem is developing enough of an intuition about how to
slot features into these buckets. Founder preference for given features can be
a good thing, but we have to be aware of this bias as we slot features into
these categories.

Slotting properly is especially important when you don't have many 'feature
arrows' in your quiver due to a lack of resources, morale, etc.

The other side of this coin is in measurement - each feature is in some ways a
test of a hypothesis. And you should have some idea of which metric matters
and how a given feature will move the needle.

It would be cool to hear how you approach this for RethinkDB -- since you are
appealing to developers, perhaps tracking how quickly devs move to a new
version for example.

------
mswen
An article like this reminds me of some of my own roots in consumer behavior
research and classic market research. Formal models of finding feature-to-
market fit are not particularly new. One that comes to mind is the Kano Model.
I tracked down an article that I co-authored back in 1998.
[http://www.quirks.com/articles/a1998/19981002.aspx](http://www.quirks.com/articles/a1998/19981002.aspx)
In that article we gave an overview of the model. I find the model
conceptually helpful but I was less enamored with the measurement methods.

------
olegp
This is good stuff and I can totally relate to this based on our experience at
[https://starthq.com](https://starthq.com) so far - we've been alternating
between game changers and show stoppers, while trying to keep distractions to
a minimum.

Another thing I want to add is the idea of the one key metric. In our case at
the moment it's the weekly growth rate of active users. Every iteration we do,
whether it's a game changer or show stopper, aims impact that metric.

------
orthecreedence
Thanks for your thoughts here. You break things down in a really easy to
understand way and you have a good writing style. I don't usually make it to
the end of articles this long, but your information is clear, concise, and
useful.

I'm launching a product right now (that uses RethinkDB!) and I'm going to put
some more thought into differentiating between "this would be a cool feature"
and "90% of people would kill for this feature." Very good idea on the mission
statement too.

------
strlen
Very interesting post. I often took "product sense" to be magic, I did not
really understand what was it that made iPhone soar in sales when it
introduced very little over a Nokia S-series I had at the time and didn't even
have a keyboard. Reasoning alone did not suffice: I could explain success of
OS X (a UNIX that ran on commodity-ish hardware that "just worked" \-- I did
not have to rebuild my kernel to get a WiFi card to function!), the iPod (ease
of iTunes/ITMS/using a large hard-disk instead of a 128mb flash...), but not
the iPhone.

When I (reluctantly) went to pick up an iPhone 3GS two years after the first
iPhone's release, I began to "get it" \-- it wasn't about a feature matrix,
but the quality (including visual) of the features it did have and (most
importantly) the way these features played together. Within minutes of having
an iPhone I was able to use capabilities that my Nokia phone claimed to have,
but that I have never found particularly useful/usable. Technically I could
use cut-and-paste to share articles from the web browser on my phone via
email, but I never did (but I began doing it daily on the iPhone!);
technically, I could I could run apps on the Nokia but the only third party
app I remember loading was Google Maps, etc...

iPhone was far from the first smart phone, but it "democratized" use of smart-
phone as a smart-phone: while it was still a toy largely for the well-to-do,
it was no longer a toy solely for a small fraction of well-to-do technical
intelligentsia.

I could apply reasoning to retroactively conclude that "yes, iPhone is a great
product"; however, it would take intuition to guess that right off the bat or
much less formulate what features would be vital to a consumer smartphone. The
popular image is that intuition is compartmentalized, innate, and unreachable
to training, practice, or (especially!) learning. I suspect the reality is
that talent does play a huge role (there's no way around it), but it is
possible to deliberately cultivate at least some forms of intuition.

That said, what's even more amazing is when one develops a sense of
gamechanger/show-stopper/distraction intuition about a topic that's not in
their domain of expertise. There's an anecdote that when Steve Jobs visited
Xerox Parc and met Alan Kay in the late 70s/early 80s he remarked that OO will
be hugely important to future of programming. What I find amazing about this
is:

1) Steve Jobs was not a software engineer, much less a PL wonk

2) In hind-sight the remark is obviously true

3) It wasn't a foregone conclusion in the 1980s, even among programmers.
Smalltalk and CLOS were seen as crazy ideas in the 1980s, who knew that in 20
years large bulk (if not majority) of programming would be done in an IDE, in
object oriented languages that run under virtual machines... Image based
persistence was seen as one part of Smalltalk (and some Lisps) legacy that
would never take off, but with user-accessible file system going away in iOS I
am not so sure...

tl;dr Intuition about products in a specific industry can certainly be
cultivated and learned (with hard work), but intuition about unknown (even if
interrelated) product industries (or concepts) still feels "magical".

------
johansch
This is all nice and stuff, but it's basically just re-inventing decades old
thinking using new words.

See
[http://en.wikipedia.org/wiki/Kano_model](http://en.wikipedia.org/wiki/Kano_model)

