Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to build great products (2013)

defmacro.org

Post reply on HN
Print view View original

11–20 of 24 posts

Re: How to build great products (2013)

#11

Post by varjag »

monkeydust wrote: post #6
varjag wrote: post #4

Earlier quoted context omitted.

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.

Re: How to build great products (2013)

#12

Post by auganov »

polote wrote: post #8

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 produc…

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

Re: How to build great products (2013)

#14

Post by kavir »

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.

Re: How to build great products (2013)

#15

Post by catchmeifyoucan »

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/

Re: How to build great products (2013)

#17

Post by ChrisMarshallNY »

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

Re: How to build great products (2013)

#18

Post by __alexs »

ChrisMarshallNY wrote: post #17

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…

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

Re: How to build great products (2013)

#19

Post by ChrisMarshallNY »

__alexs wrote: post #18
ChrisMarshallNY wrote: post #17

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…

> 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 har…

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

Re: How to build great products (2013)

#20

Post by johnnujler »

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.
Post reply on HN