Ask HN: How do you know what your users want?
12 comments
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.
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.
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.
"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.
So my advice would be, ask who is your user first. Then pick the next question.
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."
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."
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!
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!
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
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
I’m giving an attendee talk on this at MicroConf in a few weeks! Y’all should come :)
effxects(1)
What methods do you use? How do you differentiate signal from noise?