Over the past few years, I’ve become totally convinced that being as close to your users as possible (via minimum viable products, feedback mechanisms, etc.) greatly *increases your chances for product success*.
However, once you have a decent sized user base you immediately run into the problem of what do with all that feedback. *The suggestions you’re getting quickly outpace your ability to act on them, and clearly you shouldn’t act on all of them anyway.*
I don’t have the silver bullet answer of course but I’d like to suggest that the get satisfaction model of counting up the ones with the most votes and acting on them in that order *may not be your best move in all cases*. Consider the following:
* *Really small changes/tweaks can make a big difference.* At my last company we ran significance tests on single word copy changes, and some led to dramatic percentage increases in funnel outcomes.
* *Small changes that make a big difference are often non-obvious/intuitive.* That is, many iterations are often required (hill climbing) before you really nail something.
* *Adding features can lead to interface clutter.*
* *Product polish has non-linear effects.* If you absolutely nail a product experience (polish) it can go word-of-mouth viral (induce non-linear effects).
In other words, you are often faced with a real choice given your resource constraints: you can go in the direction of being a *jack of all trades, master of none* (delivering many minimum viable features people are asking for); or, you can go in the direction of the *master of one (or few)*.
Both are certainly viable strategies and have led to many successes. And I suspect that there are certain situations where one or the other makes more sense.
However, my hunch is that many startups fall into the former category (jack of all trades) almost accidentally because they don’t have the will/vision/stubbornness/whatever to buckle down and do the latter. That is, they are not making an explicit choice, which may ultimately not be in their best interest.
The reason is that delivering features people ask for is the path of least resistance. Not delivering them requires you to essentially ignore (or at least gracefully put off) huge obvious feature requests and *focus diligently on stuff that seems much smaller, and to the untrained eye, perhaps trivial*.
And that’s the key. Are these small things really trivial or are they part of a larger product vision where you end up with a truly polished product? It’s often hard to tell, and sometimes really a probabilistic bet. You really never know if you can nail a product experience until you do.
It’s a counter-intuitive strategy and often involves working on some features that no-one even notices but makes their experience smoother or a series of “advanced” features that 5% of your users will use but a different 5% for each feature (meaning that almost everyone adopting has a smooth experience).
It’s also counter-intuitive because it seems harder to defend from other companies. You’re not adding more features to a feature chart. But what’s not easily understood is your small changes are actually hard to copy because *you’ve made a ton of small decisions that others won’t implement the same way*, and so the copy-cat will end up with very different funnel results.
*Bringing this all back to product feedback, you shouldn’t ignore that one-off request/comment just because it is one-off. It may be a real piece of the puzzle.*