Ask YC: What causes startups to NOT build something users want? | Hacker News Reader

Ask YC: What causes startups to NOT build something users want?

21 pointsLeon22 comments

PG talks about building what users want as the main indicator of a startups success, but there are a lot of startups out there building things that I can't see anybody wanting. Why is this? Are the founders not paying attention to their users? Investors pushing the company in a bad direction? Ignorance? Ego?

Maybe it's hard to find out exactly what users want, but what can founders do to make sure they aren't getting caught up in a bad situation that's pushing them in the wrong direction?

View on HN

The thing you can do to make sure you're not caught in a cycle of pointless work is to release the product.

Stepping back a bit, another thing you can do is pick a market that (1) has a need and (2) is willing to pay for a solution. This works best for markets where you have personal and business connections to powerful people, but those can be built up over time. This is how much of the world's IT fortunes have been made, building a more efficient time clock or equities trading system or shipping logistics system. This is usually not something you can do with "innovative" consumer webapps because innovation targeting consumers generally implies letting people do something they didn't previously know they wanted to do.

If you're doing a pre-release consumer webapp, I think your best measure is how excited your team is about using the product. Sometimes this is hard to separate from excitement about building the product, but you should worry a lot if there aren't a few coworkers and friends who are totally in love with the product. Like, using-it-all-day-telling-all-their-friends in love.

You can take one spark of true love and work out a message that makes it grow. But you can't take a thousand gallons of "potentially interesting" and turn it into love without some significant new inspiration. And inspiration gets more and more difficult to add the more committed your team is to its existing product direction. Therefore it's very important to short-circuit this commitment by releasing early and making sure everybody knows that the measure of success is not lines of code, but attention and affection from users.

- focusing on too small a niche

- working on interesting technical problems that don't correspond to problems that people need solved

- making something that's only slightly better than what's out there (e.g. a slightly better news site or social network) and expecting everyone will magically switch or improves in areas that no one cares about

I feel like number 2 there is far and away the biggest.

"What causes startups to NOT build something users want?"

Not having a customer.

I cannot overstate this enough because it's the easiest mistake to make and I've already made it more than once.

It's so easy to say, "This is so cool!" or "I can do that!"

And then, "Who WOULDN'T want it?"

As it turns out, there's a very real possibility (even probability) that no one would want what you think is cool.

Having a customer, OTOH, changes everything. They're way too busy doing their jobs to ponder what's cool. They just want solutions to their problems. And they'll tell you. Especially if you are receptive or know how to ask.

Most of the times customers told me what they needed, I probably never would have thought of it on my own. And, invariably, those were the things that ended up being closest to what other people wanted, too.

Not to pick on him, but there was a startup posted here yesterday that got some harshly negative feedback -- it seemed obvious to many people that users weren't interested in what he was offering. The most positive suggestions suggested alternative product features. I think some founders build a product for themselves and can't understand that it doesn't offer mainstream appeal.

It seems like an easy way to check yourself is to ask your target users.

I think that's right on the money! Asking your target users what they want. Maybe I could share a few things for what it's worth. Back then I wanted to build a Yelp! like site just for the sake of it. I was thinking that guys like me would benefit from it. To cut the long story short it didn't go so well. Anyways a couple of months before my failed attempt I built a simple to-do list application. My dad saw it and asked me what else does it do. To cut another long story short this simple to-do list evolved into a full fledged project management application that is aimed towards people who are in the same line of business as my father. It's feature set was built specifically by the recommendation of my users. And by God's grace I have four companies lined up in the trenches ready to buy my software :-). So yeah without a FGD (focus group discussion) my company wouldn't be where it is right now. I was constantly amazed by the difference between what I want as a user and what my target users want. So never underestimate a good FGD session or similar to my case several FGD sessions.

Just weighing in here...

I'm never again considering what people say they want without a mountain of salt. All too often, what people say they want ends up not being used at all, not even by those who requested the change or addition. Users don't seem to be magically smarter than the developers in my experience. Design by committee has never worked so well for me. Especially in such a flexible medium as the internet.

But, releasing early is a good way to measure what people will actually use.

Agree. At my last employer, we did a bunch of market research before building the product. The CEO thought there was enough interest to go forward, so we built it. (Personally, I think he was suffering a bit from confirmation bias...) We took it before potential customers, they said, "We don't want that. But if you could solve this problem, we'd pay big bucks for it..." So we built that product. I left right as it was going to market, but from what I've heard from coworkers, it's had no more success in the marketplace than the first version.

Personally, I think the best way to figure out what your customers want is to do their job. Even if it's just on a trial, couple-of-weeks basis. Just make sure you try to do it to the best of your ability and actually seek out best-of-breed existing solutions.

People differ greatly in their needs, but most people doing the same thing run into the same problems. So if you're a financial software startup, try to make money with your investments. If you're a gaming startup, play lots of games. If you're a dating or social networking startup, try to get laid. If you're an e-mail startup, manage your company through e-mail. If you're a bugtracking software startup, put lots of bugs in your product. ;-)

Really, just a variant on "eat your own dogfood", except you can start imagining yourself as a dog before the dogfood actually exists.

It's best to listen to what people say they want, then ask why over and over. You'll notice that as you dig through levels of answers to that question, that very different requests come down to the same basic unmet needs. Then you engineer a solution to that.

When the goal is entertainment though, I don't see that strategy getting you far.

It works even there. Entertainment is as much science as any other business. Even the most popular songs around are more or less scientifically crafted.

I should say many of. Rock and maybe country are pretty much the only organic forms of music you'll find on FM radio these days.

Assuming you know/represent your users, if you are building something just for yourself and don't care if someone else likes it, great. But if your goal is getting users to use something, build a company around it, ask them & follow them.

Assuming your most vocal users represent your average user or target audience, read this Guy Kawasaki's post http://news.ycombinator.com/item?id=89088

Fear to question your old beliefs, think of the PayPal story. They originally thought they'll do payments through PDAs and put up the website as an afterthought. A week later they noticed everybody is using the website and almost no one is using the PDA software they wrote. They panicked and shutdown the website, until someone had the sense to say "if that is what our users want to use, lets let them", if they had insisted that PayPal only be used through PDAs you wouldn't have heard of them.

You would think that just asking your potential users what they want is best, but then you have to worry about self-report errors. As has been noted. (Customers lie. To you and themselves. Accept it.)

I'm fairly stupid and I don't possess a crystal ball...but since I also don't want to waste my time on things that don't pan out financially, I've spent quite a bit thinking about this question. I like to keep things simple, so I will generally only start or buy a company if it does one or more of the following (the more, the better): 1. Make the user money. 2. Save the user time. 3. Save the user money. 4. Get the user laid. 5. Save the user's life/improve their health.

There are a few other rules. Numbers 2 and 4 should never exist only on their own. Number 5 is often one of the most difficult to execute because prevention is harder to sell than solutions. And all of the potential ideas have to be a superior enough solution that they outweigh the switching costs for the customer (including the switching cost from nothing, inertia is a bitch!) Number 2 is the most likely to suffer from the "unwanted solution" problem (for various reasons, an outlining of which I suppose would better address the original question.) Multiple streams of income and multiple customer bases are always good things, just to hedge your bets.

Maybe you make something you want yourself, and figure you may not be alone in the world?

Yeah that's a good starting point, but that won't guarantee users. You've got to keep working on it. What causes people to go in the wrong direction?

Very true.

My technique these days is to find what the widespread masses will like and then work backwards until I find something that I will like too. At this rare intersection, I build.

I don't have any experience in a startup, but just thinking on the problem leads me to believe that not releasing early would be a big contributor.

Seems to me that if you release early, you'll get more interesting[1] feedback while your app is in a nascent stage and you can more easily change direction.

[1] By interesting, I'm mean that the feedback on a more fully developed release is more likely to be of the window-dressing, change-this-font-to-helvetica-16 type, while feedback for the early release will often be directed at adding desirable features.

quite frankly i think it is a trial and error process. there really is no proven technique. think it, build it. build it fast. assess response then react.

can you please quote some examples for this...

Do a google search on 'failed internet startup'

Inexperience.

Reply on news.ycombinator.com