How to Balance Internal Feature Requests with Customer Feedback

Everybody’s got an opinion. But as a product manager, a key part of your job is to figure out just whose opinion you should be listening to. One area where this debate rages is balancing product feedback from internal stakeholders with those coming from customers.On one hand, “The customer is always right, but we know: A) That isn’t always true and B) If they’re already a customer, then just how important is that new feature or enhancement? Will it be adding a dash of delight or is it critical to keeping them from cancelling?

Alternatively, internal product feedback can be fueled by many motivations, some of which may have nothing to do with actually making your product better or more profitable. This is why gathering internal input shouldn’t just be limited to the times when an internal resource reaches out to you, but rather be an ongoing process.“Product managers cannot have one-time meetings and expect input-on-demand. Yes, they’ll get some, but they’ll miss even more. It is important to solicit, and be open to, feedback on an ongoing basis,” says JT Pederson of Tata Technologies. “And this is where leadership is important. Doing this requires establishing a reputation with all the concerned stakeholders, being consistent, and avoiding being (even if only accidentally) dismissive when comments are given.”

Qualifying Internal Feature Requests

One of the key factors to weigh when receiving a wish list item from an employee is to assess whether or not that person actually knows how your product works.This is why “eating your own dog food” is so important for company staff, and why any internal request should be weighed accordingly based on just how much of that dog food the requesting party has been scarfing down.

“By using the product, you'll be able to see the product from the perspective of your customers. The creator of the product looks at it as a father looks at his child — no flaws, no problems, all great. But by using it, you'll step in the customer's shoes and feel what the customers feels,” says Michel Ozzello of OutSystems. “You'll find all the nagging defects, all the missing features, all the things you could do to make it better.”Of course, “dog fooding” can come with its own set of issues, since your employees may not actually be your target audience.“You might be a tiny startup building a product for a Fortune 500 megacorporation. Or a team of millennials trying to improve the lives of retirees,” says Michael DeFranco, Founder and CEO of mobile enterprise communications firm Lua. “It would be dangerous for the product to veer off-course to become something that fits our own needs perfectly, but neglects our true target audience.”[3]Another available tactic for prioritizing internal requests is requiring the staff member to not just list something they’d like added, but to make their own business case as the sponsor of the change or enhancement. While there may be some moaning and groaning about the extra effort required, this ensures that there are legitimate reasons for the request and gives you and other stakeholders the background and context required to truly evaluate its merits.“The important thing is that you’re not trying to impress anyone. This shouldn’t be a competition for how many ideas people can think up,” says Pandora’s Tom Conrad. “The person evangelizing for an idea has to truly believe it is vital for the company right now.”[4]

This process also gives you the added benefit of seeing where requests are coming from and what they’re intended to address, so you can make sure you’re giving every group something they want on a regular basis. Additionally, if the justification for a request was that it would capture new business, improve a business operation or reduce a cost, you can now validate after the fact that this intended goal was truly achieved.

Quantifying Customer Requests

If a customer asks for something, there’s a fairly good chance that it is a legitimate ask. They use your product, and they think that adding or changing something will make it more useful to them. Usually, their feedback is valid, although they can occasionally be asking for something they don’t really want, understand, or won’t actually use. But assuming those potential red herrings are vetted, how do you decide which customer requests to prioritize?First of all, don’t start with customer requests, start with customer threats and demands. Lots of people will ask for things, but if a customer is ready to bolt unless you do something, their concern should definitely get some early consideration. This doesn’t necessarily mean you have to build whatever a particular customer is having a tantrum about, but customer flight is a legitimate concern, particularly since it’s usually cheaper to keep a current customer around than to find a new one.Using the urgency and negative repercussions of ignoring these “screamed” enhancements adds some context to your prioritization. Once you’ve dealt with these fires by putting them out (and putting that enhancement on your roadmap) or consciously deciding to disappoint the unhappy customer for the greater good, you can begin sorting through the rest of the requests.Start by assessing how many customers this will  actually impact, as well as the level of impact this change will make.

“A feature change that does not affect many people, will likely not be appreciated by many people either,” says Dave Schneider of NinjaOutreach. “You can impact a lot of people, but if it is a smaller amount per individual, the overall value is still relatively small.”For example, while UI tweaks affect everyone, not that many people may notice or care, while new functionality and capabilities could radically change how a few or many of your customers use and value your solution.You should also ensure a customer’s feature request is something you actually want in your product. While it might be nice for a particular customer to have a built-in calendar or integration with NetSuite and Salesforce.com, is that the strategic direction you want to take your product in?Each feature you add doesn’t just cost you resources today, but you will have to continue supporting it for years to come. Burdening your product with third-party integrations and extraneous features could prove limiting in the long-term.

Research the Feature Request's Value, No Matter the Source

Whether a feature request comes from your CEO, a customer support inquiry, your lead engineer, or a customer site visit, there’s no excuse not to validate its usefulness and value by asking around. But remember the potential impact of the suggestion is just as important as (if not more important than) where it came from.So don’t be shy when it comes to asking customers about potential new features. You’re not making any promises by asking for their feedback, and you can temper their enthusiasm a bit by asking them to rank a list of potential enhancements. This scoring is useful for you, plus it makes it clear to them that each new widget comes at the expense of building a different new one. Getting customers to think about tradeoffs is healthy and beneficial for both parties.Likewise, you can shop your externally-sourced requests around internally. Ask the sales reps if this will help them close more deals, check with customer service to see if this will address frequent headaches and complaints, and canvass your technical teams to see what they think.The more inputs you have, the more obvious it becomes which features should jump to the front of the line. Plus you’ll have that much more evidence to combat any challenges to your prioritization.

Encourage Healthy Debate

While no one wants a prioritization exercise to descend into a screaming match, another productive way to determine which feature gets to the top of the list is to let the sponsors make their case in a crowd.URX has made Contrarian Office Hours a part of their culture, and this forum for open and non-judgmental discourse can be utilized for discussing potential features as well.“It creates a safe space where people are not just allowed to mix things up, but given express permission to call things out. It also primes people to not take things personally…. We tell our employees to check their egos at the door, so as a company we need to do the same thing,” says URX CEO John Milinovich. “They can express how they feel, but no one is being attacked personally. It’s all about building the best company possible.”

Load Balancing

Regardless of which source product feedback is coming from, you should ultimately be trying to make the most of your development cycles to position your product for success today, tomorrow, and the days/weeks/months after that. Each chunk of enhancements (regardless of your release cycles and terminology) should be checking each of the following boxes:

• Increasing usage - Making the product do this means more people will use it (or the people who use it already will use it more)
• Increasing revenue - This change will make more people pay for your product (or drive whatever else is bringing in cash)
• Improving performance - What you’re doing will make your product faster, more responsive or break less
• Reducing unnecessary costs - This improvement will cost your company less, whether it’s reducing support calls or using fewer raw materials
• Ensuring competitive parity - You’re keeping up with the Joneses and checking the boxes they’ve already checked (at least the ones you and your customers value)
• Advancing long-term strategies - It’s easy to fall into the trap of incremental progress, so you should be sure that some efforts are going into the big picture goals that may on the horizon

Closing the Loop

More importantly, perhaps, than what ultimately makes it into the finished product, it’s your job to make sure each requester knows the fate of their suggested change. It’s one thing to tell a customer or internal executive, We evaluated your request and decided to prioritize some other things ahead of it because it wasn’t of interest to enough customers or we had more pressing work that addresses some customer pain points. It’s another thing to make the person who asked feel like they’re being ignored.So once you’ve made a decision about a request — either slotting it or putting it on the backburner —take a moment to let the person who asked for it know what happened. Customers may be a little grumpy that their requests aren’t being implemented, but they will at least feel heard and  won’t be operating under the false impression that it is being actively worked on. On the other hand, those customers who know their requests are now on the roadmap will be even more enthusiastic and loyal to your product.