Turning feature requests into customer research

#12・
566

subscribers

67

issues

Subscribe to our newsletter

By subscribing, you agree with Revue’s Terms of Service and Privacy Policy and understand that Deploy Empathy will receive your email address.

Deploy Empathy
Deploy Empathy
This was written as part of the rough draft for Deploy Empathy, a practical guide to interviewing customers.
Like it? Order the book:
—————————————
I understand if the idea of customer research sounds like more work on top of what you’re already doing… maybe more work than you can take on.
So I want to talk about a situation you’re probably in frequently that is an easy jumping off point to deploying customer research skills.
It usually starts something like this:
“Hey, have you guys ever considered adding…”
or
“I was just wondering if you could make it so I could…”
or
“Can you add the ability to…”
Otherwise known as: feature requests.
Which, let’s face it, sometimes align with what we’re already planning to do, but often don’t. People are trying to be helpful…yet when we feel like we’ve already got more than enough to do and not nearly enough time, they may not be the most delightful thing to receive. It might feel like more work. Work that hasn’t been fully scoped out, thought through, and prioritized against existing work.
But… what if we could use those feature requests as a jumping-off point to learn more about the customers’ overall needs?
The purpose of this isn’t to convince you to be open to every feature request and change your roadmap every time you get one.
Far from it.
I want to open you to the idea that feature requests can be a welcome and crisp window into an acute problem for a customer. They’re aware they have a problem, though they are articulating it as a solution rather than a problem. We can then use customer research skills to dig into where that request is coming from and why it would help their process, which we can then use to build out our own understanding of what they’re trying to do.
My point here is to take feature requests from something that might be met with a groan into something that inspires curiosity and leaves you understanding your customers better. That maybe, even a little, leaves you excited about learning something new and more motivated – even if you don’t build what they asked or in the exact way they asked for it.
That’s why it’s important that we stop our brains from jumping to whether a specific feature would be possible or how we might implement it or issues with how the customer (or leader or coworker, if we’re in a larger company) has presented the solution.
That train running off to how this would never work?
Pump the brakes.
Time to instead dig into where that request is coming from in the first place, what the underlying problem is, and see what we can learn.
Here’s how you can do that.
Feature Request Response Template: Phone
If you happen to receive one on the phone – say, on a support call, sales call, or in an interview, here are some questions you can use:
  1. Can you walk me through the context on when you might use this?
  2. What made this need come about?
  3. What do you currently use for this?
  4. Do you pay anything for those other tools? Is there anything else those other tools are used for?
  5. What other tools / steps have you tried for getting this done?
  6. What are the different steps involved?
  7. Can you show me what you do now? (ask for screenshare)
  8. How much time does this currently take you?
  9. Is there anyone else who is involved?
By the way, for those of you in larger companies, these questions will work just as well with internal customers who bring feature requests. Just remember to ask them in your most harmless voice possible, lest it come off like you’re challenging them. (I learned that one the hard way.)
Feature Request Response Template: Email
If the request comes in over email/Twitter/GitHub, here is a template for responding.
I try not to ask more than two questions in these emails, otherwise the response rate tends to plummet. (Though it may be tempting, our goal is not to ask so many questions that people give up.)
Hi [Person],
Thank you for making this suggestion! Would you be able to tell me more about the context in which you would use this and what it would help you [figure out/do]?
or
Hi [Person],
Thank you for making this suggestion! Would you be able to tell me how this would fit into your broader process? I’m interested to know how you currently solve this, even if it’s manual or uses other tools.
The key here is to use words that elicit the big-picture explanation – words like:
  • context
  • background
  • broader goal/process
  • big picture
What do we do with this information?
There’s a lot we can do with these learnings. I’m going to touch on two here.
Before we talk about what we do with it: when we’ve gotten a response from someone, I always like to thank them again for sharing the suggestion. They took the time to send a message about this, so clearly it’s important to them and they thought it was a good idea. That deserves acknowledgement, even if it isn’t something that fits onto a roadmap or company vision.
The one thing we always do is add whatever we have learned to our bank of customer understanding. We might make those deposits formally into some sort of system, or we could take notes on them in the customer’s account or email them to ourselves, share them with a teammate or friend from a mastermind, or we simply make a mental note.
The second only applies if it is something that is directionally aligned, even if not immediate. I always save the idea and tag the customer, and keep a running list of ideas with each customer that requested it. I tell customers we’re saving their idea, and will reach out if/when we add it. (The “if” is key there.)
If we have a bunch of customers speaking to the same process and general idea for a long time, we’ll try to make those features happen. Those saved lists are helpful for reaching back out for more context or people who can help us refine/scope a feature and test it if we decide to move forward.
At a minimum, if we do add a requested feature, we then reach back out to everyone who requested it or mentioned a related use case. Sometimes that means emailing someone who made a feature request a month, six months, two years, even five years ago. I used to feel a bit worried about emailing people with such a long delay, but I’ve found that people are utterly delighted that we remembered and made it happen, even if it’s years later. I have been floored with how appreciative people have been.
I like to think it’s moments like that when you seal the trust you build by listening to your customers: you listen in the moment when the pain is acute, and you show that you listened by returning to them months or years later.
We might be business people, but the operative word there is people. All people like to feel valued, appreciated, and helpful. And being appreciative and curious when someone comes to you with a request is just a small way you can go beyond being another faceless business and to an empathetic one that truly cares about the people it serves.

Did you enjoy this issue? Yes No
Deploy Empathy
Deploy Empathy @mjwhansen

A practical guide to interviewing customers

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Created with Revue by Twitter.
440 Monticello Ave, Suite 1802 #43146, Norfolk VA 23510