As product managers, we want to avoid the ‘build trap’ (remember Melissa Perri’s book?) and focus on outcomes rather than outputs.
I find more excitement and joy in creating outcomes and help both customers and business than chasing backlog items like a hamster in a wheel.
A good way to break out of the loop is to change your perspective. If you rename feature requests to feedback, many things will change, and here’s why:
This story is motivated by a vivid discussion that got recently initiated on LinkedIn by Andrea Saez:
She says, you should not call feature requests “feature requests” anymore, but instead call them ‘feedback’ and treat them like any other feedback you get from anyone using your product.
I think there is a lot of potential and energy in this little sentence and I tend to completely agree with her.
Let’s drill down a little bit:
What are feature requests?
If you google the words ‘feature request’ the first pages are full of results that point you to forms from companies like VMWare, Adobe GFI, Pinterest, and Google, all who would like to hear your ideas and wishes.
The forms are sometimes more or less deterring, asking you to enter many things about yourself before you come to the point where you may file your idea or wish.
Two examples:
Virtual Solution AG: https://www.virtual-solution.com/en/product-feedback/
VM Ware: https://www.vmware.com/company/contact/contactus-prod-request.html
A feature request is a change request or new requirement to your existing product. It is when a customer expresses what she would like to see added or changed in your product.
A typical feature request could be:
“I need you to add international formatting to the phone numbers our users are adding to their contact information.”
If we have a closer look at this we’ll find out what it really is: a solution description.
The solution to an underlying problem is: format phone numbers that people enter into a field.
I’d ask:
why format these numbers?
why do people need to enter these numbers?
what do you do with the information?
what’s the problem, you need to get solved?
how could we solve the problem?
The problem might be that new users could not use a service the customer was offering.
The people entering the numbers need to receive a text message in order to get a pin that allows them to enter the website, like a banking PIN.
People have been adding their phone numbers in their notation, which is utterly different in most countries, and just sending a text message to someone without knowing the international format of the phone number will not work with any of the text messaging services like Twilio or others, so the service was only usable by US customers since the default to the internationalization of phone numbers was the US notation.
This answers the first three questions and using a script that forces the users to enter their number in an international notation, for example, by adding a mandatory country selection.
Where do feature requests come from?
So-called feature requests have been around when I started my career in the late 80s of the last century.
Back then we asked our customers, who were the technical counterparts (the admins) in organizations, what they needed and encouraged them to discuss their needs.
This has changed dramatically over time and nowadays users are the main initiators of requests and articulated their wishes since the expertise in using a computer is no longer only with the nerds.
When people use your product, they do often not in the way you thought of, but in a way that helps them.
People want to solve their problems and not yours with your product.
By doing so they come up with all kinds of ideas about what they could possibly do with your technology and if you’re lucky they tell you — mostly by formulating an idea about what to change or add to your product.
That’s what we call a feature request.
How do feature requests get to you?
In my experience feedback comes from all sides, and all the feedback you get indirectly is pre-evaluated and potentially biased.
You get it through forms that customers fill out on your website, through comments in app stores, or other public platforms where your users and customers discuss your product. You’ll find a lot of feedback in meeting notes of your sales teams and support requests collected by your customer teams.
Your partners will tell you what they’ve heard and understood from customers and if you’re lucky your customers tell you directly in a one-on-one conversation.
What do you do with a feature request?
Anything you do with any other feedback, I hope :-)
This is the usual process:
You collect all the feedback, you identify the real problem behind it, you iterate through your discovery process and you come up with a priority, at best based on the expected outcomes.
Sounds easy, but there are a few traps, I wish we could all avoid:
If you have multiple sources of feedback, you need to get everything together and bring it in a form that makes the feedback usable for you.
You need to make sure that the feedback is honest and valuable and not biased or influenced by personal interests.
That is often the case when you get feedback not directly but through an intermediary person. We’ve all been in the situation where a sales colleague told us that our product misses this one feature and as soon as it is done, we’ll sell like hotcakes.
Or remember when support told us that the most urgent fix that’s needed is exactly the one the very last customer on the phone was complaining about.
Both may be true, but also potentially solving more our colleagues' problems, that our customers. I am not saying that your colleagues are liars, but they’re driven and motivated by their personal goals and they fight to reach them, as you do.
If customers write comments and feedback directly, how can you make sure that you identify the problem and understand what they really want?
Imagine one customer telling you: “I don't like green bananas” and another one saying: “I’d prefer ripe fruit”.
Both are merely telling you the same thing and you have to make sure that you don’t create a process for ripening bananas separate from asking your suppliers for a specific quality of food, they deliver to you.
You also have to make sure that you collect all feedback in one place and make it visible and easier to align with your business goals and the outcomes you expect. Are you interested in making this one super large customer happy or do you need to look at something 30% of your user base talks about?
This is where feedback collection and product discovery meet. You need now to work, probably with your team, on finding making sure that the right feature gets built for the right audience.
Download Now: Get our eBook on Mastering Prioritization
And since we all have not enough resources to get everything built and fixed immediately, we need to help our team to understand what needs to be built first and what next. There are many articles out there around ‘product discovery’ and ‘prioritization, so I won’t go into details here.
Why are feature requests and feedback the same thing?
Feedback is more than a request. All feature requests are feedback, but not all feedback is a feature request, like all bananas are fruit, but not all fruits are bananas.
If you look at all the things your customers say about your product, there will be a lot more feedback that may be useless or super helpful, than if you look only at feature requests. If customers tell you that they love your product — without telling you why or what in particular, you (and your team) may feel well and enjoy that, but it will not help you build the next awesome thing that delights even more customers.
The same is true for complaints.
What changes by just renaming the requests?
If you look at feature requests as if there are simple comments about your product, it helps you to open your thinking towards what the real problem of your customer is. It also helps your team and the entire organization that is involved with working on your customer's feedback to think in the same way.
If we get back to our example from above: imagine how your sales colleague would treat customers' requests and how she would discuss product development with your customer if she knew, you consider all wishes as feedback.
She could answer a request in a customer meeting with: “That’s interesting feedback, dear customer.
Let me understand why you need it and what problem of yours we’re solving with your idea” instead of saying “thanks for the feature request, I’ll hand it over to product management and see when they can build it”
“ you aren’t obligated to do it, but rather open to understanding what the problem is”, as andrea saez said in her post.
How can this help your colleagues from customer-focused teams?
A lot of feedback around your product may be super useful for other teams in your company. For example, marketing and sales teams will happily quote customers that say nice things about you and your product, without needing to get into details.
If I say I was blown away by what mmhmm by Phil Libin did for many of my video conferences, it may eventually be worth a quote, but not useful for the product team.
You need to make sure, that you establish a way to communicate and share all the useful feedback within your company and to those who need it.
Business Development -> Discovery -> Priorization -> Build -> Deliver -> Market &Sell
Looking at the high-level process of how an idea wanders through your organization from customer feedback to new feature in use, you’ll see that in most cases the contact with your customers for gathering feedback and for letting the world know that it is available is not with you, but your colleagues. In my experience, the handovers between the orange boxes (customer connected) and the others (internal) are most critical.
Conclusion
We will not be able to change the world and prevent our customers from sending us feature requests, but giving us feedback only and explaining their problems right away.
Any I guess we also do not want them to stop asking for new things. We have to change our internal wording and mindset and treat every ‘feature request’ as customer feedback.
We have to open our thinking to looking behind the requests at the real problems and combine our customers' real needs with our own knowledge about our products and build the right thing at the right time.
Changing the wording in our organization will also help the entire team to treat feedback and customer wishes with more focus on real problems.
This will change the way we interact with our customers because we automatically pay more attention to their real needs and we care more.
In our daily work never should prioritize feature requests, we need to prioritize outcomes.
Bernhard Hecker
Read also
All product feedback in one place
