How do you all manage/handle feature requests?

Hi everyone! This is my first question/discuss I create, so I'm very excited! ? I started my Customer Success Manager journey 3 months ago at a small startup and I'm loving it!!!

I'm finding that managing feature requests from my accounts is way different than during implementation projects, as they have a specific end date. I would love to hear different ways to deal with repeated feature requests conversations with customers, how do you track them and at what point it is proper to push more for them to be prioritized in the roadmap, mostly when the product/engineering teams have different priorities (new product rolling our soon, so that's the main priority).

I want to balance voicing the customer's needs/nice-to-have items and the resources/internal priorities.

Any ideas, experiences or suggestions would be appreciated! ? Thank you!!!

Find more posts tagged with

Retention

CS Team

Comments

Will Stamatis

Great strategies mentioned above-here are some examples of what they look like in the wild:

Sample Product Feedback Board
This is for an EdTech company that's like Powerpoint on steroids for schools (disclaimer: I used to work there). It's a public-facing board that allows users to post feature requests, upvote others and even see where each feature sits in the product roadmap (note statuses like Under Review ). You could also have an internal page for employees only that helps the team discuss and prioritize features without revealing everything to competitors. Canny is just one of many solutions, and hopefully seeing a visual/real example anchors the above suggestions.

User Stories by Atlassian
Great starter if you've never worked in Product. But to talk through an example:

Let's say you're a CSM for a company like Intelycare, effectively Uber for nurses. Disclaimer: I've never used the product, I'm just imaging potential feature gaps/use cases. Let's imagine that as it's currently built out, you can't issue a multi-day request for a nurse with different starting and end times on each day.

As CSMs, our knee-jerk reaction is to articulate this precisely:

Hey Product, can we get different start and end times on multi-day requests?

To Andrew (and others') points, reframing that in the user story is more impactful for the average Product Manager. In this case, that might be something like:

Hey Product, our staff coordinators are looking to plan their teams' absences in advance so that they're not scrambling to fill positions last-minute.

In a way, you're reverse-engineering the question so that a 5 Whys approach leads people to that feature. In this case, e.g., a Product Manager might think Why can't our staff coordinators plan their team's absences in advance? Oh, multi-day requests might not always have the same start and end times...

The latter example is a little contrived, but I hope that clarifies what the process might look like in the real world.

Happy advocating!

Doug Havlik

I can only answer for my experience at ThoughtTrace. We have had Pendo for at least a couple of years, but this feedback functionality only came out last year. We are currently around 60 total company employees, a little shy of 10 million ARR and 100 customers. Hopefully, that gives you some sense of our start-up stage

Ashton Liu

I think there are some great comments in the thread on building the business case for an enhancement/feature request.

For me (and for many orgs) this becomes harder to track as you grow and scale. From the CSM's perspective, let's say that you do all the due diligence before sharing this with Product. Then when the customer asks about it 6 months later, you're scrambling to find an update only to deliver the news that it's nowhere on the roadmap. These are not fun conversations to have ("you mean to say I told you about this months ago but nothing's been done?"). From Product's perspective, they're constantly inundated with requests from sales, engineering, CS, etc. while trying to manage resources to deliver on the roadmap. You get to a point where it's impossible to manage in email. Similar to what Doug mentioned in his comment, my company started using a portal where users can enter, vote, and comment on feature requests. This removes the CSM as the middleman (although let's face it we'll always be involved), while putting the onus on the user to put together the business case, and on Product to review and prioritize. It also gives the Product team much better visibility into customer feedback because now you can report on the data and quantify votes. It doesn't solve the fact that most requests simply will not be built, but that is the reality of what we do and users can now see the volume of requests for themselves. I mention this not to say that that you should choose one system over another, but that as your organization grows you will need to develop a process to handle this. This is probably a conversation between CS, Prod and any other stakeholders because it does need to provide value for everyone. It should give transparency to end users and should give internal stakeholders the information they need to make decisions. And this is certainly not going to solve every problem. Per Mark's comment, there needs to be transparency and accountability about the product roadmap, but the hope is that this makes our lives in CS a bit easier.

Mark Flanagan

Here is a different take on this based on my own experience.

CSMs shouldn't be lobbying for specific features at all. A company - even a startup/early-stage company - should have an escalation process in place that quickly lets the CSM know the status of their customer's issue or request.

If the issue being reported is a bug or is determined to be a critical enhancement, then it should be immediately acknowledged by the Product organization so that the CSM can let the customer know that it is being diagnosed/evaluated and that information will be made available shortly about how long it will take to address it. Then, the CSM needs to keep the customer informed in a timely way as the work proceeds to address it.

If it is a request for a new feature, then the Product organization should 1) let the CSM know that it will be added to the Product Roadmap and in what timeframe it is expected to be added to the product... and the CSM can then keep the customer informed of its status as time passes; or, 2) that the request is important but is not currently a top priority... but the customer will be informed immediately if/when that changes; and finally, 3) there are the those that fall into the "thanks for the feedback but the request doesn't currently fit into our product plans".

On one side, you need to be willing to listen to your customers and their needs, but at the same time, probe deeper into what they are asking and why they are asking for it. In my experience, I've found that applying techniques like 5-Why's to dig deeper into customer asks, tends to reveal objectives they are trying to accomplish that either the product can already do (just not the way the customer wants/expects it to), or the customer is misguided on what the product can/should be doing.
When you're making the case for an actual feature request to your product team, you need to go beyond just asking for the feature. You should be explaining the ask within the context of a business use case. Tell a story. Help those that need to listen to better understand why the ask is important to the customer and how it will impact their ability to achieve their desired outcomes.
You should also be attaching the potential revenue impact of adopting such a feature, not just with this customer, but with other company customers. You're trying to make a case to either add a feature, or move something up in the product roadmap. Product has a prioritization challenge every day. The best way to make your case (beyond telling a story) is to attach the revenue impact, either loss of revenue from a customer churn because the feature is critical to their ops, or the potential upswell revenue because you're increasing your TAM (total addressable market) by offering something even richer in functionality for the entire customer base, or potentially opening doors to new customers or verticals.

A few thoughts for you.

Good luck!

Andrew Marks

That's a tougher one. It depends on what that product launch was geared towards. If it's something that is going to benefit the larger customer population, well, you just need to accept that sometimes. If it is a new product launch designed to go after new customers, I think it's bad business to de-prioritize the needs of your existing customers for new ones.

Edgar Cholewa-Cardona

Hi Harsh,

Thanks for replying and I love the checklist idea. This could a checklist used by all CSM in our team.

Edgar Cholewa-Cardona

Hi Doug! Love Pendo, I've used it before, but more for notifications. I've seen the product feedback as a user, but I have never set it up. Awesome suggestions!
In which start-up stage have you seen this being implemented more often?

Edgar Cholewa-Cardona

Thank you so much Andrew! These items definitely help a lot. I'll follow the 5-why's starting immediately and I'll let you know how it goes. ?

When creating a business case for a request that is already on the roadmap and was supposed to be completed a while ago, but was deprioritized due to a new product launch, are there any additional suggestions?

Harsh Shah

Hi Edgar,

Welcome to this wonderful community and best wishes for your CSM journey!

I'm gonna share my thoughts on this query as I have faced similar challenges in the past and it really worked for me. So, I hope some of it might be useful for your scenario as well.

There might be various reasons of requesting new features/enhancements by customers like Comparing features of competitions, Better UI-UX, Bugs, and more. I generally use below checklist to identify the request type and accordingly plan the next steps:

Understanding the feature requirement and the problem which they wanted to address
Check if we already have a similar feature that can be readily used or need minor enhancement
Check if we already have done similar Customization or Enhancement for any other client
Is the requested feature already in our future roadmap?
If not, then do any other customers have also requested a similar feature in past?
Can this particular feature provide any additional value or solve a major problem in the default product?
Can it be useful for the general audience?
What might be the efforts required to build it?
What's the priority of this particular feature?

After verifying the request with the above points, most of the time I get an exact idea if any feature request should be included in the product's roadmap or not. Because with all this information you would be able to pitch any new feature/enhancement request to your product development team by showing its value/impact and they can add in their backlog based on their priorities.

Let me know if this could be useful for your case.

Have a splendid day ahead.

Doug Havlik

Edgar,

On a very tactical level: we use the Pendo Feedback product, which allows the customer to submit requests themselves, rank all the requests by priority, add comments to the requests of others, and see the current status of their requests.

Andrew Marks

Welcome to the community and profession Edgar.

Your challenge is a familiar one, shared by CSM's all over. There isn't a quick answer to this so I am going to rattle off some thoughts for you to consider:

On one side, you need to be willing to listen to your customers and their needs, but at the same time, probe deeper into what they are asking and why they are asking for it. In my experience, I've found that applying techniques like 5-Why's to dig deeper into customer asks, tends to reveal objectives they are trying to accomplish that either the product can already do (just not the way the customer wants/expects it to), or the customer is misguided on what the product can/should be doing.
When you're making the case for an actual feature request to your product team, you need to go beyond just asking for the feature. You should be explaining the ask within the context of a business use case. Tell a story. Help those that need to listen to better understand why the ask is important to the customer and how it will impact their ability to achieve their desired outcomes.
You should also be attaching the potential revenue impact of adopting such a feature, not just with this customer, but with other company customers. You're trying to make a case to either add a feature, or move something up in the product roadmap. Product has a prioritization challenge every day. The best way to make your case (beyond telling a story) is to attach the revenue impact, either loss of revenue from a customer churn because the feature is critical to their ops, or the potential upswell revenue because you're increasing your TAM (total addressable market) by offering something even richer in functionality for the entire customer base, or potentially opening doors to new customers or verticals.

A few thoughts for you.

Good luck!