By developing a system of pass/fail signals.<p>A lot of early approaches to feedback involve directly asking potential customers, or existing ones. This gives you <i>vocal</i> 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).<p>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.<p>A bit of philosophical reasoning goes a long way to develop new signals: You have to spend time pondering what the problem <i>really</i> 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.<p>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."