Lessons from Customer Interviews — part I

How to avoid making something no one wants


(Here are my personal Cliff Notes on Ash Maurya’s excellent Running Lean book. I hope you find them helpful, and I’d still highly recommend you to read the actual book. It’s one of the best Lean Startup books I’ve ever read, and I bought 2 myself — the physical and ebook version. It’s that good).

One of the most dangerous risks an early-stage startup faces is “building something no one wants.” Running Lean illustrates how you can use problem interviews as a tool to greatly reducing this risk. I’ll try to paraphrase and summarize the book’s excellent advice on how to do this.


How to interview customers

(Chapter 6: Interview Customers )

Avoid surveys or focus groups. Surveys are difficult because it assumes you know the right questions to ask, right answers to provide, and you can’t interact with survey participants. Surveys are better for later-stage validation, where the “goal is no longer learning, but demonstrating scalability (or statistical significance) of the results.”

Ways to talk to users (emphasis mine)

  1. Focus on learning about their problems instead of pitching a solution
  2. Don’t ask customers what they want. Measure what they do.
  3. Stick to a script for uniformity
  4. Cast a wide net. Interview lots of people, and throw out stuff that don’t make sense
  5. Face to face is better
  6. Start with people you know
  7. Have multiple people interview is good — it keeps the learning objective.
  8. Pick a neutral location, have enough time.
  9. Don’t pay prospects — the goal is to find customers who will pay us for the solution, not the other way around.
  10. Avoid recording, it makes people unnatural
  11. Document immediately
  12. Interview 30-60 people
  13. Consider outsourcing interview scheduling — using a virtual assistant could potentially save you a lot of time here.

Ways to find users

  1. Start with your first-degree contacts — even if the feedback is potentially biased, it’s better than talking to no one.
  2. Ask for introductions — include an email template for easy forwarding.
  3. Play the local card — people like to help others from the same town, city, country.
  4. Collect emails from a landing page
  5. Give something back — offer to write up in the interview, blog, video, etc.
  6. Cold call, email, or LinkedIn — best saved for last when your messaging is better fine-tuned.

Doing the Actual Interview

(Chapter 7: The Problem Interview)

Now that we’ve gather a number of potential customers to talk to, what are we looking to gain from these interviews?

Recall that problem interviews is about reducing the risk of building something no one wants. Hence everything you say and learn during the interviews must be geared toward answering the following questions:

  1. Product risk: What are we solving (Problem)?
  2. Market risk: How do customers solve these problems today (Existing Alternatives)?
  3. Customer risk: Is this a viable customer segment (Customer Segments)?

Formulate falsifiable hypotheses — formulate your hypotheses about your potential product into the following formula, then use your interviews to either prove or disprove the hypotheses.

Falsifiable Hypothesis = [Specific Repeatable Action] will [Expected Measurable Action].

For example, “Problem interviews will reveal difficulty sharing lots of media as must-have problem,” or “Problem interviews will validate customers use one or more existing alternatives.”

I found it was difficult to formulate concrete, useful falsifiable hypotheses during my own interviews. For example, I was trying to verify that users have problems tracking versions of Word documents, and so my falsifiable hypothesis became — “Verify that users find tracking content changes of different version Word documents as a must-have problem”. But then the key hinges on the definition of “must-have”, and in the initial stages, it’s hard to know what defines “must-have” vs. “should-have” and “nice-to-have” problem. In our case, almost all users have some existing work-arounds, and while people have various degree of complaints about their current solution, it’s at times difficult to tell when they’ve crossed into “must-have” territory. e.g. lots of people complain about email overload, and there have been a plethora of project management or email managers over the years, yet email remains the most common form of corporate communication till today.

Sample structure of a Problem Interview

  • Welcome — set the stage (2min)
  • Collect Demographics — Test Customer segment (2min)
  • Tell a Story — Set Problem Context (2min)
  • Problem Ranking — Test Problem (4min)
  • Explore Customer’s worldview — Test Problem (15min)
  • Wrapping up — The Hook and Ask (2min)

The most important parts of the interview is the Problem Ranking, where you ask the customer to rank 3 potential top problems with their current situation, and Explore Customer’s Worldview, where you listen to their existing solutions or workarounds.

Problem Ranking

In Ash’s example, he’s trying to build a photo/video sharing solution that doesn’t require installing local client software, so his top 3 problems are —

  1. Do you find yourself taking more photos/videos than before?
  2. Do you find the photo/video sharing process painful?
  3. Are you like most parents in that you don’t have a lot of free time?

Do you have any other photo- and video-sharing pet peeves I didn’t talk about?

Explore Customer’s Worldview (Test Problem)

This is the heart of the interview, so best to listen open-endedly with no script. And use your best judgment on a problem’s “must-have” factor. His sample questions are

  1. So, how do you share photos and videos today?
  2. Could you walk us through your workflow?
  3. What products do you currently use and how did you first hear about them?

It’s important to check for consistency between a customer’s purported problem ranking and his current solution; if a problem was ranked as “#1”, but customer didn’t bother to have an existing solution, then the problem is probably not really that important.

From our own experience, it’s also easy for customers to proclaim they have a pain point, but much more difficult to tease out how badly the user really wants to solve it (and pay). Obviously if the user had hacked together their own solution, that’s a good signal, but unfortunately we haven’t been able to identify other ways to reliably qualify a user’s pain level.

Once the interviews are in progress, it’s important to

  • Review your results weekly
  • Start to home in on early adopters
  • Refine the problem — it’s important to distill your product down to one “must-have” problem for one unique value proposition
  • Really understand their existing alternatives.
  • Pay attention to words customers use — these can be keywords used to optimize your marketing message, and value proposition.
  • Identify the potential paths to reaching early adopters — this will be useful to build distribution channels later.

Problem Interview Exit Criteria

So how do you know when you’re done with interviews? You are done when you have interviewed at least 10 people and you:

  • Can identify the demographics of an early adopter
  • Have a must-have problem
  • Can describe how customers solve this problem today

The above are my notes excerpted from Running Lean’s most relevant chapters on Customer Interviews. Stay tuned for more notes in the future!


Want more posts like this? Sign-up for my email newsletter

Email me when Yu-Kuan Lin publishes or recommends stories