For feature requests, a good format is to restate the customer’s description and then ask why he wants it. Restating the customer’s words ensures that you understand him correctly. It also softens the impact of the “why?” question, helping you sound curious rather than accusatory:

Response rates to this type of question are extremely high because the customer believes that answering will increase the odds of getting the desired feature. Rachel Pennig, Director of Customer Support for Recurly, explains, “We say to customers, ‘Tell us everything you need to be able to do, and we’re not always going to be able to say yes but we can pass it along and use your feedback to make informed decisions.’ I recently talked with a customer who wanted a way to create sixty thousand billing plans! By asking what he was trying to accomplish, I was able to come up with a reasonable solution using three plans.”

Figure 9-1. Customers tend to make suggestions rather than talk about the problems they’re facing, which adds a layer of abstraction that you need to push beyond

Functionality or interface complaints require a bit more deliberate politeness. At KISSmetrics, my guidelines for customer support included 4 As (apologize, admit, ask, appreciate).^[75] Apologizing for the customer’s bad experience and admitting blame sets the right tone for asking questions—you don’t want to inadvertently imply that the customer is at fault. An email reply might look like this:

What you can expect to learn from these responses are important details: who is affected by a problem, under what circumstances it occurs, how often it occurs, and how severe the problem is.

In many cases, interactions may have tested well in standard usability testing but don’t align with someone’s existing behavior patterns. For these types of problems, for every one complaint, there are often 10 more customers suffering in silence (or groaning in frustration) while they think about switching to a different product or service.

When a customer first comes to support with a bug report or error that needs fixing, customer development should not be top of mind. The first priority is to address the concern and resolve the customer’s issue. However, anyone who has worked in customer support knows that answering the question that your customer asked is not always the same as answering the question that your customer should have asked. Support professionals are probably already familiar with the art of gracefully transitioning from giving an answer and then asking an additional question:

Once you’ve provided an answer, you’ve got a captive audience, and you may as well use it!

Aside from phone and email support, many web-based products use live chat to answer questions for customers and sales leads. When a customer initiates a question, that’s a good opportunity to identify her pain point and ask some additional questions. You’ll have closer to 2 minutes than 20, but that’s still enough time to learn something.

Perhaps you don’t have a specific customer development question or a graceful way to fit one into the conversation.

Not all questions have to be specific to your customers’ experiences. There’s a lot of useful background research that you can answer from simple, survey-format questions.

The easiest way to do this is to pick a standard question each week on some topic that you’d like to learn more about. When I answered customer support emails for KISSmetrics, I often manually added a question to the bottom, which only took a few seconds:

If you use a support ticketing system, it should be easy to export and search for the answers to this question.

The best generic questions are ones with factual answers that are either numerical or answer who/what/how/when/why. It takes longer for the customer to write the answer to a subjective question, and those answers tend to be less useful if you’re not following up on them with more questions.

The people who initiate interactions with you are probably not a representative sample. The silent majority is an apt term for the bulk of your customers who neither complain nor compliment.

When I worked at Yodlee, support requests and posts to our customer forums were heavily skewed toward people with a high degree of technical literacy and financial domain knowledge. They were constantly seeking to push the limits of how our products could be used. At KISSmetrics, I split my time between absolute beginners and experts (who knew far more about web analytics than I did!). At Yammer, many of our support and feature requests are funneled through a community manager or project manager.

Luckily, there is probably consistency in the type of person who reaches out to you. Once you recognize the direction toward which feedback is biased, you can correct accordingly. When power users or proxy customers such as admins or managers offer feedback, it’s a good idea to investigate how many users it impacts. It’s not uncommon for power users to clamor for improvements to a feature that 90% of users have never even tried. When extremely low-tech or inexperienced customers offer feedback, it’s worth evaluating whether they are viable customers or whether their inexperience is too high a barrier to getting value from your product.

How you collect customer development notes from other people should depend on the tools that your company is already using. If it takes multiple clicks or written instructions to submit notes, people won’t take the time. What’s the easiest, most lightweight way for people to communicate currently? Here are some methods I’ve seen for getting people who talk to customers to give you customer development input themselves:

At KISSmetrics, I used the Google Form approach. I added the default recommended questions or prompts with a freeform text area for responses, and then added an extra Other question at the end. This allowed the interviewer to bookmark a link to the form, take notes directly into the form, and then quickly click Submit at the end. This approach had two big benefits: I didn’t have to nag my coworkers to get their notes, and it was easy to do a quick follow-up after their very first form submission to offer some light feedback or suggest a prompt or follow-up question for the next time.

However, what works best is what gets you the most useful information. In many organizations it may be more effective to just call your coworkers to find out what they learned. Customer-facing employees may be traveling and having face-to-face conversations instead of carrying a notebook or sitting in front of a computer, so all of their notes live in their heads.

Your goal is to make smart product decisions based on what you’ve learned about your customers’ problems and needs. When you do that, you need to share that explicitly back to your organization. Don’t assume that people will understand how customer development has had an impact! (Remember that people practicing customer development are focusing on problems; they may not recognize the solutions that you end up choosing as a result of those problems.)

When customer development saves time or money, helps avoid a mistake, or dramatically increases a customer’s satisfaction, that’s a win to be celebrated:

As you may remember from the Preface, the interviews I conducted in my first month at KISSmetrics allowed us to cut back our product development scope dramatically. We saved at least two months of development time as well as the ongoing cost of supporting overly complex code.

Here’s a more subtle way to state results:

Success stories like this fit well on a slide, but for maximum impact, don’t just share them in a meeting. Print out summaries like this on posters and stick them on the walls. At Yammer, we often have short summaries of customer learnings either taped to the wall or showing on the ambient TV displays in the office. That helps everyone—not just the people at one meeting—view customer development as part of the company’s culture.

Whether you share stories like this weekly, monthly, or randomly as you have a story to tell depends on the pace of your organization and how much input you’re getting. In a small startup, weekly feels right. In a larger organization, a weekly customer development success update may feel like overloading people’s inboxes.

At Yammer, our user research team shares updates at a monthly internal all-hands meeting. We also share our insights with the customers themselves once a quarter with our private community of enterprise Yammer customers, and sometimes even on our public-facing blog. We try to summarize information as “Here’s what we learned from you and here’s what we’ve done as a result.” Our customers don’t always agree with our solutions, but the transparency into how we learn and prioritize promotes great questions and challenges from them. In other words, talking about customer development is actually another way to practice customer development.