What Customers Say

What do you get when you talk to customers?

I just finished a large round of customer interviews and was reminded of something in Tony Ulwick’s great book, What Customers Want.

When you talk to customers, they don’t give you “requirements.” In fact, requirements don’t really exist. The statements they make can be separated into four buckets:

• Solutions

• Specs

• Needs

• Benefits

The sketches above give you an idea of what that sounds like. Usually, these statements aren’t directly actionable by the product team and need to be “unpacked” to some degree. You need to translate what you’re hearing into either:

• Outcomes they’re trying to create

• Goals they’re trying to achieve

• Jobs they need to get done

• Constraints they’re under (don’t forget these!)

There’s lots of information available on how to translate the statements into actionable insights: you can use Tony’s book, refer to The Jobs-to-be-Done Handbook, go with the Lean Startup approach, or use the traditional Cooper design methodology.

Talk to customers, but don’t take their statements at face value.

User Stories Must Die

I knew the traditional Agile user story was lifeless and disconnected from the real world long before I could articulate why. Then I came across Alan Klement’s post on replacing user stories with Job Stories, which builds on top of the Jobs-to-be-Done framework.

Instead of the usual “As a / I want / so that” structure, a Job Story looks like this:

• When [I’m in a certain situation]
• I want to [take some action]
• so I can [achieve some outcome].

I’m in the middle of synthesizing a pile of customer research right now, and I’m kind of amazed how well the Job Story lets me encapsulate what I’ve learned in literally one sentence. Traditional design methodologies offer other ways to capture and share these insights, but boiling it down that much is very compelling.

Another benefit I’m seeing is knowing how much more research is needed. That is, if you can’t write the Job Story to explain a behavior, you’re not done interviewing.

The Study of Causation: Etiology →

I was listening to the TED Radio Hour today and ran across a great word: etiology.

It’s the study of causation, as in:

What causes someone to contract polio?

For those of us doing product work, it’s critical to know what causes someone to use a particular feature. What caused this user to run a certain report? What’s causing these other users to create a given workaround?

Your product will improve when you understand the etiology of each user behavior.

Scenarios Are More Than Use Cases

It’s not uncommon for a designer to join a project in which “the use cases are already written.” This documentation attempts to describe in words how a user will complete a particular task within the system.

Scenarios take this further and include the context around the action to form a complete story of a person in the real world using the product to create a positive outcome. In the example shown here (Square’s credit card reader), I’ve intentionally de-emphasized the steps around charging the card to highlight the surrounding context. Reviewing the full story helps the team identify additional functionality the product needs to serve this customer:

• The charge needs to be authorized in less than 5 seconds. (Count it out and imagine being the buyer, waiting and drumming your fingers.)

• The seller needs an easy way to cancel or refund the charge. (Someone will hit the wrong button in the chaos of the trade show floor.)

• A simple way to keep/decrement inventory would be a value-add for the seller.

Imagine if this team stopped at simply “meeting the requirement” that the seller swipe the card and the buyer signs with their finger. That notion is abstract beyond the point of helping the team know if they can serve this customer. Instead ask how your product will help a specific person get through a specific situation.

Take the Leap and Talk to Customers

The leap of faith scene from Indiana Jones and the Last Crusade struck me as a good metaphor for doing customer interviews: just do it and you’ll be fine.

But after thinking more about it, I realize it’s deeper than that. There is no actual danger—only the illusion of danger created by the perspective you have on the situation. When you look at it differently, you see there’s nothing to be afraid of.

Best of all, when you figure out the “secret” and get through it, you make the path clear for others.

A Template for the Jobs-To-Be-Done Timeline

Clayton Christiansen is as high-profile as a business school professor gets, being the author of the only business book Steve Jobs ever read. And while his work on disruptive innovation has been hugely impactful, there’s another aspect of his work that any business can use: the Job-To-Be-Done.

Much has been written about Jobs-To-Be-Done Theory, but the core concept is simple: behind every product purchase is a certain “job” the buyer needs to get done. IKEA, for example, has had great success orienting its business around a consumer that needs one or more rooms furnished in a hurry. And there’s the classic story of a fast food chain discovered adults buying milkshakes as a drive time breakfast substitute. Understand the job and you’ll understand the demand for your product.

One of the best methods to identify the job your customers are looking to get done is to use The Timeline. The Timeline is an interview technique in which you step the interviewee through one particular instance of a given product being purchased and used. It begins with the first thought they consumer had they needed a product similar to the one they bought, extends through using the product, past the “honeymoon period,” and evaluating their satisfaction in retrospect.

Like any timeline, the Jobs Timeline has certain key points on it, and between those are phases. The following is a quick run-through of how to use the template and run one of these interviews.

Tip: When you sit down with your interview subject, set expectations by asking them to pretend you’re filming a documentary about this purchase. Your interview will be much more fruitful if you can “move their mind” back, so warm up with questions on where exactly they were, what the weather was like, and so on. Put them back in the past.

The First Thought is aptly named, and defines the beginning of the Timeline. It’s not a great place to start the interview, however. If you start at the purchase and work backwards, you’ll get much better information. If you simply ask people when they had the First Thought, they’ll answer the question multiple times, and each time this event moves backwards in time. This makes the interview feel choppy. Work backwards and you’ll get there.

“I liked my car when I bought it, but I remember one cold day it felt really drafty and I realized the mileage was getting up there.”

After the First Thought, the person goes into a Passive Looking mode. They’ll have their eyes and ears open for potential matches to their need. Jot down anything they noticed or remember relevant to the purchase during this time. Maybe they noticed an advertisement for a possible solution. (Note to marketers: this is a good time to advertise to them!)

Eventually, something happens that pushes the buyer into an Active Looking mode. This thing that happens is captured as Event 1. Capture this.

“My friend and I originally bought our cars around the same time, and he got stuck in the city because his wouldn’t start.”

In this phase they may compare options online, read books or magazines, and ask friends about the issue. They’ll generally expend much more effort investigating the options. The options the consumer identifies are known collectively as the Consideration Set. This is your competition, so ask about this. Make notes on what they compared, and how. You’ll probably be surprised how products “outside your category” are in the running in the mind of the consumer. (Customers don’t care how you’ve segmented your market.)

More time passes, and sooner or later another event happens (Event 2) that causes the buyer to set a deadline for the purchase. Jot this down as well, and look for patterns among buyers.

“When we saw the check engine light on our car, we knew we’d be going to dealerships that weekend.”

During this Deciding phase, the consumer makes Trade-offs among the criteria they identified earlier. Capturing these trade-offs is critical, since it gives you real insight into what your buyers think is important. Record how the buyer ranked them. Cost over quality? Speed of delivery? What actually mattered?

Before long, the consumer makes the Purchase and simultaneously sets their own expectations about what it’ll be like to use the product. The Consuming period after the buy is a continual evaluation against those expectations. Capture which item they ended up purchasing, and prepare for the interviewee to flood you with details on what it was like to use the product and whether they were satisfied.

Satisfaction surveys tend to focus on the buyer Looking Back at this point and reflecting on their purchase. If the interviewee purchased your product, you may get a few good nuggets of info in this satisfaction discussion. Outside of that, satisfaction reports are overrated because value is defined in the customer’s mind Going In as part of the steps leading up to the purchase. Understanding how the buyer built up their definition of value is usually much more valuable from a strategic perspective. Put another way, understanding how well a product met a certain consumer demand is not the same as understanding the demand itself. Don’t make the mistake of confusing the two.

After the Interview

Even a handful of these interviews will get you deep inside your customers’ heads and fill in your understanding of what they’re trying to get done. Armed with that information, you can build new features or create entirely new products that address a demonstrable need. Minimally, you can tweak your product’s marketing to make sure you’re truly speaking to customer concerns.

Tools like these that build an understanding of the customer are critical for product teams. Without them, they’re simply flying blind—guessing what current customers value and what would attract new ones. Do a few of these interviews and share the results with anyone that touches your product. If departmental silos have hardened in your organization, try the sledgehammer of customer insight.