6 Tips to Using Customer Feedback To Iterate Your Mobile App

January 15, 2019

In today’s B2C environment, listening to customer feedback is a tick on every app development checklist. In fact, most mobile app initiatives have a testing and feedback phase built right into their design structure. But there’s a big difference between listening to your users and listening to them without a filter. If you were Microsoft, maybe you’d have the revenue to put money into projects alarmingly out of focus, but you’re not. That’s why we’ve come up with:

Six fool-proof ways to best use customer feedback to iterate your mobile app.

1. Be A Little Creepy.

Maybe don’t go investing in that two-way mirror just yet, but watching your users from a distance or even up close can alleviate the limitations brought about by having the user explain the issues they’re having. In other words, when you only give them the option of reviewing their experience through email or over the phone, they might miss the important stuff, like when and where they’re having trouble with a part of the UI, instinctively swiping in places you didn’t think of placing a certain function (and should), or seeing that users aren’t enjoying something as much as you thought (always gut-wrenching).

When you’re creating a mobile app, one of the 3 essential metrics you need is engagement, or stickiness. Watching users interact with your app, iteration after iteration, is the only way you can assure that you’ve created something that gets from signup to goal as non-frustratingly as possible.

2. Don’t Listen To Feature Suggestions.

There will always be well-meaning users that love suggesting new things, so we suggest you don’t include answers to questions like “What would make our app more enjoyable?” or “Do you have ideas for improvement?” into your iterative process. You should still ask, but keep them in a feedback bank, not feature backlog. The only value these answers provide is how much users want to help you out! As much as we love these users for their passion, we have to be very careful about applying them to product management.

Instead, ask pointed questions about pain points. Let’s say you’re creating an mHealth app to help patients find and apply for clinical trials. Here are some questions you might ask:

“Would you use this every day until you find a clinical trial?”
“Did you get stuck while looking for a clinical trial on our app?”
“Have you applied for a clinical trial online before, and did this feel easier and faster than that?”

3. Only The User’s Own Experience Matters.

The only feedback from a user you should listen to is feedback about their own experience. For example, a user might say “I’m not ready to use this app, but my doctor and my cousin suffering from MS would find it useful.” This would give you a potential referral for another source of feedback, but that’s all it should be. On a standalone basis, this “feedback” is just an opinion and not a validation for your app on any level.

4. Know The Lifetime Cost of Every Feature You Add.

MeetEdgar.com is a bootstrapped social media automation tool for twitter posting that’s somehow doing over $3 million in Annual Recurring Revenue amid a frothy sea of countless social media management tools. They’re also one of the best examples I’ve found for staying focused as a company. They’ve gotten badgered by users about accommodating Instagram posts, and not only did they not budge but they’ve also only introduced a grand total of 1 new feature into their pipeline in the last 6 months.

MeetEdgar reminds us that even for a company with $3 million in ARR, every feature you add has consequences. You may decide you’re missing out on a big chunk of the total addressable market by not having a feature, but every new feature has a lifetime cost that should include things like maintenance, debugging, additional server load, and compatibility. Ask yourself: Is that something you can afford?

A similar situation to feature cost is device compatibility cost. Seemingly every potential client of ours comes to us wanting to deploy simultaneously on web + iOS + Android. We have to remind them that the ability to have a single codebase for all platforms is a fallacy, so your lifetime costs will eventually spiral. We’re always telling clients: starting with multiple platforms is a bad decision for bootstrapped companies. It’s always better to start with a single platform and validate you’re onto something before moving onto another.

5. Let Your Metrics Be Your Trusted Advisor.

Your metrics are your trusted Consigliere. Sometimes we get distracted by overly complex metrics, so it’s important to keep it simple. Try putting it this way: just about every mobile app needs growth, retention, and engagement to do well

Growth is usually measured in the number of downloads (success is usually found with 5%-10% week-over-week growth).
Retention is usually measured in monthly actives out of the total number of downloads (success is usually found somewhere between 25%–50%).
Engagement (A.K.A stickiness) is usually measured in how frequently users use your app (success is usually found with daily or almost-daily use).

Let’s go back to the clinical trial app. Assume that multiple users say something like “If I knew what clinical trials my friends were interested in, that would help me find the right clinical trial.” The team decides to experiment by showing “clinical trials of interest” on other users’ profiles, does a sprint to deploy a very basic not-pretty prototype, and measures results. For this new feature to conclusively be a good idea, the team determines that at least one of the 3 metrics needs to improve without the other 2 metrics getting worse. It’s a fairly foolproof method I know I’m proud to stand behind.

6. Your Vision Should Be Your North Star.

Let’s go back to the clinical trial app. Your vision might be something like “We want to make finding and applying for a clinical trial as easy as finding and booking a doctor’s appointment.” Assume that users start saying they want more interactivity with other users, and you could say the data corroborates by showing that users spend a lot of time on each others’ profiles. In a vacuum you might take this to mean that you should increase user interactivity, but within the context of your vision, increasing interactivity among users really doesn’t help and actually might hinder them from getting to the clinical trials. If you keep your vision at the forefront of every decision, you’ll have a better chance of setting your app up for success.

Using the Godfather analogy again (I’m not sorry, as he wouldn’t be): No matter how wise your Consigliere, every “user hit” starts and ends with the Godfather’s vision. In a data-driven world, data can help you make well-informed decisions about what to do, but the decisions need to be in line with your guiding vision.