Startup Problems are Found in the “Why”
Date : February 15, 2021 By
The most successful startups have one thing in common; they’ve identified a significant problem for a large enough customer segment. This is the most important puzzle piece when starting a new business. But what do we mean by “significant” and what is “large enough”?
Finding Startup Problems
Not all problems are equal. Your job as a startup entrepreneur is to dig deeply into a customer segment to learn the problem that is meaningful and impactful — enough so that they are motivated to solve it. And not all customer segments are equal. You want a user base that is small enough to be easily reached, but big enough to gain financial traction with.
One of the great startup entrepreneurs and early stage investors, Peter Thiel, co-founder of PayPal, often talks about being ultra niche with your first customer. He says startups should try to get a large share of a small market rather than a small share of a large one because it’s easier.
You can always expand later.
“Every startup is small at the start. Every monopoly dominates a large share of its market. Therefore, every startup should start with a very small market… The perfect target market for a startup is a small group of particular people concentrated together and served by few or no competitors.” – Peter Thiel
The key to finding a significant problem for a particular group of people is doing extensive customer development. This is the process of getting out of the building and talking to potential customers before you launch a your product.
And when you start talking to customers, you’ll want to listen for the “why” not the “how”. Problems are found in the “WHY”. When you learn why something is important or frustrating or exciting or fun or overwhelming, you learn what the real need is.
It’s important to note that success is not driven by the number of problems you solve, but rather how well you solve the biggest single problem. Your business may in fact be addressing multiple problems or provide multiple benefits, but it’s likely going to be just one thing that hits the mark. So as you work on your user story and problem hypothesis, try to distill your problem and benefit to just one thing, for now at least.
Finding the “Why” in Customer Development
To emphasize this point about the “why”, let’s take a cue from an unlikely source, the Toyota Motor Company. Starting in the late 1940’s through the mid 1970’s, Toyota pioneered a new philosophy in automotive manufacturing called The Toyota Production System (TPS). The system was created by Taiichi Ohno, a Japanese industrial engineer, and it transformed modern manufacturing globally.
Today the process is often referred to as Lean Manufacturing and in many ways has become inspiration for the lean startup movement this course is based on.
For our purposes, the TPS teaches us something important about customer development and about finding meaningful problems to solve. Ohno’s inventive method asks five simple questions: Why, Why, Why, Why, Why?
Jake Mendel in his Medium article Seriously, what’s your (startup’s) problem? Shows us how we can use this process to begin to validating a problem:
Start with the problem you came up with
- Ask the question “Why does this problem occur for the customer segment?” This is your first why (we’ll call this Y1)
- Then ask “Why is Y1 happening?” (this is Y2)
- Then ask “Why is Y2 happening?” (this is Y3)
- Then ask “Why is Y3 happening?” (this is Y4)
- Then ask “Why is Y4 happening?” (this is Y5)
It might seem childish. It is, and it’s ok. We’ve all known kids that ask “Why?” repeatedly until a point of mutual exhaustion. This stems from their growing brain’s need to simplify and identify a “root-cause”. The root cause is the problem you want to solve.
Here’s an example of the five why’s in action.
- What are you trying to get done?
- Build a fence.
- Why?
- So that I can surround my front yard.
- Why?
- So that I can plant a garden.
- Why?
- So I can grow my own food.
- Why?
- So that I can save money on groceries.
So the real customer need is saving money on groceries.
Now let’s look at an example using a fictitious business idea.
Say you have an idea for a t-shirt that dries quickly. You think, maybe from your own experience, that people don’t like t-shirts that get sticky and hot when they sweat, and a quick-dry shirt is the solution. You might make a user story like this:
“As [an athlete], I want to [wear clothing that dries quickly] so that [I don’t feel sticky and uncomfortable when I sweat].”
So our root problem is something like: Athletes don’t want to feel sticky when they sweat.
Now let’s try the five why’s.
Why #1: Why don’t athletes want to feel sticky? — Because their clothes get bunched up.
Why #2: Why don’t they want their clothes to get bunched up? — Because they can’t be as agile.
Why #3: Why do they need to be agile? — Because they want to move quickly and stay focused.
Why #4: Why do they need to be focused? — So they can stay motivated to work harder.
Why #5: Why do they want to work harder? — So they can be the best at their sport.
So what did we learn about athletes by asking the five why’s? Well, we found that maybe the problem isn’t “sweating” and “feeling sticky”, but really that they want to be motivated to work harder so they can do their best.
With this insight we might alter our problem hypothesis to read:
“As [an athlete], I want [wear flexible clothing] so that [I can work hard to be the best at my sport].”
Of course we still need to talk to actual athletes, we can’t be sure we’ve nailed the problem just yet. But what we do have is a better sense of what athletes might actually want. And with a more open-ended problem hypothesis like — “wearing flexible clothing” and “being the best at their sport” — we have more room to listen for solutions when we actually do go talk to customers.
It may in fact be that they want quick-dry clothing to solve this problem. But it could also mean something else like loose fitting or lightweight clothing. We don’t need to know the final solution right now — the whole point is that we’re about to embark on a discovery mission to validate the problem and have suspicions around what the most likely solution to that problem is.