Customer Discovery Series Part II: How to Identify and Validate the Problems your Users are Having

Product Management is all about two things - pattern recognition and the art of managing a lot of lists (more on this later).  Identifying common problems your customers are having comes from recognizing patterns in customer behavior, business objectives and internal/external feedback.  This is how I've managed to identify and validate customer problems...

1. Listen to your customers
The first step to understanding your customers is to talk to them.  I can't tell you how many product managers I interview that can't tell me the last time they've talked to a customer.  In my career, I've managed to speak to a customer almost every single day.  Whether it was a consumer that purchased on a site or it was a business user (or buyer) to understand their pain points, I made sure I got someone on the phone or in person that could tell me how they were using our product and why.

Customer development is key to this process.  Frequent interactions and iterations with potential or prospective customers help you and your team build the best products.  A way that you can do this is by GETTING OUT OF THE BUILDING.  Early in my career, I got advice from the team at Pragmatic Marketing - NIHITO.  It stands for 'Nothing Interesting Happens In The Office'.  Basically - get out of the building, talk to people.  Even if you walk around the office to talk to your peers and co-workers, it gives you perspective to understand the landscape of the ecosystem you're working in.  A way you can develop customer insights is by answering 6 questions:

  1. Who are my users?
    • Are they businesses? Consumers? Parents?  What are their demographics?
  2. What are their habits?
    • Are they already doing something in a different way?
    • Do they create content? Share content? Are they active or passive users?
  3. Where are they accessing from?
    • Where do they spend most of their time? Desktop, tablet mobile?
  4. When do they need my product?
    • Time of day? During a particular moment in their life?
  5. Why do they need my product?
    • Do other products not meet their needs? Do other that exist fit their needs?
  6. How do they access my product?
    • One time download? Web app? iPhone app?

2. Come up with a hypothesis
Once we understand our customers, we can start to form hypothesis about our ideas. Remember 5th grade science?  A hypothesis is a supposition or proposed explanation made on the basis of limited evidence as a starting point for further investigation.
A few examples of hypothesis, taken from a few popular companies:

  • Groupon - businesses will be willing to give large discounts for short periods of time in order to get a large number of new customers
  • Uber - customers will take frequent trips if it is easy to book a ride and simple to pay
  • Dropbox - users are willing to pay for on-demand flexible cloud storage of their files
Hypothesis statements help product teams get answers.  Many digitial practices bring back the hypothesis as a way to validate prototypes and tests.  Defining this up front helps the team (and the PM) strategically consider success factors and hold themselves accountable.  Here's the format I've seen (and use):

  • We believe {this specific customer}
  • needs a better way to {meet this need}
  • because of {this insight}.
  • We believe that if we help them solve this problem, we will achieve {this business objective}
  • We know we're right when we see the following feedback from the market: {qualitative feedback and/or quantitative KPI change}
3. Validate your hypothesis
In order to validate your hypothesis, you have to ask yourself a few questions.

  • How painful is the problem?
  • How many people have this problem?
  • What resources are required in order to solve this problem

You can use various forms of MVP's (minimum viable products) to help validate these!  I'll cover this in another post.

How are you identifying problems your users are having? How do you validate them?

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.