What Does It Mean When a User Says “Add This Feature”?

Most of the messages that land in my apps' support inbox follow the same pattern: "Could you put a button here?" "Could you add this to the filter?" "It would be nice to have a list like this."

For a long time I treated them like a to-do list. I queued them up and worked through them in order. The result was an interface made of features that did not talk to each other, and users who still were not happy.

What I realized is simple, but it changes a lot: a user is not describing their problem to you, they are describing the solution they came up with. And that solution is a suggestion made by someone who cannot see the whole app, working from the limited information they have.

An example: "add a history list"

Let me work through a concrete case. Several users asked for "a history of the listings I've viewed." The first instinct is to build a history screen.

But I asked them why they needed it. The answers turned out to be wildly different:

• "I can't find a listing again once I've liked it." → What they actually wanted was saving.
• "I keep opening the same listing over and over, I forget which ones I've already seen." → What they wanted was viewed listings marked in the list.
• "I check to see whether the price has changed." → What they wanted was a price change notification.

All three users said the same sentence, and all three wanted something completely different. Had I built the history screen, it would have partly solved all three and fully solved none — and I would have added a permanent screen to the interface.

The questions I ask

When a request comes in, here is what I ask before saying "sure, I'll add it":

1. What were you trying to do at the time? — This surfaces the context. The same feature in a different context means a different solution.
2. How are you handling it right now? — The workaround the user has built for themselves describes the problem more clearly than anything else. If they are taking screenshots and saving them, a save feature is missing.
3. What happens when it isn't there? — This measures the size of the impact. There is a priority difference between "I lose a bit of time" and "I can't finish what I came to do."
4. When was the last time you needed it? — This measures frequency.

These four questions look like they stretch out the support conversation. In practice the opposite happens: building the right thing once takes less time than building the wrong thing and fixing it afterward.

The silent majority problem

The users who write to you do not represent all of your users. The ones who write are usually either very happy or very frustrated, and they are almost always more advanced than the average user.

The consequence is this: most incoming requests come from the minority who use the app heavily. If you follow only them, the product keeps getting more specialized and more complicated for new users.

To balance that out, I separate two things when I look at a request: how many people wrote in and how many people it affects. Nobody writes in about friction in the onboarding flow — because a user who gets stuck there doesn't contact support, they delete the app. But the number of people it affects is many times larger than for any advanced feature.

How I prioritize requests

I collect every request in one place and record it with three fields: which problem it solves, how many different users asked for it, and the estimated effort.

What I look at when ordering them is not how popular a request is, but these three things:

The part of that trio people skip most often is the "make room for it in the interface" side of cost. Every new feature makes everything already there a little harder to find. The fifth item added to a menu lowers the odds that the first four get tapped. That is why I turn down some requests even when the effort is low.

How to say no

If I am not going to build a request, I tell the user — but not with "we won't be doing that." The pattern that works is this: show that I understood the problem, explain how it can be solved with what already exists, and if it genuinely cannot be solved, say so plainly.

This has an unexpected benefit: the user often replies with more information. When they continue with "I do that, but it doesn't work in this situation," I see the real problem far more clearly than I did from the first message.

When not to listen to users

One last thing: some decisions are not the user's to make. Users generally ask for more options — more settings, more filters, more customization. Implement each of them one by one and what you end up with is a settings screen that everyone asked for and nobody uses.

Deciding what the product will not be is the developer's job. Users show you what is missing; only you can see what is unnecessary — because you are the only person who can look at the whole picture.

• Product
• UX
• User Feedback
• Mobile Development