Almost every start-up and quite a few larger companies have ways for users to suggest features. These make sense at first glance: They give you a scalable way to understand what your customers want. Surely, you’ll want to use this information to inform your prioritization!
I intend to show not only that these are not helpful but that they are damageable. But fear not! Because I will also explain how to do it better. So, whether you love your current feature request form or consider building one, please read on!
Let’s start with the damage side, which is more counterintuitive. Sure, you might think, we may not get great ideas in our public feature requests, but having them won’t hurt us!
That’s not quite so.
See, there are four big categories of features coming from users:
- The wildly impractical: stuff that just doesn’t make a lot of sense¹
- The strategically unaligned: ideas that don’t further your vision — though they might fit one of your competitors’
- The big / not for now: ideas that are sound and aligned but will take a long time to build or cannot be done right now for whatever other reason
- The simple / already planned: features that are aligned and are either easy to build or already in progress
See, only users submitting category four ideas will likely receive a timely resolution. But also, since those are things you are either already working on or are very straightforward tweaks to the current version of your product… Why was user input necessary?
The other three categories will wait for a resolution that will never come² and grow frustrated. If the issue tracker is public, their frustration will be broadcast to the entire world, as in the case of this issue in Atlassian’s flagship Jira product, which was filed in 2006 and still hasn’t been resolved. Users are not happy about it.
And just to be clear, I don’t blame Atlassian for not fixing this³: there are many reasons why it may not have been prioritized. But whatever they may be, the users requesting it are left feeling abandoned: even if that feature doesn’t make sense to Atlassian, it does for them.
Even Featurebase, despite providing a feature request solution, has a whole article reassuring its users about the need to say no to most feature requests. They say:
As a startup, it’s essential to stay true to your core objectives and brand identity. This might mean turning down features that don’t align with your strategic goals, no matter how popular they are.
Right on! That’s features from category two right there.
I don’t know that anyone has precise stats on the breakdown of feature suggestions among those categories, but I would be shocked if more than 5% were in category four because there are just so many ideas out there! So, most of your users will be left like those poor Atlassian customers, neglected and without recourse. This isn’t a feeling you want to inspire among your users, is it?
You might think that the few users whose issues you can address will offset this feeling, but this is not the case. So, we come to the other problem with feature trackers.
When your users request features, their suggestions will be very iterative. They will start with the product as it is and suggest a twist, adding a button here, some feature there, or rearranging the information on some page. Their suggestions will often be based on their experience with a direct competitor: Can you make your product feel more like that one?
But this shouldn’t be news to you. As a professional, you should have a deep understanding of the current status of your product and any changes that are immediately adjacent to it, and you should also have an in-depth knowledge of the products of your (real) competitors. Your response to most feature requests aligned with your vision should be: “I know.”
The one thing that you can’t count on your users to provide you is disruptive innovation. That is the point of Ford’s famous quote:
If I had asked people what they wanted, they would have said faster horses.
“People” in Ford’s time couldn’t have asked for cars because cars weren’t a thing. The users saw the proximate problem—my horse isn’t very fast—but couldn’t jump to the ultimate problem, which isn’t making a speedier horse but going from point A to point B quickly and conveniently. Horses need not be involved.
This is one of the major limitations of data and user feedback for innovation. As I’ve commented before, users, by and large, only know what came before. They can’t tell you what should come next.
Fortunately, there is a solution to this that doesn’t involve lots of data and doesn’t require you to set up a feature request intake form… actually, it doesn’t require much more than you: user research.
User research means empathizing with your users, and this means talking to them. Specifically, it means having open conversations: Don’t ask your users about your product, but ask about themselves. Who are they? What do they do for work? What are their issues? Why did they choose your product in the first place? How else have they tried resolving their problems?
One thing to keep in mind is that the most valuable ideas will initially look terrible. Think about it: anything that obviously looks like a good idea should already be on top of your mind — and will be on top of your competitors’ minds, too! But occasionally, a product comes along that flies in the face of conventional wisdom. One that is inferior to its competition, as per prevalent performance indicators. The iPhone was one such product: inferior to the devices of the time by its price, fragility, battery life, lack of a physical keyboard, and many more factors. But, of course, the iPhone wasn’t seen as inferior because it entirely redefined its category.
What does that have to do with user research? Well, no user would have asked for an iPhone. No user would have filled a Nokia feature request asking for their device to be more fragile or expensive. It requires deep empathy with your users to realize that these criteria aren’t what matters: that the user base is ready for an entirely new paradigm.
The single biggest counterargument to user research is scalability. Even if your user count is in the hundreds, you won’t be able to talk to a significant fraction of them, so why even bother? That is part misunderstanding of user research and part cope, as I feel that many people would do anything if it means not having to talk to other human beings.
Scalability is not a real issue because you don’t need to talk to all of your users or even a statistically significant fraction of them. Over thirty years ago, Jakob Nielsen had already determined that, when trying to identify usability problems with an interface, testing with more than five to ten users was unnecessary due to diminishing returns⁴.
A similar thing happens with user research. The stories you hear from your users will start repeating each other. You will quickly start seeing patterns in the answers you will be getting. You will learn why your users “hire” your product.
It will be your job (not the user’s!) to understand your users’ real problems and how to resolve them. This is the value you bring to the table as an entrepreneur, CEO, or product manager.
Once you have identified an issue and devised a solution, there will be plenty of scalable ways to test it. But in the meantime, do yourself a favor and kill that feedback form.