How to build great products
defmacro.org
defmacro.org
This is the type of article I come to Hacker News for. Thank you for writing it.
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.
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!
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.
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.
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
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."
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.
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.
- 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".
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.
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.
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 :-).
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."
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.
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.
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.
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.
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".