Most software products are developed for “real people” not software developers. Sometimes those of use that are creating software every day, using technology in every aspect of our lives and are savvy computer users sometimes forget that our customers don’t have the same skills and thought processes.
Examples where we forget that real people are using our products:
- Technical knowledge about the operating system: We may think it necessary to “run as administrator” to install an update. Most customers don’t what this means or how to change their access levels.
- UI short cuts: We use the context (right-click) menu every day, but most customers don’t.
- Better browsers: Awareness of Firefox and Chrome are on the rise, but many customers still use the default browser that came with their OS.
A few of these examples are not likely to be specified by the product marketing team. To build software that is usable by your customers, its important for the developers and quality team to understand the customer. They need to have empathy with their customers to fill in the gaps between written requirements.
These are a few practices that have proven useful for building empathy with customers. For learning how they think, and what they think about, and what they expect to be taken care of for them.
Customer Care rotation for new engineers
Where I work, we have a practice for all new college hires. They spend a month with customer care, taking support calls on our product. In this program, they are provided the same training that our care agents receive then get on the phone to help our customers. The learnings are amazing. After 4 years of academic learning, steeped in algorithms and theory, they get exposed to the day-to-day issues that our customers encounter. An example of an insight that an engineer passed on to me, “I was amazed how many people didn’t know about the right-click menu.”
The Customer Care rotation program is outstanding, but it’s also pretty expensive. It’s mostly been applied to new college graduates, and it’s combined with a more general orientation to our company and corporate life. Another method that is used by experienced professionals as well as long time employees is to listen into customer calls.
Listening to calls
Many of our customers call in for support. As we all know, “those calls may be monitored for quality control purposes.” The monitoring infrastructure provides an outstanding opportunity to get engineers and testers exposed to these calls. In fact, listening to both sides of the conversation while not an active participant gives some deeper insight to the customer’s issue and how we resolve those issues.
Many of our staff meetings start with listening to a call, followed by a discussion about the insights each of us learned by the process. Another practice, we call it the call listening lunch. Once a month, the entire team is invited to have lunch, while listening to prerecorded calls. After hearing the call, we discuss what could be done in product to mitigate the call. Many improvements came from these sessions.
Follow Me Home
The Follow Me Home process started a long time ago, when the main distribution channel for our products was a retail store. Engineers and marketers would hang out at a local retailer and watch people shop for our products. Marketers were interested in how the brand new customer chose our product from the alternatives on the shelf, but the fun stuff happened when they “followed” the customer home.
The team would approach the customer and ask to follow them to their home or place of business and just observe the first time use process. Did they read the instructions? Have trouble installing? Accept defaults or investigate each option?
The process continues, but is usually set up ahead of time via email contact. It’s very instructive to observe the customer use our products, in their environment. You notice things that are not spoken or written in surveys or support tickets.
One example insight, on a follow me home that I conducted with a customer that had complained about our service being slow. We checked the logs; all the transactions were in normal tolerances. We checked her computer, network connection bandwidth, network latency to our data center, etc. No slowness there.
In observing her, though, she had a stack of bills that needed to be paid. This stack was on a credenza behind her desk. She would take a bill, swivel her chair around and enter the data on our page. Then hit save, swivel and get another bill. She said “there, see, the screen is not yet ready to enter a new bill. It used to be ready by time I swung back.” Ah, we now have a new definition on how fast is fast enough: it can’t impede her work flow. (The real insight, why are we making this poor woman type in information, the bills should be automatically imported.)
Web design is about a lot more than fonts and style sheets. Ultimately, it’s about ease of use. To test ease of use, and gain insights about customer behavior, the UI designers invest a lot of time in formal usability studies. They will invite customer (or potential customers) in house and observe them using our product or prototypes. This is an excellent opportunity to get an engineer or tester some insights as well. Make friends with the design team, and get some invitations to observe as well.
Voice of the Customer
Our customer care team handles many calls, emails, and online chat sessions each week. They produce a call drivers report, which lists the top 10 issues that generate a support call, with the goal of fixing product or process so the call is not required. This aggregated and abstracted data helps focus priorities for product changes, and the raw data that feeds these reports are a great resource for gaining insights about our customers. We call this raw data the Voice of the Customer.
Our support system has a feature that pulls out 50 random issue summaries, and emails it to the entire team. The first item on our weekly development staff meeting is to review the call drivers and discuss insights learned from reading the verbatim comments.
Customer Satisfaction Survey Call Backs
Our marketing team conducts a customer satisfaction survey every quarter, called the Net Promoter survey. (Net Promoter is a measure of the willingness of our customers to recommend our product to their friends and colleagues). Part of this process is to call every customer that is a detractor (not willing to recommend our product), and a random sample of the promoters.
The marketing team loves getting help in making these follow-up calls. The team that builds and tests the product is an excellent choice for this task. Each engineer and tester is expected to make 3 of these calls per year. It’s not a huge investment in time and the insights gained are very valuable.
One way to understand our customers is to act like one. We hold frequent “challenges” where we put ourselves in the shoes of our customers and try to use our product. This is a great way to introduce new team members to the product.
To make this realistic, we have a document that describes a typical customer scenario. We ask the participatants to follow along with the scenario and only rely on information provided externally (web searches, product documentation, etc.) Putting yourself in the customer’s shoes is very helpful to understand how your product comes across to them.
These practices are helpful for developers and testers to build empathy for customers. In the next post, I’ll describe the infrastructure that is useful to implement customer-driven quality.