Ask HN: How do you know what your users want?
What methods do you use? How do you differentiate signal from noise?
What methods do you use? How do you differentiate signal from noise?
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.
So my advice would be, ask who is your user first. Then pick the next question.
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."
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!
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