What Is Problem-Solution Fit?
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
Problem-solution fit is the point where you have evidence that a specific group of customers has a problem that matters to them, and that your proposed solution addresses it. It comes before product-market fit. You're not yet proving that people buy and keep using a finished product. You're proving that you've picked a problem worth solving and an approach that makes sense for the people who have it.
Many startups skip this step. They fall for an idea, build it, and only then find out that the problem was mild, or that the people who have it already cope well enough. Checking for fit first is a cheap way to avoid that. It's also the natural bridge out of the idea stage and into building.
Where the term comes from
The idea is older than any single framework, but two sources define it most clearly for founders.
The first is Alex Osterwalder and the Strategyzer team, who lay out three kinds of fit that a venture should aim for before it commits to execution: problem-solution fit, product-market fit, and business model fit. Strategyzer says problem-solution fit occurs when you have evidence that customers care about certain jobs, pains, and gains. Those terms come from the Value Proposition Canvas, which maps what a customer is trying to get done, what frustrates them, and what they'd like to gain.
The second is Ash Maurya, creator of the Lean Canvas and author of Running Lean. His company's site states a belief that has become shorthand for this whole stage: love the problem, not your solution. The same page puts the working order as "Demo-Sell-Build, not Build-Demo-Sell." In other words, show something and see whether people will commit before you build it.
Maurya has also described why the mistake is so common. In a 2014 SmartCompany article he is quoted saying that founders often prematurely fall in love with their solutions, and that customers don't care about the solution, only about their problems.
The three fits at a glance
Strategyzer treats the three fits as a sequence. Each one answers a different question, and each needs its own evidence.
| Fit | The question it answers | Evidence Strategyzer describes |
|---|---|---|
| Problem-solution fit | Is this a problem customers care about, and does our value proposition address it? | Evidence that customers care about certain jobs, pains, and gains |
| Product-market fit | Does our product actually create value for customers in the market? | Evidence that the value proposition is alleviating pains and creating gains |
| Business model fit | Can we deliver that value inside a profitable, scalable model? | Evidence that the value proposition sits in a profitable and scalable business model |
Notice what separates the first two. Problem-solution fit is about demand for the idea. Product-market fit is about the product in the market. For the second, see our guide to product-market fit for SaaS.
What evidence shows you have it
"Customers confirm the problem" is the headline, but it hides a lot of detail. Here's what a founder can reasonably point to.
The problem is confirmed by the right people
You've talked with a specific, narrow segment of customers, not a general audience, and many of them describe the same problem in their own words without being led. If you have to explain the problem to them, that's a warning.
The pains are ranked
Customers have problems with everything. What you need to know is which ones hurt most. The Lean Canvas has a box for the top three problems your customers face, which forces a ranking rather than a long list. If your problem lands in the middle of a customer's list, it may not earn attention or budget.
There are current workarounds
The same canvas has a box for how customers solve these problems today, labelled existing alternatives. This is one of the strongest signals available. People who already use spreadsheets, hire help, or stitch tools together are showing you the problem has a price tag. People who do nothing may not care enough to switch.
Customers have spent time or money
A workaround you can put a number on is better than one you can only describe. How many hours per week? Which tools do they pay for? What does the manual process cost? This gives you a baseline your solution has to beat.
The solution resonates in a demo
When you show a rough version, such as a mockup or a walkthrough, people react to the specifics. They ask when they can have it, or what it costs, or whether it connects to their existing tools. Polite praise doesn't count. Questions about using and buying it do.
Key Facts: Problem-Solution Fit
- Strategyzer names three kinds of fit: problem-solution, product-market, and business model fit (source).
- Strategyzer says problem-solution fit occurs when you have evidence that customers care about certain jobs, pains, and gains.
- Strategyzer's article was written by Nabila Amarsy and published on November 10, 2014 (source).
- Ash Maurya's LEANSTACK states the belief love the problem, not your solution and the order "Demo-Sell-Build, not Build-Demo-Sell."
- The Lean Canvas has boxes for the top three problems and existing alternatives, the two places to record problem-fit evidence.
- In 2014 Maurya said that founders often prematurely fall in love with their solutions.
- There is no official threshold for "enough" evidence. The term is a working concept, not a legal or financial test.
How it differs from product-market fit
The two terms get mixed up, partly because both are about "fit." The practical difference is what you're testing and what you've built.
| Problem-solution fit | Product-market fit | |
|---|---|---|
| Core question | Is this a real problem, and does our approach suit it? | Does the product we built create value in the market? |
| What exists | Hypotheses, interview notes, prototypes, demos | A working product with real users |
| Typical evidence | Customers confirm and rank the problem, describe workarounds, react to a demo | Customers use the product, return to it, and pay for it |
| Main risk | Solving a problem no one cares about | Building the wrong product for a real problem |
| Typical stage | Idea and early pre-seed | Pre-seed through seed stage and beyond |
You can have the first without the second. A team may find a real problem and build a solution people don't use. The reverse is rarer. A product that gains traction almost always rests on a problem someone cared about, even if the team never wrote that down.
How to test for problem-solution fit
Three methods cover most of the ground. They usually run in this order, and each answers a different question. The customer discovery process goes deeper on how to run them.
Problem interviews
These are conversations with people in your target segment, aimed at the problem and not your idea. You ask about the last time the problem occurred, what they did, what it cost, and what else they've tried. You don't pitch. The goal is to learn whether the problem is real, how often it shows up, and how people deal with it now.
Past behavior is the useful part. "Tell me about the last time this happened" gives you facts. "Would you use something that does X?" gives you opinions, and people are poor at predicting what they'll do.
Solution interviews and demos
Once a problem looks real, you show a rough version of your approach: a sketch, a clickable prototype, or a manual walkthrough. You're watching for specifics. Which part do they care about? What do they push back on? Do they ask for it? This is the "demo" step in the demo-then-sell order the LEANSTACK site describes.
Be careful to keep this separate from the first round. If you pitch in a problem interview, the person will start being polite about your solution and stop describing their own situation. A minimum viable product comes later, once these conversations point to something worth building.
Landing pages and smoke tests
A simple page that states the problem and the promise, with a signup or pre-order button, tests demand at a larger scale than interviews allow. You send targeted traffic to it and see who takes the next step. Treat results with caution: a click is a weak signal, and a deposit is a strong one. The page is useful for comparing messages, not for proving that a business works.
Which method answers which question
| Method | Best at answering | Weak at |
|---|---|---|
| Problem interviews | Is the problem real, and how do people cope now? | How many people feel it |
| Solution interviews and demos | Does our approach make sense to them? | Whether they'd really pay |
| Landing pages and smoke tests | Does the promise attract the right people at scale? | Why people did or didn't respond |
Using more than one method guards against the weakness of each. If interviews are warm but nobody clicks, or the page converts but interviewees can't describe the pain, something is off.
Common mistakes
- Interviewing the wrong people. Friends, colleagues, and other founders are easy to reach and tend to be kind. Talk to people who actually have the problem and don't owe you anything.
- Pitching instead of listening. If most of the conversation is about your solution, you've learned about your own enthusiasm, not their problem.
- Confusing a mild annoyance with a painful problem. Plenty of problems are real but not urgent enough to earn a budget. Look for signs of effort, cost, or workarounds.
- Treating every problem as equal. Without ranking, you may build for the fourth most important issue on a customer's list.
- Ignoring the current alternative. Your real competitor is often a spreadsheet, a habit, or doing nothing. If you can't say why someone would leave it, you don't have fit yet.
- Mistaking praise for commitment. "That's a great idea" costs nothing. A pilot, a pre-order, or a firm date to try it costs something.
- Starting too broad. A segment of "all small businesses" can't be reached or interviewed in a useful way. A narrow group you can name is easier to learn from.
- Declaring fit too early. A handful of encouraging chats doesn't prove it. Keep testing until the same problem keeps coming up and the alternatives are clear.
Where it sits in the startup stages
Problem-solution fit lines up with the earliest part of the stages of a startup. Most of the work happens during the idea stage, and the evidence it produces often decides whether a team moves into building a first version at pre-seed.
The stages and the fits overlap rather than line up neatly. A team may revisit problem-solution questions after launch if it enters a new segment, and some founders reach a rough fit while still calling themselves idea-stage. Think of fit as a checklist of evidence, not a gate someone opens for you.
A related way to think about the same sequence is the build-measure-learn loop from the Lean Startup method, where early experiments are meant to reduce the biggest unknowns first. Finding the riskiest assumption in your plan, and testing that before anything else, is a practical way to decide what to check first.
A simple checklist
Use this as a rough self-check. It's our own summary, not a standard.
- I can name one narrow customer segment.
- Several people in that segment describe the same problem without prompting.
- They rank it among their top few problems.
- I know what they do about it today, and roughly what it costs them.
- Someone has reacted to a demo with specific questions or a request to try it.
- At least one person has made a small commitment, such as a pilot or a deposit.
- I can describe the problem and the proposed solution in two sentences.
If you can't tick most of these, the next step is more conversations, not more code.
Related reading

On this page
- Where the term comes from
- The three fits at a glance
- What evidence shows you have it
- The problem is confirmed by the right people
- The pains are ranked
- There are current workarounds
- Customers have spent time or money
- The solution resonates in a demo
- How it differs from product-market fit
- How to test for problem-solution fit
- Problem interviews
- Solution interviews and demos
- Landing pages and smoke tests
- Which method answers which question
- Common mistakes
- Where it sits in the startup stages
- A simple checklist
- Related reading