Ask HN: When to listen to users & when not to?

[neo]

Andreessen has said he thinks the highest entrepreneurial ability is shown by knowing what advice to take and what advice to ignore. It seems there are 2 diametrically opposed camps, to which to you ascribe to?

1) Use customer testing/validation (e.g., A/B, #leanstartup, et.al.) to drive design & feature decisions. Your job as the developer is to only iterate quickly and have a fast feedback loop incorporating their input. Prominent example: Google/Marissa.

2) Users don't know what they want (especially when it comes to "new" product categories that don't fit nicely into a pre-existing frame of reference) and so you must develop your own Design sense and intuition. Prominent example: Facebook/Zuck & of course, Apple/Jobs.

[andrewvc]

Well, the famous, if possibly apocryphal Henry Ford quote definitely lends itself to viewpoint #2:

“If I had asked people what they wanted, they would have said faster horses.”

At the end of the day you're in a gray area, and good judgement is the result of smarts, experience, and luck.

[fun2have → andrewvc]

Users can't give you the solution, but they can give you the challenge that needs solving. By listening to your users you can see that they want a faster means of transportation. The issue is to listen to them for the solution will point you in the wrong direction.

[trjordan]

There are two ways to ask your customers what they want: you can ask them, or you can produce a product, and see if they buy it. I'd unquestionably go with the second approach.

Even Google does it the second way, but, like everything else, they do it at scale. Instead of having a single designer, they let all of their engineers design, put everything out there with a "Labs" and "beta" sticker on it, and see what sticks. It their early days, they didn't have the resources to do that, so what did they do? Larry and Sergi pushed forward with their idea for a search engine, even as they were told the search space was closed.

People never know what they want in the future, but, in numbers, they are fantastic at responding to truly good ideas and products. That's the feedback you want, "Tell us what you think" boxes be damned.

[DenisM]

Talk to 18 of your future customers, ask them about their problems, ignore what they tell you and then ask what they were trying to achieve. Focus on the desired outcome, and the goal it leads to. If you stop hearing new things after 12 you have found solid targeting. Now you have technology on one hand and a worthwhile problem on the other, and you just need to figure out how to apply one to the other.

When staging your plan make sure to put important parts first, so ask your future customers which parts of the outcome they want the most.

So the first part is Listening, then comes Design, then comes the Iterative Loop.

[ndc → DenisM]

Yes, ask them 'why' 5 times when they ask for feature A B C.

[DenisM → ndc]

That might piss them off, but yes, the idea is to get to the bottom of it.

[timcederman]

The trick is not to have users design for you. You're only soliciting what they're thinking and how they act. It's up to you to decide what to do with that information, not the user.

[etherael]

I'll take a heaping of door number one with a dash of the second.

Alone, the raw data approach is enough to tell you that you're on the right track, while the go with your instincts position is not enough to tell you anything in and of itself.

Sticking to the raw data model but attempting to intuitively discern underlying currents and reasons for the shifts in the data and incorporating those into future direction is the ultimate sweet spot.

[access_denied]

These camps only seem to be opposed. How is the iPod nano not an iteration?