Internal feedback on your product or feature is special, and can help you make better products that your customers’ users love, rather than tolerate.
Effort vs Reward
Much external (customer/user) feedback on your product gets to you because it’s so painful, that the cost of reporting it to you is worth the effort. That is, the time and effort involved in contacting your support team or customer success team, detailing the issue, why it matters, how it might be fixed, and the resulting follow ups, are worth the issue being fixed.
Many small frustrations, like User Experience issues, don’t meet that effort criteria. They’re small – tolerable – workaroundable. But they can quickly add up to a bad overall User Experience or worse, a poor opinion of your brand.
Think about this: If you’re setting up a new software product, and you have to a click a button twice to make the button do what you want, instead of once. What do you do? You probably just use the workaround. Because, you want to move onto the next thing. You’ve got a meeting in a minute. The time/effort involved in talking to your IT team, who then may need to contact the vendor, isn’t worth it to you.
But that software product, and its user experience, is suffering. The user now has a more-negative experience. The vendor of that product is missing out on opportunities to improve the experience.
Tapping into Internal feedback is one way to make sure you’re getting that valuable low-friction feedback that could take your product from “meh” to “yeahhh!”.
Take advantage of reduced friction
Internal feedback is different. There’s less friction involved. As a user, using my company’s products, there’s typically a forum or community where I can feedback, or raise a bug.
You can get feedback earlier. If you get the product or feature in Internal team’s hands earlier, you can fix issues before they’re even noticed by external customers.
Often, the feedback is more honest, too.
Also, internal feedback usually comes from love. Or at the very least, a desire to help the company build great products and be successful.
And because it’s internal, it should be easier to funnel/route it to the right places.
Some thoughts/considerations on Internal feedback
Some tips for dealing with Internal feedback:
- Build a community around feedback. Make sure that feedback is acknowledged and appreciated openly – if you want to make great products, people should feel like their opinions are wanted and they’re listened to.
- I personally love how open Slack channels can be. The feedback is right there – it’s trivial for people to “+1” a problem or thought.
- Make your internal feedback ingestion process as easy as possible for the people reporting their feedback. If you care about this feedback, it’s in your interests to make it really easy. The effort of raising/classifying the issue should be on you, the Product Owner/Manager. Get that friction close to zero.
- Where possible, have a place where you can “funnel” the feedback and keep it transparent. This can be hard in large companies with many products. But I favour asynchronous forums which are open for all to see (public Slack channels, for example)
- Don’t fall into the “We’ve never heard this from external people before” trap. That doesn’t mean the feedback is less worthy of consideration.
- Understand that in most cases, the feedback comes from wanting to make things better. It’s not personal. It might feel like criticism, and it might hurt because it’s from a colleague, but the intent is good.
- Don’t argue over whether the feedback is a “bug” or a “feature request” and don’t put that onus on the Reporter.
- Classification is irrelevant to the User Experience. Fix the experience.
What about Dogfooding
A note on “Dogfooding”:
It’s not enough to use your own products internally. You have to solicit and act on feedback from those efforts – build a community if you can.
If you don’t take and act on that feedback, you’re missing out on a huge opportunity to make products and features people love, from the people most invested in your own success.