At the outset of a new project, or especially if you’ve recently taken over a product, it’s tempting to survey all your users to appraise where things are. It’s usually a mistake. In fact there are five common mistakes that we see over and over. Intercom makes getting feedback extremely easy, and as a result, it’s easy to become a little trigger happy with the feedback requests. Here’s five quick fixes for product feedback:
1. Stop talking to “all users”
Solution: There’s a much cleaner way to get much better feedback. Here’s some examples:
- If you want to improve your onboarding, only listen to people who recently signed up.
- If you want to improve a feature, only talk to those who use it.
- If you want to understand why people aren’t using a feature, only talk to those who don’t use it.
- If you want to find areas of concern, only talk to active users who use all your features.
Solution: Periodically check in with users. The simplest, yet still valuable, version of this is to ask users for feedback on day 30, 60, 120, 365, etc. This takes about 20 seconds to set-up in Intercom, and will pay for itself in a day or two. A slightly more advanced version would be to gather feature specific feedback based on usage. For example, if you have a calendar tool, you might ask someone for their thoughts on the first, twentieth and fiftieth time they use. As a user gets used to a product their feedback matures. The first usage feedback will explain what’s confusing, the twentieth will explain the frustrations, the fiftieth will explain the limitations.
3. Distinguish Free from Paying Feedback
- To improve your product for your paying customers, only talk to your paying customers.
- To learn what makes people upgrade from free, only talk to customers who upgraded from free.
- When you want to improve your free product, only talk to your free customers.
Solution: Treat every clustering of feedback that you see as a hypothesis, and then don’t build it, verify it. Once you verify that the pain is real, the next step is never “build the requested solution”, you have to go deeper. Which brings us to the last point.
5. Don’t assume users request the right feature
Solution: Be aware that customer feature requests are a cocktail of their design skills, their knowledge of your product, and their understanding of their current pain point. They know nothing of your product vision, what features you’re currently working on, or what’s technically possible. This is why it’s essential to abstract a level or two above what’s requested, into something that makes sense to you, and benefits all your customers.
Of course it’s worth noting occasionally a feature request will be spot on. It will rhyme with every thing else and perfectly fit in the world the way you see it. On these occasions you can skip steps, namely verification, abstraction, and clustering and trust your gut. Your product intuition gives you wonderful shortcuts, so long as you’re still a true user of your product, and constantly in touch with the needs of your users.
But on every other occasion, talk to your customers, it makes you smarter.
This is an edited version of a post originally posted at http://blog.intercom.io, by Des Traynor, Co-founder @intercom.You are free to re-edit and repost this in your own blog or other use under Creative Commons Attribution 3.0 License terms, by giving credit with a link to www.startupcommons.org and the original post.