Hacker News new | past | comments | ask | show | jobs | submit login
How to build great products (2013) (defmacro.org)
125 points by prawn on Aug 4, 2020 | hide | past | favorite | 23 comments



- First figure out if the market needs it. This is the biggest reason why products fail https://www.getautopsy.com/

- Asset economic viability i.e. you must be able to recover the cost.

- Ability to build and nurture a solid team that can deliver a product of reasonable quality and robustness.

- Find who your end-customer and paying customer is and whether this problem is light or hard in their head. Accordingly curate the right messaging for the product for marketing purpose.

- Ensure that there are no legal challenges.


The “Three Bucket Model” is something that I learned by reading Scott Jenson’s excellent The Simplicity Shift[0]. This was a book about mobile UX design, written before the advent of smartphones.

It is all about prioritizing features, as the real estate back then was bad.

I call it “Front of the Box/Back of the Box.”

The Front of a box on the shelf has two or three major eye-catchers, in huge text.

The Back of the box has four or five more, in slightly smaller text, and the sides of the box have the rest of the features, in even smaller type.

This drives my development priorities, as well as UX.

Engineers always want to do the most difficult thing first, just to get a feasibility study done, and the most challenging part out of the way, which makes a lot of sense (engineers tend to be quite sensible and practical).

The problem is, is if the most important feature is easy, it can be left to last, and can be jettisoned, if work on the most difficult (but less important) feature borks the schedule.

So you get a technically marvelous app that does what no one wants.

I’ve done exactly that. Repeatedly (I’m a slow learner). It sucks.

[0] https://jenson.org/The-Simplicity-Shift.pdf


> The problem is, is if the most important feature is easy, it can be left to last, and can be jettisoned, if work on the most difficult (but less important) feature borks the schedule.

This sounds similar to principle of WSJF and Cost of Delay that I learnt from "Principles of Product Development Flow". TL;DR. Ship the easy but valuable stuff first so that your users can get value out of it while you work on the hard things.

The mistake I've seen happen applying this in practice is that you end up cutting all the hard things which leaves you with a product made up entirely of easily copyable stuff and not much differentiation.


Good point. I never plan to skip the difficult parts, and one of the things that I have learned, is to not ship too early, even if it means a delay.

In fact, I am dealing with that right now, on a low-level Bluetooth SDK[0] I’m developing. It works great on iOS (and I even have a shipped app, based on it[1]), but I can’t consider it “shippable,” until I have test harnesses written for the other three systems (I’m just finishing up the Mac one, now).

[0] https://github.com/RiftValleySoftware/RVS_BlueThoth

[1] https://apps.apple.com/us/app/blue-van-clef/id1511428132


I like the three bucket model. I work on a programming language and we talk about it in terms of:

1. Differentiators. ("Gamechangers" in the article.)

2. Tablestakes. ("Showstoppers".)

3. Niceties.

I like "tablestakes" because it describes the presence of the feature and not its absence. Also, a betting metaphor implies that this is a moving target. The tablestakes can be raised on you if all your competition adds some beloved feature. When Dart first launched, non-nullable types would have been a differentiator. Now it's tablestakes.

Languages are interesting because you have a very limited budget for differentiators. Users have a finite appetite for novelty in programming languages, so you have to spend that wisely on a small number of very compelling features.

The third "niceties" category is interesting. Those are features that please existing users but are not compelling enough to attract new ones. There is an argument that you should not focus on those if you are trying to grow your userbase since by definition they aren't compelling enough to attract new users.

But I believe they can be important for growth. Shipping features that bring joy to existing users can help turn those people into your product's evangelists and, especially in programming languages, you really need that.


Seriously, who are these people who believe that sales alone can fix everything or building a great product alone can change their life? Everyone, and I mean literally every human being I have interacted with on this topic have assured me of the difficulty, complexity, and multifaceted-ness, of what it takes to get something going from ideation to profit, either through their fear of stepping into this territory of entrepreneurship or through their experience. And anyone who has been an entrepreneur or at least has tested the water will definitely have some sort of intuition for what it takes. If people still rely on a single factor, either they are one of those fraudulent aholes or the asocial nerds who should improve their sales skills(or hire someone who has the required skills). Never understood people taking about the multivariate and complex nature of life. It is complex and multivariate; and everyone knows it.


"Sales fix everything" is a shortcut for "There are many experienced people who can help fix most problems your company is currently struggling with, and if you give them lots of money they will help you win.". You can throw money at most issues in HR, retention, brand, marketing, government issues, customer support, engineering speed, infrastructure. Of course, it is possible to hire stupid people who will hurt you, but we can assume basic competence on behalf of the successful entrepreneur and that she can find competent helpers.

In business, if you have a product nobody wants, you generally fail. If you have no means of capitalizing your company, you generally fail. But if you turn the product into a money-printing machine, you will resolve other problems with enough iterations. Sales momentum does not make your startup immortal but sets the company on a better trajectory than another startup with amazing culture, great passion, but no customers/revenue.


I've also seen companies that are such a complete mess and have such terrible product that they should just die fix everything with sales.

I worked for one that (on average) spend 950 euro to sell a 1000 euro product that isn't worth 5 euro. (It was extra "funny" since I just gave up trying to "sell" a similar vastly superior product for free. "Suspiciously cheap" was my potential clients verdict 99% of the time. After all, from all angles, every day of the week, they were offered the same product for 1000 euro!) I never sold anything working there but that was perfectly normal.


I believe market validation is more important than having a great product that no one wants to use. The combination of product and distribution goes hand in hand to building a great product. So don’t obsess over UI and tech stack in the first version, until you have demonstrated customer demand.


One fourth category to consider is "quick wins" (papercuts). The smallest things you can do that make customers feel delighted. Not everything will be game changing. These are the items that are easy to build, and still provide minimal value. These often don't qualify as "features", but do make life easier. For example, a simple "copy url" button or keyboard shortcut might fall into this category.

Good example from the Github Team: https://github.blog/2018-08-28-announcing-paper-cuts/


Building a great product should almost never be the goal, people don't buy a product because it is great, people don't use a product because it is great.

People buy a product because they are forced to buy it and people use a product because they love it.

This is the biggest mistake people make in product management, is to forget the customer

> it follows that most startups fail because they don’t ship a great product

this is so wrong

edit : funny that the guy behind the article created only one company (rethinkdb) which failed because they didn't find a business model


> People buy a product because they are forced to buy it

That's the best situation to be in, but people certainly often buy stuff just because they think it will benefit them in some way.

It's worthwhile to think about the sheer marketability of a product beyond its strict usefulness. Some things are easier to sell regardless of the actual functionality.


to put in different words, we all start using a product because we need it, and we are willing to put up with not great design and lack of features. Usually is that product that does one thing that you need, later on you might fall in love with it.

I agree is not the other way around where you try to make something people will fall in love, that's why I think "scratch you own itch" is such a great advice.


Whatever you do, make sure to get the basics right:

- Good UI - Fast UI - Good performance and if this is not possible, keep the UI responsive and give Feedback to the user


"Showstopper" to me means something quite different, but reading your description made sense. It's a wordsmash noveau


Analogous advice applies to academic research, career/resume building and perhaps even dating!



Community is also key. it will either make it or break it.


Thousands of successful commercial products have no communities to speak of.


Yea, community is relatively new phenomenon in software at least the way it is down now. Traditionally its something curated and orchestrated via sales and product managers, events,seminars, 1:1 meetings or sometimes small coherts of similar clients. There is still value in this versus newer forms of community.


With a bit more cynical view, "community advocates" and "product evangelists" are still marketing and sales people. Only that community (i.e. users) is now shaped to bear additional function of first level support on the Internet.


The iPhone example is frankly laughable. Try selling a smartphone without copy/paste and with subpar vocal quality if you're not Apple. People will throw it in your face.


If it is also a razor, a piratebox and a sex toy you can get away with crappy voice q.




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

Search: