The Black Hole of Enhancement Requests

Many thanks to David Hulbert for suggesting this topic. (You can suggest a topic too, just send me a note.)

What’s the problem?

Customers often make suggestions for product enhancements, large and small. Most organizations have a system to record such requests, but once recorded, the requests typically sit there, sometimes entirely untouched and certainly not acted upon, until some escalation pushes one forward. Customers feel, justifiably so, that there is a special black hole where enhancement requests go to die.

Beside customers, members of customer-facing organizations have their own frustrations having to justify to customers that their requests are not implemented–and they may see their own requests being ignored.

Why is it a hard problem to solve?

• Bandwidth. Enhancement requests need to be adjudicated by the Product team, which is also trying to keep up with market trends, add major functionality to existing products, and develop entirely new products. It’s a busy bunch of people!
• Process. The Product team is not set up as a customer interface team. It doesn’t have the discipline of having to meet SLAs and it doesn’t have a process for turning around requests in the first place.
• Quality. Enhancement requests, especially those coming from customers, are often meant to address a narrow use case that would not be generally applicable to large numbers of customers.
• Impact. “Simple” requests may not be so simple to implement, as they may require architectural changes that are not visible to the naive observer.

What can you do about it?

These recommendations apply to Success and Support managers, but don’t hesitate to share them with your counterparts in the Product team.

• Create better requests. If support engineers, CSMs, or application engineers log enhancement requests, there’s an opportunity to craft requests of higher quality. Train them to document the underlying use cases (not just the desired product changes) and to capture the business value of the requests (not just the technical requirements). Provide a structured template to facilitate reviewing the request in the future.
• Track transparently. It goes without saying that enhancement requests must be tracked as carefully as cases or bugs. Open the repository to customers so they can see the progress of their requests. (They will also see the lack of progress, which may prod relevant parties to hustle up!)
• Implement a quick review process. There’s nothing worse than a request that sits there for months only to be summarily dismissed during an infrequent mass review. Instead, ask product managers to quickly identify requests that won’t fly (and close them out). Weekly or bimonthly reviews are ideal.
• Group and structure requests. In parallel to the quick reviews, have a methodology to bundle similar requests in logical groups. This is especially important if customers log requests independently and may not achieve great quality in their requests.
• Use AI to manage the volume. The awesome capabilities of AI can be deployed on massive numbers of enhancement requests to quickly categorize them, consolidate them, and summarize them. Cut down on the volume that requires human scrutiny.
• Use voting and prioritization. You can allow customers to upvote individual requests or you can ask for votes on the consolidated requests (the latter is more productive, in my mind). You can take customer size into account as you tally the votes.
  Allow internal organizations to weigh in, too. If the support team is getting scads of cases that would all go away if a particular enhancement was available, that’s worth a lot.
• Report on successes. With each release, list the customer-requested features that were implemented in it and, ideally, message the customers who have requested or upvoted them. Customers may not always get what they want, but they will see that many customer requests are, in fact, granted.

What are you doing to manage enhancement requests? What has worked (or not) for you?