Can You Describe—Exactly—the Problem You’re Solving?
Share:
This is an excerpt from partner Nils Bunger’s talk for Pear Accelerator S20.
Pear Accelerator is a small-batch program, where our partners and mentors work hands-on with exceptional founders through the journey to product-market fit. Learn more: pear.vc/pearx
The tricky thing about finding product-market fit is that it’s easy to be misled (and to convince yourself) by false signals. As Ajay mentions in his talk, the worst case scenario is when customers are lukewarm about your product. They will seem excited about it and talk about the features they want, but when push comes to shove, they won’t buy the product, no matter how many features you add at their request.
The hard truth is: that’s because they don’t actually need or love it. If this is happening to you, you haven’t found product-market fit.
Again, from Ajay’s talk, if your users love your product, they’ll tell you.
So how can you get to that point of love? How can you set yourself up for success and avoid getting caught in the feature spiral of death — where you’re building and shipping but no one is buying?
Customer development. Or, verifying your insight before building your MVP. This talk is about how you do that, step by step.
Jump to a section:
How to Form A True Problem Hypothesis
How to Win Your First Validation Meetings
How to Extract Real Insight From Your Meetings
The Mindset
“Fall in love with the problem, not the solution.”
— Uri Levine, co-founder of Waze
You first have to understand that customer development is not sales. You’re not selling your product yet. You’re not trying to convince potential customers that you have the correct solution.
Customer development is anthropology. You’re studying your customers. You’re trying to answer the question — do these people actually have a problem? How do they describe it? What would it take to solve it? You’re trying to probe and get real data to confirm whether your insight about a solution is correct.
And to do that, you need to deeply understand the problem your customers have.
Prepare to spend a lot of time here, going in a circle from hypothesis to validation back to hypothesis over and over again. It might feel frustrating, but it’s far better to be stuck in this loop, learning about your problem, rather than being stuck in the product feature loop where you’re wasting time, money, and energy building things that don’t work. You want to stay in the customer development loop until you achieve repeatable sales or clear cut metrics that say that you’re onto something.
Form A True Problem Hypothesis
A problem hypothesis has these basic parts:
- Problem: A concise, specific statement of the problem you solve
- Audience: Focused set of people who you think desperately have this problem
- Reasoning: What makes this problem something that people in the audience need solved?
The problem is “the what.” The two key points for a well-articulated problem statement is that it is (1) specific to something that is solvable and (2) in your customer’s language. If you don’t have either of these, you don’t actually know what the problem is.
For the audience, the most important thing is to be narrow and tight — who has the problem most acutely? Keep narrowing down your ideas until you have defined a concentrated pool of users with the most acute need.
For any amateur chefs out there, you can think of this like a reduction sauce — start with a big pot of some kind of juice and stir over the stove for many hours, slowly evaporating all the water and slowly concentrating the flavor of that juice. What’s left behind is the deep essence of the ingredients.
You want to be finding your group of customers with the deepest, most desperate need for a solution.
Finally, you need to double check yourself and make sure you have sound reasoning for your hypothesis. Do you know why your audience wants or needs that problem solved? Again, specificity is the key here.
If you don’t have a good idea of why people might need a problem solved (perhaps your reasoning is a bit circular — “this customer has this pain and they want it solved, because it’s painful”), it might not really be a problem in the first place. There are plenty of problems people have that they’re okay with tolerating, because solving them is more effort than it’s worth. Or, you’ve just made up a problem that doesn’t exist.
You’re looking for an urgent problem, or if you’re on the consumer side, you’re looking for people who are just itching for something new.
Win Your First Validation Meetings
Once you’ve got a solid hypothesis, you have to validate it. That means you need to collect data from unbiased people who don’t know you, which means you will need to lean into cold outreach.
While customer development isn’t sales, during this phase, you will need to put on your shameless salesperson hat a bit to get the meetings you need.
There’s no single answer to how you should reach out. This is actually a core part of your learning during this whole process. You will need to know the unique answer for your company: how do you reach the right people and what are you saying that activates them?
Your approach should have three key things:
- A high response rate
- Consists of your target audience
- Generates a steady volume of meetings
Then, it’s really a numbers game. Aim for 10 first meetings per week, and then aim to keep increasing that number with iteration. Iterate your message. Iterate your audience. Keep reaching out.
You’re learning about your customers here and you’re also learning about your message, where your customers hang out, and what they respond to. These insights are just as valuable as the meetings themselves.
Extract Real Insight From Your Meetings
Alright! You finally get to talk to customers! But what do you say? How do you get good data from them? Nils offers this simple section structure:
- First 10 minutes: Broad questions to learn the unexpected.
- Middle 10 minutes: Specific questions. Learn about your problem statement.
- Last 10 minutes: Reconcile and zoom out. Did what you hear in parts 1 and 2 match up? Why or why not?
Broad Questions Phase
During the broad questions phase, your goal is to learn context about the user and the general area of your company. Find out about the incentives and biggest problems on their mind before being influenced by your ideas.
Some example questions:
- What do you do here?
- Who else do you work with most closely?
- How do you spend most of your time?
- What’s the most important thing for you to accomplish?
- What’s the biggest challenge you have in your job now?
- What are the top 3 problems you face?
- Have you bought products to help some of these problems?
Do not tell them about your product idea, or what problem you’re after in this phase. Just try to understand how your prospect thinks about their day and what they need to accomplish.
During this phase, because your questions are broad, you’ll likely get some broad answers in response that won’t be very actionable for you. Make sure to spend some time drilling down into these answers. Pick one of the problems they talk about that seem relevant to you and ask for more details, peel back the onion a bit.
Specific Questions Phase
Your goal in this phase is to gain data points specifically about your problem hypothesis. Does this person have the problem you came up with? How badly do they have that problem?
Some example questions, and what you’re really after in asking them:
- Have you ever had <your problem hypothesis>? Tell me about that.
- How do you deal with it now?
→ Why You’re Asking: If this is a real problem, they’re probably doing something to deal with it already. And if they’re not, it’ll be useful for you to find out why. - How painful is this problem for you? How often do you have it?
→ Why You’re Asking: If this doesn’t come up that often, then it’ll probably not be a priority for them to buy or find a product about it. - Have you ever looked for a solution to this problem? Have you bought anything?
→ Why You’re Asking: If they have this supposed problem but then haven’t thought about it enough to try doing a simple Google search for solutions, maybe they just don’t care about it all that much. - Would <direct competitor> solve your problem? Why haven’t you bought it?
→ Why You’re Asking: Don’t be scared of this one. Remember, you’re not trying to sell a product, and in any case, you will have to assume in the future that your customer is going to know about your competitors—so you might as well ask them about it for your own competitive intelligence. - If you could solve this problem, what would change?
→ Why You’re Asking: Why does solving this problem really matter to this customer? Why does it make their life 10x better to not have to deal with it? This is what your product is going to need to solve for. - How valuable is that change?
→ Why You’re Asking: Value is much better than talking about pricing. You’re now trying to get as close as you can to a quantified version of the answer to the previous question. Does it cost them a lot of time? Money? Does it allow them to save on not hiring extra people?
Reconcile and Zoom Out
Now you want to reconcile what the customer has said in both the broad and specific phases to double check that your data is valid. If your customer answered your specific questions in a way that makes it seem like you’re onto something, but didn’t bring the problem up on their own in the broad phase, you’ll really want to dig in and understand why. Maybe the pain isn’t as intense as you (or they) think it is, or maybe they think of the problem you came up with more as a piece towards solving those larger problems.
Finally, you’ll want to zoom out and understand how your customer buys products or solutions to their problems. Ask:
- What would be the next step if you had a product that solves this problem today?
- Do you actually buy these kinds of products?
- If you tried such a product, what would you want to see to keep using it?
You want to try to make this part as concrete as possible for the customer, almost as if it really does exist. Walk through their new customer journey with this product in their life. You’re looking for that “WOW” moment, as described in Bob Tinker’s talk.
Tying It All Together
Do at least 5 user interviews with the same type of audience you outlined. If you’re not finding an acute, concentrated pain, go back to your problem hypothesis and revise either your audience, or your problem, and run through it all again.
If you are starting to find an acute pain, do 5 more user interviews and drill down to the next level of questions. Show some product mockups and see if the pattern you’ve been seeing holds up.
Ask about discrepancies between your interviews. For example, if the previous four of the five previous customers said something was extremely important, but your next five don’t mention it, just ask them about it — “These other three guys had this big issue around XYZ and that didn’t seem to come up here. Is there a reason? I’m curious about the differences between what you do and what they do.”
OMG, it’s starting to work!
The strangest thing happens when this process starts working: you’ll find yourself trying to have a customer development “anthropology” conversation, and your customer is trying to turn it into a sales conversation.
People start leading you, instead of you leading them. They want to buy this thing now, they want to know how they can try it out, they want to bring their colleagues to a meeting. It’s the WOW moment. If you can get it repeatedly with 3–5 customers, then it may be time to develop your MVP!
Two options for this phase:
- Create a “no-code” solution with phone / email / spreadsheets / whatever, and try selling the solution to a few.
- Try turning 3 of your most promising interviews into “design partners” to help co-create a solution. Try to get some written agreement in place.
In any case, we always recommend building the tiniest MVP you can, enough to go through a “build/measure/learn” loop, per Eric Ries.
We wish you luck and hope that all of you get to this magic moment! It’s our favorite part of the journey.