Hacker News new | past | comments | ask | show | jobs | submit login
How to build great products (defmacro.org)
227 points by coffeemug on Sept 27, 2013 | hide | past | web | favorite | 29 comments



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":)


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.


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!


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.


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

I think this point gets lost all too often. It is a subtle but critical difference: a product guy can only do so much if you've picked the wrong sub-market.

Then there is the whole thing about what even constitutes a market. People refer to healthcare as a market. But healthcare has a few death trap sub-markets where you are just spinning your wheels and not likely to succeed. And then there are submarkets where you can building a half-assed product and still get traction.

Honestly, this has been the biggest learning lesson for me: that markets operate at a very micro level for startups. Too bad it isn't emphasized enough by folks preaching the whole pick-the-right-market idea.


Yeah, I have to agree. Looks like the author took a long time and care to formulate this thoughts. Obviously, the experience to come up with these thoughts took over 3 years as the article mentions.

This is the type of article I come to Hacker News for. Thank you for writing it.


The conclusion is very reminiscent of 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.


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


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


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.


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.


This is extremely interesting. I think I already do this intuitively, but didn't form a model for it in my head. I'll think about this for a bit -- would you mind if I later edit the post and add a section on this?


Sure, go for it. Credit would be nice. :-)


That's a very interesting subcategorization of game changers.

What I find quite interesting about thinking only in terms of hooks and painkillers is that this categorization might trick you.

A series of hooks could prove to be only distractions. A features that users think it's awesome is not necessarily "signing the deal". They might be an eye catcher, a conversation started, but in the end you might find that not enough users actually care about it.

As for painkillers, well, I think that those could be anything from game changers to distractions (include too many painkillers and you'll get MS Office :-).

Once again, this is only to say that I think I'd be thinking in terms of hooks and painkillers only after making sure that the feature is a game changer. And not vice versa.

ps: by the way I feel I disagree with some of the hooks you've listed. But that part of the discussion would fit better in a different context :-).


I don't think you should have a series of Hooks. The Hook's value is to get people's attention: it's often not actually that useful in ordinary usage, just like PageRank is far from the complete Google ranking algorithm and people usually don't care about the satellite imagery on Google Maps when they just want to get from place to place. But they made people stand up and think "Wow" when the product came out, and that's what convinced them to try using the Painkillers. Oftentimes the Hook is quietly retired once the product gains market acceptance.

By definition, if something is a Distraction, it's not a Painkiller. :-) This relates to the common marketing wisdom that your product should be an "aspirin", not a "vitamin". You should solve something that's painful to the user, not just an "Oh hey, this looks shiny."


When talking about painkillers I think we should also think about how many have that pain. If it's too little, then that painkiller can be a distraction. So while I fully agree with you that a distraction is not a painkiller, the opposite is not always true.

Plus I think painkillers could definitely be just showstoppers.

Once again, I find this subcategorization working great as a refinement applied to the @coffeemug's model. The only point is not to start with it directly.


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".


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.


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.


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.


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.


Gamechanger is also where bulk of the risk lies. What most start ups build as gamechangers often end up being features their market doesn't care about. This is why if you build a me-too product in a great market you can get quicker initial adoption than building supposed gamechangers in an unestablished market.


Match.com: Hook = Females! Painkillers = Females.


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.


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 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.


This is good stuff and I can totally relate to this based on our experience at 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.


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.


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


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".




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: