Why is it important to effectively mediate product requests from CS to the Product team?

Feature requests are a vehicle to product-market fit. If you can’t handle feature requests, you may struggle to achieve long term product-market fit – early-stage companies choose a specific initial customer with very narrow requirements. To achieve product-market fit, which requires meeting ideal customer needs at scale, you must be able to adapt to feedback from customers with broader requirements. 

Key financial metrics depend on your ability to bridge the gap between the customer and the company – as the face of the company to the customer, CS is often responsible for helping stretch fit customers find success. Expansion, retention, upsell rates, and customer advocacy KPIs suffer when you can’t make your solution work for customers. 

Feature requests make buying decisions easier – most customers buy products with “unknown unknowns” or incorrect assumptions about the product itself. Feature requests are a tool that enables CS to save at-risk accounts, especially during the early stages of the customer lifecycle.

Poorly-handled requests cause stress, disruption, and unnecessary cost – demanding customers can be prone to escalation and likely to churn or request a refund. Teams with a rigorous product request mediation processes limit the emotional, fiscal, and bandwidth impact of serving hard-to-please customers.

What are common indicators that you need to improve this process?

Poorly-handled product requests signal an unoptimized customer journey, both internally and externally – while this suboptimal experience can manifest in myriad ways, there are multiple common indicators:

• Backlogged engineering – if engineering is backlogged by product requests (not internal product development priorities), too many requests are coming through and/or there is a problem with the product.
• Backlogged CS – if every customer is treated as unique, you lack standardized, repeatable processes to resolve customer issues. Product requests should not be the default way to solve customer problems.
• Low retention or referrals – if customers have a negative experience and aren’t getting their feature demands met, they’re more likely to leave and less likely to recommend your product to others. 
• Low usage expansion – if customers aren’t launching, adopting, and/or increasing their usage in line with your expectations, there might be a feature roadblock preventing them from deriving the expected value from your product.
• High volume of escalations – if customers are continually moving the goal posts and insisting on custom features, your team lacks the proactive processes that should prevent this from happening a majority of the time. 

Intake

What are common touchpoints where CS receives product requests? 

Early stage onboarding triggers the highest risk requests – Customers are the most demanding at this stage. It’s difficult to get customers to relinquish the expectations they had from the sales process or from their experience with their previous solution. Customers perceive change as limitations and requirements of your solution. At this stage, customers are likely to return to their prior product if your solution seems to be more trouble than it’s worth as switching costs are lower to stay on the current system versus switch. 

QBRs and regular customer interactions frequently lead to requests – any regularly scheduled check in is an opportunity for customers to voice concerns and requests. However, if you can anticipate requests before they’re voiced, you have a better chance of setting expectations for the conversation.

Critical milestones for mature customers (e.g. renewals) can entail high-risk requests – customers might threaten to leave if you don’t handle their feature request, especially if renewal prices are increasing. 

How can CS proactively solicit feature requests?

Internally source feature requests before they’re voiced by the customer – work with Sales to anticipate demands for each customer. Then, come to customer meetings armed with proactive solutions that have worked for other customers who experienced similar challenges. 

Conduct trend analysis to identify critical feature requests at scale – conversational AI tools can review sales calls and indicate which feature requests are most likely to block deal closure, block implementation, or not factor into conversion at all. Discuss these findings with Product to determine whether solutions for any common blockers should be included in the product roadmap. 

Initiate a conversation that invites feedback, not demands – set expectations as early as possible that you welcome feedback and appreciate hearing your customer’s ideas. Make it clear that feedback enables you to set your customer up for success; it doesn’t necessarily mean that you will commit to building out new features. 

Sample opening talk track to set feedback/request expectations:

“As you’re changing software, I wanted to set expectations. There will be kinks in the road. This transition period will be challenging, but it will be worth it. Those kinks will come in the form of 3 things: training issues, bugs, and feature requests.  The majority of the issues you’re going to have are in the training and adoption category. Those are easily surmountable. Bugs are rare, and we fix them with lightning speed. We prioritize giving you the product that you bought. The third category is feature requests. We love feedback. We love ideas. However, we can’t make any promises that feature requests will be delivered on any particular time frame, if ever. Please feel free to share feedback. You have my commitment to advocating for you–and, in kind, I ask for your commitment to move forward with the product as purchased.”

What are the 3 eventual outcomes after a customer makes a feature request?

Outcome	Potential benefits	Potential risks
Company delivers on the request	• Customer renews • Usage expands • Better PMF achieved	• High investment  • Sets precedent with customer
Company decides not to handle the request	• Company saves on internal resources • Product roadmap not derailed	• Customer walks away/ doesn’t renew • Customer asks for a refund
Company strings customer along	• Customer forgets about request and renews • Company eventually has time to accommodate the request in the future	• Customer doesn’t forget and becomes irritated/ churns

How do you gauge the risk that a customer will leave if you don’t implement their feature request? 

Determine the level of need – you will never have all the information you need to fully assess a customer’s likelihood to churn, but you can estimate risk by understanding how the customer will be impacted if you don’t implement the feature.

Sample talk track to gauge severity of customer need:

“You have my commitment to advocating for you, and I’m going to see what we can do. In a world where the worst case scenario happens–if we can’t get this across the finish line in any particular time frame–what does that mean for you?  From my view, the overall benefits and values of our software are so overwhelmingly positive that it still makes sense to proceed forward, and you’ll see that in time like the rest of our customers. You’ll see that this is just a small part of a big picture, and that there are plenty of alternatives.  If you bear with me, the positives will far outweigh the negatives, but that’s my perspective. I want to hear yours. What does it mean for you if we’re not able to deliver on this?”

How should CS capture product requests? Which tools facilitate the feature request process?

Use a pain-centric template (see below) to capture key needs – ask the customer to fill out the template, then collect any additional details that will help Product understand the nature of the customer’s pain point. 

Additional tools that support the feature request process
Category	Example	Useful capabilities
Conversational AI	Spiky.ai , truco,ai	Sentiment identification – helps determine which customer requests are demands vs ideas, and which requests are most prone to escalation
Feature request ticketing system	Pendo	Public publishing – mature companies can see whether customers upvote or downvote potential new features. However, this is too risky for early stage companies.
Session playback software	LogRocket, Fullstory	Gauging usage sentiment – track hammer clicks (also known as rage clicks) to see when customers get frustrated by certain elements of your product.
Uptime monitoring	Datadog, PagerDuty

Managing Expectations

What is the 10 step formula for dealing with feature requests? 

Step	Example
1. Challenge yourself to show curiosity and not defensiveness	Interesting!
2. Express gratitude as part of your growth narrative	Thank you. That makes sense to me because… feedback like this is what helps us grow.
3. Prove you understand; reflect back what you hear and even dramatize it	If I’my hearing you correctly, you want the ability to [have different logos by branch], right? And you want to do that because…
4. Catch all use cases  Makes customers feel heard Reduces the chance we build incorrectly	That makes a lot of sense to me. Let’s talk about the use cases.
5. Inform them of the truth. (They don’t know your role) I owe it to you to let you know, our product roadmap is set Feature requests take time to get right	I owe it to you to let you know, our product roadmap is set and feature requests take time to get right.
6. Provide real alternatives  Avoid “workarounds”	I want to deliver the value from the product you purchased. I have some ideas that work for our other customers. For example…
7. Outweigh the feature with the need to move forward Consider the BATNA Consider a concessions playbook	I’ll be better at getting this across the line if you help me prioritize/access whether this is a go/no-go item from you.
8. Convey next steps	I can bring this up during our quarterly product review. You have my commitment to advocate for you so long as I have your commitment to move forward.
9. Do not promise a timeline	I can’t make any promises on if or whether this will be completed.
10. Let them know we’ll reach out when we have updates, but ask for more info (this should be release notes)	But I’ll follow up if I get more information. Your case number is #12345  (Don’t call me; I’ll call you)

Notes on steps:

• Step 4 is a valuable opportunity to set expectations – in addition to making customers feel heard and confirming that you understand all use cases, this step forces the customer to realize how much work the feature request will create for your team. 
• Don’t feel guilty about discussing alternatives in Step 6 – product development can be likened to the Henry Ford analogy: if you asked people what they wanted, they would’ve asked for a faster horse. Alternatives can be better solutions than feature requests in some situations.

How should CS respond to product requests when it’s likely that the team will develop the functionality?

Aim to underpromise and overdeliver – while it is tempting to people-please and share the most positive updates possible, you must set expectations that will provide the best overall experience for both the company and the customer. 

DO:

• Build in a buffer – give yourself an extra quarter (beyond the internal timeline). 
• Sell them on alternatives – help customers see the existing solutions that could solve their issues while the feature is in development. This also mitigates the risk that delays could pose to customer satisfaction.
• Lean on a concessions playbook – you should have a playbook that gives CS or AM discretion to tack free months onto the contract so customers aren’t billed for the interim time. The playbook should include a talk track for handling refund requests. 

DON’T: 

• Guarantee anything – never promise that a specific feature will be built–or that it will be implemented at a certain time. 
• Commit to features or functionality – commit to value instead. Commit to providing a solution that will do X for the customer, not to providing a specific feature. 

How should CS respond when they won’t develop it? How do you handle rebuttals?

Respond with empathy and prepare for rebuttals – customers never like to hear that their request won’t be implemented, so CS must be prepared to deliver honest information and receive a potentially strong customer reaction.

DO:

• Size the customer risk – have the necessary, uncomfortable conversation where you explain that the future roadmap is already set for the next [LONG TIME PERIOD], and that you are genuinely doubtful that you would be able to make this accommodation. Then ask the customer what it means for them.
• Escalate – bring your CRO, CTO, or CEO up to speed on the situation so they can determine whether the company is willing to walk away from the deal over a feature request. Often, leaders will create a contingency plan in which you push back with the customer but can make an exception if they threaten to terminate.

DON’T:

• Alienate the customer – don’t tell them that they’re the only customer who has this need. If they don’t feel like you care about them as a customer, they might decide that you’re not the right product.

How should you respond if the customer gets impatient with the development process? How should you respond if the customer escalates?

Deescalation is about staying calm – your goal is to retain the customer, not to feel like you’ve won an argument or made someone feel happy. In order to effectively deescalate the customer, you must first deescalate yourself, then employ the Feel-Felt-Found methodology.

Step	Example Script	Tips
Feel – show the customer that you understand what they’re feeling.	“I totally see where you’re coming from. It makes sense to me that you care about XYZ not being missed. Really, it’s a testament to how much you care about your business and the timeliness of your business.”	Amplifying the customer’s need shows that you understand their pain and makes them feel validated.
Felt – demonstrate that you’ve worked with customers who have felt this way before.	“I’ve heard this before. I’ve dealt with people who felt this way before. I myself would feel this way if I were in your shoes.  Do you mind if I share what I’ve found that is a great way to XYZ?”	Don’t forget to ask permission to share what you’ve found.
Found – explain what those customers found to be helpful in this situation.	“What I’ve seen before is that our other customers sort XYZ by ABC. It’s actually kind of interesting, because we’ve found that when they take this approach, we get higher [KEY METRIC] and the same outcome–or more successful outcomes–when you use the ABC approach.”	Don’t make the customer feel like their request is “wrong”; help them see that the alternative adds value.

Communication to Product

How should you submit feature requests to Product? 

Include as much context as possible – your goal is to give Product all the information they need–and to err on the side of providing more context than necessary. Explain what you are trying to accomplish, why current systems fails to accomplish that, what use cases are relevant, what alternatives have been tried, and why those alternatives failed. Share call recordings when possible.

Enable controlled contact between Product and the customer – schedule a meeting to allow Product to speak directly with the customer to better understand their situation. However, make it clear that Product is not the customer’s main point of contact.

Never make feature demands – act as the voice of the customer and share their pain point with Product. Product needs to understand the story behind the customer’s problem in order to identify potential solutions, but the best solution isn’t necessarily to implement the feature the customer requested. 

How do you determine if a feature request should be prioritized when presented to Product? How do you convey priority to product?

Distinguish between severity and priority – an issue can have high severity for a customer but moderate priority for the business. Use the Support Priority Key to determine how to handle different kinds of feature requests.

Overall

How can you capture better customer feedback on the product? How can CS improve their contributions to the product roadmap? 

Treat CS as the voice of the customer – CS should be involved in all VOC programs. While CS is directly involved with ad-hoc customer requests, CS professionals are doing themselves a disservice if they aren’t proactively trying to understand trends and patterns around customer satisfaction. 

Create a customer advisory board – offer customers a seat on the customer advisory board to A) ensure that you’re getting input from key customer demographics and B) appease strategically important customers whose requests cannot be implemented in the foreseeable future. 

Hold regular CS-Product meetings – reserve time each month to share regular updates, discuss high-urgency trends or issues, and share feedback. Effective CS-Product meetings:

• Increase cross-functional collaboration with the goal of reducing churn
• Increase visibility to Product and leadership around the voice of the customer
• Improve employee satisfaction by removing mutual roadblocks

What are the most important things to get right? 

Use psychology to reinforce a positive perception of your product – showing appreciation for the customer can reduce the anger behind pain point-driven requests and make it easier to have a productive conversation. Furthermore, using customer feedback to contextualize your company’s growth (e.g., “I really appreciate that you shared this. Our dedication to customer feedback is one of the reasons we’re the fastest growing X provider.”) reinforces your product’s value.

Vocabulary is important during stressful conversations – certain terms can trigger escalation in a customer and derail your conversation. Specifically:

• Don’t say “workaround” – say “alternative” (e.g., “May I suggest an alternative that worked for several other customers?”). 
• Don’t say “but” – say “and” or “so” (e.g., “I cannot guarantee that we can fit this request into our roadmap in the next year, so when I’ve seen this before, I found that our customers who pursue ABC alternative see X result.”).

What are common pitfalls?

Don’t make decisions in a silo – CS is the face of the customer to the company and the face of the company to the customer, but they should not decide which feature requests get implemented. Because feature requests can have significant short and long term strategic impacts, all relevant parties and leaders should be aware of what is at stake when feature requests come through.