

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?<p>1) Use customer testing/validation (e.g., A/B, #leanstartup, et.al.) to drive design &#38; 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.<p>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 &#38; 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
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
Yes, ask them 'why' 5 times when they ask for feature A B C.

~~~
DenisM
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?

