Imagine it’s a hot Thursday morning nearing the end of summer. You’re the customer support manager at a small-but-growing start-up. Things are pretty crazy where you work, but it’s getting better. A year ago, the engineering team would ship new features on a Friday afternoon, leading to a weekend spent monitoring the inbox for potential fires. Now they ship on Wednesdays so you have a chance to keep an eye on things during the work week. Progress.
You scan the support inbox to start your day. There seems to be one email related to the previous day’s deployment.
Subject: Can we have the old UI back?
There’s not much context, so you catch up on other emails first and intend to circle back later.
In one sense, summer was a slower season for product development. With so many people taking vacations, new features didn’t ship as regularly. But with summer interns finishing up projects, there’s been a big push to get their work out the door and in front of customers before the interns head back to school in the fall. That’s what made this past Wednesday’s deployment significant, when all of the feature work that had been building up from the summer went out at one time.
On paper, not much had changed in the app. Some new features solved for esoteric use cases, but they were buried in corners of the app that you would only find if you knew where to look. One change, however, was something everyone would see. It was a redesign of the home page of the app. Not a full redesign, mind you, but a tweak of some of the external design elements and a complete overhaul of the CSS styling under the hood. Functionally, everything was the same.
You open up your help desk and take another look at the inbox, where you notice two more emails asking to revert to the old UI. It’s not even 9 AM.
Should you raise the alarm and ask the product team to revert back?
The feature request canned response
A common exercise for a new support manager joining a start-up is to wrangle the support inbox and come up with canned responses—“saved replies”, “macros”, “snippets’, etc., depending on what your help desk calls them—that solve for common support scenarios. One of these scenarios is almost always feature requests.
When the engineering team is small and nimble, they probably love feature requests. People are excited about their product. Their app isn’t bloated (yet) and it’s easy to get features out the door. Shipping shows that they’re listening. And besides, it’s fun.
There will come a time where there are more feature requests coming in than engineering resources to implement them. Hopefully this is a good problem because it means you have more customers and revenue. This is where the feature request canned response comes in. You come up with the perfect copy to communicate to the customer that you’ve heard their request and that if enough people ask for the same feature, you’ll implement it.
Good, right?
No! Don’t do that!
“Tell me more about the pain…”
The feature request doesn’t matter. What matters is the pain behind the request. The customer’s pain is the thing that uniquely belongs to them. It’s also the thing you’ll miss if you just pay attention to the feature request.
Instead of:
Thanks for telling us about your interest in [feature]. If there are enough requests, we’ll be sure to add it to the app.
Do this:
Can you tell us a bit more about the pain that has you wanting [feature]?
You don’t have to use those exact words and you don’t necessarily have to do it over email. Maybe you say, “can you tell me more about the problem this would solve?”, or if the potential change is impactful enough, maybe you try to get them on a call.
Track pain, not features
It’s not your customer’s job to think of how to solve problems with your product. That’s your job. You have smart designers, engineers, and product managers who think about hard, challenging problems all day long. They work through difficult design decisions involving complex trade-offs to come up with optimal solutions. As a business, it’s your job to own the solution and the value you intend to deliver with that solution.
It is your customer’s job to share their pain and it’s your job to listen to their pain. Sometimes the way customers share their pain is by saying, “hey I have an idea for a feature” or “I don’t like the new UI—can you change it back???”. You have to do the work to discover the underlying pain.
The systems you create for funneling customer feedback to the product team will ultimately shape the value your team is able to bring to your customers. Do your systems track feature requests or do they track customer pain?
Understanding pain
If we return to the fictional example at the beginning of this post, we might question whether the inbound emails are a feature request or a sign of an operational fire where we need to revert to an older version of the product. Without additional context—and more importantly, without trying to understand the customer’s pain—we don’t really know. Should we be on alert? Yes. Should we stop everything and do what the customer is asking? No, or at least not until we better understand their pain.
Perhaps what changed is that the user interface broke for a specific user configuration, which got missed during testing. Or perhaps the change broke a popular chrome extension that was solving an unmet need for a large number of users.
You don’t know until you ask. And you don’t know how to solve the customer’s problem until you deeply understand their pain.