Tag Archives: interviews

Know Thy Customer

© 2010 Esther Derby

Understanding the market and your customers (and potential customers) is the first step in building products that will sell and keep the business in business. You need to know enough about both so that you can plan your product investments and know which features to deliver when.

If you aren’t sure what your customers think about your current products, it’s time to find out. This doesn’t mean you have to launch a huge market research or competitive intelligence effort. You can begin by reviewing customer support data, interviews, and watching your customers use your products.  These simple acts of analysis, listening, and observation will reveal how your customers currently use your product, which features need improvement, and identify unmet needs.

Read about Your Customers’ Experience

If you have any sort of technical support line, you already have information about how your customers experience your software.

If your support calls are in a data base that doesn’t allow you to sort, slice, and dice the data, move it to one that can.  But don’t make it such a big project that it gets in the way of learning about your customer’s experience.  You can always take a sample, start with one product, or look one months worth of calls as a starting point.

The first step is a rough sort by feature or module.  Is there an area of the software the generates more calls than other areas?  Start there to understand the pattern and content of the calls. Look at your sample as a time series.  Is there any pattern in when the calls occur or spikes in the number of calls? Investigate.

Put yourself in the customers shoes, and try to see the issue from a customers point of view.  The data from support calls may have information on how problems affected the customer, but that information is filtered by the questions the support person asks and the from used to capture data. You need that information pure, straight from the customer. Follow up with customers who have called support recently to learn about the disruption or irritation they suffered.

Talk to Your Customer

Interview a sampling of customers, a dozen or so. You may choose a representative sample, or focus on people who have reported problems or called technical support.  Design a short interview—no more than 45 minutes.  After all the interviews, analyze the data. Look for themes related to difficult to use features or missing features.  Both will give you clues on where to focus future efforts.

I think it’s important for all people involved in building software to get to know their customers.  However, some managers worry that developers lack the social skills and polish to speak with customers.  It does take skill to interview customers, so give everyone a crash course on the three iron rules of customer interviews:

1) Never argue with the customer.  Even if you disagree with your customers assessment, do not argue the point.  If you win you lose because the customer will feel discounted. If you lose you lose because you’ve shown you don’t understand your own software.  In both cases, you’ve damaged the relationship with the customer and destroyed a chance to learn.

2) Don’t turn the meeting into a training session. If the customer is using the software incorrectly, take that as information about the product, training materials, or support.  At the end of the interview, offer to arrange a follow up call for training.  If you start instructing during the interview, you’ll miss out on learning from the customer.

3) The interviewee should talk more than the interviewer.  My rule of thumb is that the interviewer should talk no more than 30% of the time and spend at least 70% of his time listening to what the customer has to say. This is impossible if the interviewer relies on closed questions, which can be answered with yes or no.  Open-ended questions and probing questions invite the customer to provide deeper answers and reveal more about his experience with the software. (For more on how to interview your customers, see Building a Requirements Foundation with Customer Interviews, insights Vol. 2 No. 1.)

Observe Your Customer

Visit your customers and observe them in their context.  Watch them using the most common use features, those that the find easiest to use and those that they find difficult.  Take notes, and take pictures. User Experience expert Jared Spool advises that people should invest time every few weeks observing customers use the software. You say you can’t visit?  What about skype or video conference? Webcams are cheap and getting better every day. There’s really no excuse.

As you go about learning how your customers experience you product, notice how easy or how difficult it is to talk to your customer.  One client of mine had to go through multiple levels of approval in order to make a follow up call to a customer. Unless you work in an industry with high security or secrecy, it’s a big red flag if you can’t gain access to your customers. It signals that the customer’s point of view is distant, diluted, or discounted by the people who manage software development. How can you satisfy your customers when the people who build the software are prevented from getting to know them?

When everyone involved in writing software knows the customer, benefits abound.  People understand the customer’s context and concerns. They may find out that the feature they thought was wonderful is unwieldy. They’ll see the pain of duplicate data entry, foot-long drop down lists, and navigation that feels like searching for a needle in a hay-stack.  Feedback is critical for improved performance.

Are you getting the feedback you need to build great products?


If you would like to learn more about how your customers experience your software, my Customer Interviews workshop will give you the skills to prepare for and conduct effective interviews.

Interview with Jerry Weinberg

An interesting interview with Jerry Weinberg here, at the Citerus site.

Some excerpts:

Q: You must have seen a whole bunch of ideas, about how to best do software development, grow and die over all those years. Do you see the agile movement as a pendulum swing or is it a move in a new direction?

A: How about a pendulum swing in a new direction? It’s a pendulum swing because approximately every decade, there’s a fresh movement to “solve the programming problem.” High-level languages, structured programming, object-oriented programming, …

But it’s a new direction because it’s the first movement to focus largely on social processes rather than purely intellectual ones. For that reason, I believe, it has more hope for success than the earlier movements, each of which made a little progress, then largely ran out of steam before achieving its grand promises.

Of course, agile won’t achieve all its grandest promises either, given the conservative nature of human beings, but that’s all right. After another dozen decades or so of incremental improvement, we’ll begin to see some really fine software development. Well, I shouldn’t say “we,” because none of us will see them, but at least our great-great-grandchildren will be able to look back at us and laugh at our crude methods.

Q: If you’re the J.K Rowling of software development, who’s Harry P then?A: Well, first of all, I’m not a billionaire, so it’s probably not correct to say I’m the J.K. Rowling of software development. But if I were, I suspect my Harry Potter would be a test manager, expected to do magic but discounted by software developers because “he’s only a tester.” As for Voldemort, I think he’s any project manager who can’t say “no” or hear with Harry is telling him.