The Problem Discovery Interview

If you’re following lean startups, you’re undoubtedly familiar with concepts like customer discovery and problem/solution interviews. This morning, I was reading Paul Graham’s essay from the inception of YCombinator, “Why Smart People Have Bad Ideas,” and thought of a new type of interview that smart people should try: the problem discovery interview. The concept is simple: sit down with someone for 20-30 minutes and try to identify where they spend the most time and money so that you actually solve a problem someone is willing to pay you for.

In the customer discovery phase, you have identified a particular problem space that you’d like to focus on. You target people who are likely to have your problem, unhappy with the available options, and ideally have spent toward a solution. For example, if you wanted to start a laundry pickup service, you would want to find people who had hired a housekeeper to do laundry or visited a laundromat on a regular basis. You would ask them how important it was to save time or money on laundry services, then perhaps pitch your version of the solution, depending on what stage of the process you’re in.

But how do you choose a problem space in the first place? I’m not sure how most people choose ideas, but for me, I see 3 major sources:

  1. Conversations with friends or family
  2. Articles and blog posts
  3. Solving a problem myself

The third one is a wonderful source of ideas, assuming that other people are remotely like me. (As every former girlfriend has disparaged, this does not appear to be a valid assumption.) The first two are also wellsprings of good ideas, but they present a trap long-known to UX designers — what people say they want and what they actually want are very different things.

The interview that I propose cuts through this mirage. The proposal itself is simple: sit down with someone for 20-30 minutes and review their finances and weekly schedule. For any large chunks of money or time, research the space and decide if the problem is generalizable and important to you.

It might be difficult to convince someone, particularly a stranger, to walk through relatively personal details with you. Consider the alternative, though: your interviewee stresses over budgets and schedules, forgets to pay a bill because she spent 5x longer than necessary performing a given task, or just doesn’t have time for the personal development tasks she needs to maintain a fulfilling life.

This idea could also work with businesses, particularly small businesses that couldn’t afford to bring in a consultant to help them with process efficiency. You could sit with the owner or founder of a company and walk through expenses and time sinks. How much do they spend on project management? Food? Supplies? How much time do they spend passing around Excel spreadsheets or trying to convince everyone to use a bug tracker? You are likely to discover many problems you never would’ve considered if you just sit with a passionate business owner for a few minutes.

The reason most entrepreneurs fail is because they deliver a product no one wants. Sometimes this is because they create the product that they think people want without ever talking to their customers. In a better but still fatal case, they talk to customers, but they do exactly what the customer asks for. Like behavioral economics or experimental psychology, part of entrepreneurship is separating expressed desires from actual behaviors.

If you’re struggling to decide what problem you should spend your time on, try conducting some problem discovery interviews. See what people spend their time and money on, then build a product that saves them one of those resources. And while you’re at it, share your results and save other entrepreneurs some time as well.

This entry was posted in Opinion and tagged , . Bookmark the permalink.

2 Responses to The Problem Discovery Interview

  1. Matt De Leon says:

    Right on…I’m trying a similar approach with a new idea of mine. In my spare time, I’m sitting down with coworkers and chatting about their problems getting questions asked and answered at work.

    I would caution that this feels a bit like fishing for an idea in the middle of the ocean. I would prefer to first have an intuitive feeling for the problem space, then try to understand the problems within that space better.

    On a separate note, I had an interested experience recently where my coworker and I were testing our app with users. They suggested a feature that would color objects on a page to help them differentiate one type of object from another. My coworker and I stared at each other, desperately looking for a way to say “NO!” (It would’ve destroyed the UI.) Well, after some thought, we realized what they NEEDED was an easy way to search for certain types of objects, not a coloring mechanism.

    Just goes to show you that people truly do not know what they need. Look for problems, not for solutions. The solutions are for us to create :-)

    • kyle says:

      I think the goal of the problem discovery interview is to begin orienting yourself within a space, not to find the one true idea to spend your next 5 years on. If 5 people tell you that budgeting is their biggest problem, you’ll start looking at the budgeting space a lot more closely.

      Although no customer will give you the exact solution to their problem, playing off of existing psychology is important. If people are used to paper-based systems in a particular space, you should probably try to implement something that shares characteristics of the paper system. That’s why most computer interfaces still resemble card catalogs and filing cabinets at a high level. Once people come to terms with a new method of interaction, you can layer in novel behavior and create a new paradigm over time.

      Thanks for the comments. Would love to hear more about the color/search UI on Wednesday!

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>