
Ask HN: How do you know what your users want? - borisandcrispin
PG says that understanding users is the most important thing for a startup, but exactly how do you know what they want?<p>What methods do you use? How do you differentiate signal from noise?
======
vb6lives
We've had success with direct communication.

Tell your users to call or email of they have questions or problems. Then
personally speak with them.

You will find loads of valuable things you can do for them or find significant
pain points to address.

As for sorting signal and noise, you have to find generic solutions if
possible. Example: if you have any kind of reports or tables etc you will have
people asking you to add, remove, rearrange them. Users will get very upset
that their "really important" field isn't available. And you could add this
field but then the next person will come along. So give them some options to
add, remove, rearrange fields so they can get what they need without coming to
you first.

------
deanalevitt
Asking about their problems or goals is the best. In other words, don't ask
about what features they want (you'll figure that out), but ask what their
goal is. Research is good, especially in helping you figure out what questions
to ask and getting close to the issue, but talking to potential users is
unbeatable. I'd highly recommend 4 Steps to the Epiphany for great customer
development guidance.

------
TBonneau
"Who are you users?" would be the first question to ask. That would help on
determining what questions to ask next. For example with most SaaS products,
Ford's quote "If I had asked people what they wanted, they would have said
faster horses" is very applicable, meaning people often a limited by their
knowledge and personal experience and can't see solutions beyond those, so if
you ask them what they want you won't hear what would make a good product. In
other industries it can be pretty straightforward, if you are old enough you
would remember questionnaires your parents used to fill in for exchange of
free products (I think it was P&G) answering all sort of questions about what
products they use in their daily life from soap to dishwashing liquid, what
would they want improved, what's their favourite smell and whatever you can
think of (that then went to phone and I imagine now online).

So my advice would be, ask who is your user first. Then pick the next
question.

------
mntmoss
By developing a system of pass/fail signals.

A lot of early approaches to feedback involve directly asking potential
customers, or existing ones. This gives you _vocal_ feedback, but almost all
of it will be of the form "just add this and change that". And while this
works in terms of incremental refinement, and can improve an existing
successful product, often as not they will not be satisfied if you add this
and change that with something that isn't selling - because they are not
expressing the underlying issue(it is most likely too complex to grasp without
pouring yourself into it, and you have to make it your job to develop that
domain knowledge).

Instead look for mechanisms that let you immediately evaluate whether your
quality is going up or down: "if we break our performance target that's a
failure." "if we take more than two button presses to perform this action
that's a failure." You can poll users to ask if this signal is the form of
quality they are looking for: they will happily let you know that no,
actually, the button presses are not it, it's more important that they have a
certain set of views pinned front and center.

A bit of philosophical reasoning goes a long way to develop new signals: You
have to spend time pondering what the problem _really_ is and make sure you're
building up a principled approach that addresses it in a broad, coherent way
that informs the detailed decisions, and then get some confirmation that your
principles work for the people you want to reach. Your customers will want to
help, but you should expect to bear the brunt of this development effort too.

Many signals of engagement, interactions, purchasing patterns, etc. can be
turned into numeric metrics and graphed. These make for good eye candy, but
they tend to serve the internals of the business(e.g. cost reduction studies)
better than the customers, who will still always proceed through their
experience with the pass/fail model: "I didn't understand the documentation,
so I gave up."

------
timlloyd
[https://www.producttalk.org/2017/03/ladder-of-
evidence/](https://www.producttalk.org/2017/03/ladder-of-evidence/)

------
farcosailas08
Tons of research!

Many many interviews with target users and/or surveys before building MVPs.

After that, user tests to get feedback on the MVP.

It takes a lot of effort to find the right people but it's well worth it!

------
gitgud
I'm part of a small startup and we've found that most customers are happy to
provide feedback and feel like they are helping craft the system with us.

One other thing we noticed is that people don't want to fill out surveys, and
you can get much more insight by just sitting next to a person using the
system.

As for signal/noise... try to keep the majority of users happy

------
mjwhansen
I’m giving an attendee talk on this at MicroConf in a few weeks! Y’all should
come :)

