Most product ideas fail not because the technology doesn’t work, but because nobody needed it in the first place. And by the time we figured that out, it may be too late. But there is a simple question that can cut through that particular fog: Whose problem are we solving?
Myself, I have spent both months and years building stuff nobody really needed, because we never actually answered this one question.
The question sounds simple. And yet I’ve found, both as a startup CEO myself and when working with companies from startups to large enterprises, that it can be very hard to answer.
The question is really two questions in one. Are we solving a problem at all? And do we know who has this problem? Answering both gives us something valuable: not just what the problem is, but how much it matters.
The Problem: Figuring out the Problem
We all know that ideas should be formulated as solutions to real problems. Not hypothetical ones, not problems we think people should have, but problems that exist right now. But even when you know you should be thinking in terms of problems, it is easy to get lost.
The usual starting point is a loosely formulated idea. Myself, I’ve been in many meetings where someone (often me) proposes an idea for a product or feature with a vague justification that is some variation of “Here is an idea…” or “wouldn’t it be cool if…” And while that idea may have been good, there is nothing in that pitch that tells us anything about how good it really is.
Let’s try an example by picking a idea that kind of feels like a real product we might want to build: a Bluetooth coffee cup. A small IoT sensor embedded in a coffee mug that sends a notification to your phone when the coffee hits the perfect drinking temperature. No more burnt tongue. No more cold coffee you forgot about.
So now we have our idea, a Bluetooth coffee cup. Let’s apply the Whose problem are we solving? question on this idea and see where this takes us.
But first, why isn’t it enough to just answer the question “what problem are we solving”?
“What Problem Are We Solving?” is Not Enough
So we know that we are supposed to be solving a problem, and we’ve found that we can ask ourselves the question “what problem are we solving?”. This sounds great! Why isn’t this enough?
I’ve found that the “what problem are we solving?” question makes it too easy to simply restate our idea as a solution, without further analysis, and then believe that we’re done.
If our idea is the Bluetooth coffee thermometer, we might formulate the problem as: “We solve the problem of coffee being too hot to drink”. This technically answers the question of what problem we are solving. But it doesn’t tell us anything about how important that problem is.
The Trick: Focusing on the Who
Here is where the “Whose problem are we solving?” question starts to do its thing. Instead of solely focusing on the problem we are solving, it forces us to first figure out who has the problem we are solving.
This really requires us to sharpen our thinking. Because if we need to find an actual person who has that problem, it isn’t enough to just say that “users” or “people” or “companies” or “multinational enterprises” has the problem.
We need to figure out a real person in a real role who might have the problem, like “Our customer Alice”, “Bob in accounting”, “VPs of sales at Fortune 500 companies”, or “Python developers who want to develop frontend applications”. And this is where we start to see whether our ideas actually hold up to scrutiny.
Let’s look at our coffee thermometer. When we try to name someone who has this problem, and who is actively paying to solve it today, we run into trouble. Everyone who drinks coffee has experienced it being too hot. But what are they paying to solve it, today? Nothing. They wait a few minutes, or they blow on it. The existing solution is free and requires no hardware.
So that’s a sign that our idea isn’t so good.
How Important is the Problem?
Now that we know both who has the problem, and what that problem is, it is surprisingly easy to start figuring out the importance of the problem. We can do this with these three questions:
- How many are there that experience this problem? (Usually: the more they are, the more important the problem.)
- How often do they experience this problem? (Usually: the more often they experience the problem, the more important it is to solve.)
- How much are they paying today to solve this problem? (Usually: the more they are paying, the more valuable problem to solve.)
And then we multiply them to get a rough idea of the importance: How many * How often * How much
Let’s now apply this idea on two use cases:
- Building a business case
- Prioritizing feature requests
Use Case 1: Building a Business Case
Building a business case is something we often have to do: most enterprise projects start out requiring a business case to be formulated. In a startup, the entire purpose of the company is to find a repeatable and scalable business.
And our “Whose problem are we solving?” question gets to the heart of the business case. Because we can now estimate a value of the problem, and our solution to it. We do this via our three questions:
- How many have this problem?
- How often do they have it?
- How much are they paying to solve it today?
Then we simply compute How many * How often * How much, and we get a rough estimate of the value.
Say that 1,000 persons are paying $1,000 per day to solve this problem, our problem is worth $1,000,000 per day.
What if we find that only a small number of people have this problem? Or if they are not paying anything to solve it today? That means that we are in a bad place, and that we should pick a better idea. As a general rule, if we want to build a business, we probably shouldn’t solve a problem that we just found to be of low value.
But if we find that many people have this problem, that they have it often, and that they are paying a lot to solve it today, we have a good business case. And we now have a way to demonstrate that it is good.
Use Case 2: Feature Requests
Feature requests are another area where this question works surprisingly well. When someone has an idea for a feature, it’s easy to jump straight to building that feature. But asking “Whose problem are we solving?” first forces us to think about who really needs this feature before we start debating how to build it.
For feature requests, a vague answer to the question is fine. We don’t need a perfect answer, the important thing is that we think about the question. We just need enough of an answer to know whether solving it makes sense for the direction our product is heading.
The importance of the feature request depends on the answer to the question of whose problem it is solving. If it is solving a customer’s problem, then that usually means increases the importance of the feature request. If it is solving our own problem, that might mean that it is important too (if it is an important problem). But if we find it hard to even say whose problem this feature request really is solving, that might be an indication that this is not really an important feature request after all.
Why this Question Works
This question works because it is falsifiable. That means that we are able to determine if we got it right or wrong. We can talk to the people that we think have this problem to see if they actually have it. Do they have it? We might be on the right track. Do they not have it? We are probably wrong and should pick a different problem to solve.
Without answering this question, we can continue to believe in our idea forever, burning through runways and budgets, because we can always convince ourselves we’re making progress toward some abstract goal. Even though nobody really has the problem we think we are solving.
More Examples
Now let’s apply this question to a few more examples. Here are some companies who are solving someones problem:
-
Amazon Web Services (AWS): Whose problem are they solving? A CTO at a ten-person startup who needs to deploy a backend before launch but doesn’t want to pay for server hardware. A basic rack of servers plus colocation costs $30,000–$80,000 upfront, and $500–$2,000 a month to keep running. And this is before even writing a line of product code.
-
GitHub: Whose problem are they solving? A VP of Engineering whose team has grown from 5 to 25 engineers and whose codebase is starting to turn bad, with broken builds, changes overwriting each other, and a poor code review process. Enterprise version control like Perforce may cost hundreds of dollars per user per year, several thousands for a team of 25, plus a dedicated person to administer it.
-
Stripe: Whose problem are they solving? A CEO of a startup who needs to start charging customers before the runway runs out. A traditional merchant account costs $500–$1,000 to set up, takes weeks of paperwork, and the integration itself is another 2–4 weeks of engineering time. Maybe $15,000–$25,000 in developer hours before a single transaction clears.
-
Google Ads: Whose problem are they solving? A VP of Marketing at a B2B software company who may be spending $500,000 a year on trade magazine ads, conference sponsorships, and direct mail campaigns, with almost no way to know which of it is actually driving sales. A full-page trade magazine ad costs $10,000–$50,000 per insertion and reaches everyone who picks up the issue, not just the people actively searching for their product.
Conclusion
It is too easy to miss good ideas and get stuck with bad ones. Figuring out whose problem our idea is solving is a simple trick to distill the good ones from the bad.
If we don’t know whose problem we are solving, we might burn time chasing solutions to problems that may not exist. Unlike technical debt, which can be paid down later, that time is just gone.
So the next time you have an idea for something (anything, really): think about whose problem it is solving.