Problem-Solution Fit: How to Know Your Solution Solves a Real Problem Before You Build It

Quick answer

Problem-solution fit is the state in which a defined customer has a real, recurring problem that a defined solution would meaningfully improve — before either the customer or the founder has committed to building or buying anything. It is the rung that sits between market validation (does the problem exist?) and product-market fit (does the product retain?). Problem-solution fit is observed in customer behavior, not declared in a pitch deck.

The five rungs of evidence that prove problem-solution fit is real: customers describe the problem unprompted and without being asked about your product, customers have built a workaround that costs them time or money, the workaround produces measurable pain the customer names without coaching, the proposed solution would replace an existing workaround rather than sit beside it, and a small group of those customers commit something scarce (a pre-order, an interview hour, a deposit) in exchange for the proposed solution. The six failure modes that prove problem-solution fit is not real: the polite-yes problem (Rob Fitzpatrick, The Mom Test, 2013), imaginary-problem failure, feature-asking failure, workarounds-that-actually-work failure, segment-too-broad failure, and solution-irrelevance failure.

The 14-day validation framework is Customer → Problem → Pain Signal → Workaround → Solution Hypothesis → Validation Evidence. Each rung must hold before the next one is meaningful. A founder who skips the pain-signal rung and starts testing a solution concept is testing a hypothesis nobody has earned the right to pose yet.

Key takeaways

• Problem-solution fit is the rung before product-market fit. PMF (Product-Market Fit) tests retention; problem-solution fit tests whether the problem deserves a solution at all. Marc Andreessen's 2007 "Pmarca" essay on PMF was the first formal naming of the higher rung; the lower rung has been re-described in Steve Blank's Customer Development work (HBS, 2005–present) as the discipline of problem validation before solution testing.
• The polite-yes problem is the most common failure mode. When you describe a problem to a potential customer, most will agree it is real and that a solution would be useful. Most are being polite. Rob Fitzpatrick's The Mom Test (2013) made this canonical. The only honest test is whether the customer has already spent time or money to solve the problem — and would spend more for a better option.
• Workarounds are the cheapest signal of real pain. A customer who has built a spreadsheet, paid for a consultant, or switched between three competing tools has translated pain into action. A customer who just nods is reporting the polite-yes problem. Workaround analysis is faster and more diagnostic than interviews, because workarounds are observable behavior.
• Pain severity is not the same as inconvenience. A customer who complains about a slow tool has an inconvenience; a customer who pays a freelancer to fix it has a pain. The validator's job is to ask: what is the cost of the current workaround in dollars, hours, or missed opportunities? If the answer is "I just live with it," the problem may be real but the willingness to act is not.
• Problem-solution fit is a state, not a moment. The fit can erode. Customer needs change, competitors ship better workarounds, regulations shift. The discipline of maintaining problem-solution fit is the same as the discipline of finding it: observe customer behavior, measure workaround costs, and re-test the solution hypothesis every six months.

Why this matters

I have watched two founders test the same problem in the same week and reach opposite conclusions about whether the problem was worth solving.

The first was a solo founder building an AI tool for solo lawyers. He interviewed eleven lawyers, heard eleven variations of "yes, contract review is a huge pain," and started building. Six months later, three paying customers, churn above 50% by month three, and no organic lift. The interviews had produced polite agreement, not evidence. He had built a solution before confirming a workaround.

The second was a solo founder building a project tracker for freelance designers. He interviewed eight designers, and four of them had already built a project tracker using Notion templates and spreadsheets. The workaround was observable behavior: not "do you have this problem?" but "show me what you do today." He talked to those four customers about what the workaround cost them. The first designer had spent $1,400 on a Notion consultant to set up the system; the second had switched trackers three times in two years; the third had hired a VA (virtual assistant) to maintain the spreadsheet. The workaround cost was concrete. He built the same kind of tool the interviews had suggested was needed, and the first fifty customers paid within ninety days.

The difference was not the problem. The difference was whether the problem had produced action.

This article is the smallest set of steps that turns "I think people have this problem" into evidence that they do. Not a survey guide. Not a generic "talk to customers" essay. A concrete framework that ranks the customer, problem, pain signal, workaround, solution hypothesis, and validation evidence into a sequence that produces evidence instead of enthusiasm.

The deeper treatment — the four stages of startup validation, the six methods ranked by signal strength — lives in the canonical How to Validate a Startup Idea Before Building. The conversation discipline that surfaces real pain lives in The Mom Test Explained for Solo Founders. The customer-discovery playbook that finds the people who have the problem lives in How to Find Your First Customers Before You Build. The vocabulary used in this article is defined in the Startup Validation glossary.

What is problem-solution fit?

Problem-solution fit is the state in which a defined customer has a real, recurring problem that a defined solution would meaningfully improve — before either the customer or the founder has committed to building or buying anything.

Five things make this definition harder than it looks.

It is a relationship between a customer, a problem, and a solution. A problem-solution fit exists for a specific kind of customer facing a specific kind of problem, with a proposed solution that would change what they do. Move any of the three — change the customer, change the problem, change the solution — and the fit may disappear. The relationship, not any single piece, is what the term names.

It is observed in customer behavior, not declared in customer interviews. The polite-yes problem is real and well-documented. Rob Fitzpatrick's The Mom Test (2013) is the canonical citation: when you ask a customer whether a problem is real, they will agree to be polite. When you ask them what they have done about it, they will show you behavior. Behavior is the only honest signal.

It is the rung between market validation and product-market fit. Market validation asks "does this problem exist in this audience?" Product-market fit asks "does the product retain?" Problem-solution fit asks "is the proposed solution the right solution for this problem?" Each rung requires the rung below it. A founder who tests solution hypotheses before confirming problem evidence is testing ideas nobody has earned the right to pose.

It does not require a built product. Problem-solution fit is testable with interviews, workarounds analysis, and solution concept tests. The customer does not need a finished product; the founder does not need a development team. The whole validation can be done with conversations, prototypes, and a willingness to listen. Steve Blank's Customer Development methodology, taught at Stanford and Harvard Business School since 2005, treats this rung as the first of four: Customer Discovery, Customer Validation, Customer Creation, Company Building.

It is a state, not a moment. The fit can erode. Customers' workarounds improve, competitors ship better solutions, regulations change. A founder who treats problem-solution fit as a one-time checkpoint will eventually find the fit has slipped. The discipline of maintaining the fit is the same as the discipline of finding it: observe behavior, measure workaround cost, re-test the hypothesis.

A useful way to think about the concept: problem-solution fit is the state in which the customer is already solving the problem, badly, and would switch to a better solution if you could show them one. That phrasing is the entire reason this rung exists separately from product-market fit.

Why startups need problem-solution fit validation

Four reasons, in increasing order of consequence.

First, the polite-yes problem is widespread. Rob Fitzpatrick's The Mom Test (2013) made the canonical case: when you ask customers about a problem, most agree it is real to be polite. Most do not act on the problem when no one is asking. CB Insights' Startup Failure Post-Mortem reporting consistently lists "no market need" as the most-cited reason for startup failure, named by roughly 40% of failed founders across multiple years of survey data. The polite-yes problem hides the real signal behind friendly answers.

Second, building before problem-solution fit burns runway in a measurable pattern. A founder who tests the solution hypothesis before confirming the problem evidence builds a product for an audience that may not be solving the problem today. Three to nine months of runway get spent on a product that solves a problem the customer has not yet demonstrated they would pay to solve. The fix is to test the problem rung first.

Third, the assumption that customers will switch from their current workaround is often wrong. Most people with a workaround have optimized the workaround for their context. Switching has a cost. The job of problem-solution fit validation is to confirm the proposed solution would beat the workaround by enough margin to justify the switching cost. Without this confirmation, even a real problem may not produce a paying customer.

Fourth, problem-solution fit is the prerequisite for willingness-to-pay. A customer who has the problem but no workaround has not demonstrated the pain is acute enough to spend money. A customer who has the problem, has built a workaround, and complains about the workaround's cost has demonstrated pain severity. The willingness-to-pay test, which lives in Willingness to Pay Validation, produces a useful signal only when the customer has already shown they would act.

How to validate problem-solution fit

There are six methods that produce useful signal. They run from cheapest to most expensive, and they roughly track the strength of the signal they produce.

1. Workaround analysis

The cheapest, strongest, and most often skipped method.

The right measurement is: for each potential customer, what have they already done about this problem? Have they built a spreadsheet, paid a freelancer, switched between three competing tools, hired an assistant, abandoned a workflow, or simply stopped doing the work? Each of these is observable behavior. Each is a signal of pain severity.

Three patterns are common.

• The spreadsheet workaround. The customer has built a tracking system in Notion, Airtable, or Google Sheets. The cost is the time they spent setting it up and the time they spend maintaining it. The signal is concrete and countable. A founder who can show a customer a tool that replaces a maintained spreadsheet has evidence the customer would switch.
• The tool-switching workaround. The customer has tried multiple tools and not found one that fits. The signal is high but harder to read — the customer has tried and been disappointed, which means the bar for the next solution is higher than for a customer who has not tried.
• The abandonment workaround. The customer has stopped doing the work the problem requires. The signal is mixed. Abandonment can mean the problem was not severe enough to act on (low pain) or the workaround cost was higher than the value of doing the work (high pain). The interview must surface which.

2. Pain severity interviews

The middle method, and the one most worth running this week.

The interview is structured around the question: "What did you do last time this problem came up?" Rob Fitzpatrick's The Mom Test (2013) formalized this question. The interview never asks whether the problem is real; it asks what the customer did about it. Behavior is the only honest signal.

The interview script is five questions. Ask them in order. Listen without pitching.

1. "Tell me about the last time this problem came up."
2. "What did you do about it?"
3. "How long did that take?"
4. "What did that cost you, in time or money?"
5. "What would have to be true for you to spend money on a better solution?"

The fifth question is the closest the script gets to asking about willingness to pay, and it still does not ask. It asks the customer to name their own threshold. Customers who name a concrete threshold have demonstrated pain severity. Customers who say "I'd have to think about it" have not.

3. Solution concept tests

The second behavior signal, and the one that catches founders who have built the wrong solution.

The right measurement is whether the customer can describe a better solution without prompting. Ask: "If you could magic away this problem tomorrow, what would change?" Customers who can describe a specific change have a concrete mental model of the solution. Customers who cannot — who say "anything would help" — have not yet identified the gap their workaround leaves.

The signal is in the specificity. A customer who says "I'd want a tool that auto-generates the first draft of the contract" has named a solution shape. A customer who says "anything is better than what I have" has named pain, not a solution.

4. Existing alternatives analysis

A founder who is testing problem-solution fit should map the existing alternatives the customer is choosing between. The map should include: tools the customer uses today, tools the customer has tried and abandoned, freelancers or consultants the customer has paid, and processes the customer has built internally. Each alternative is a workaround.

The analysis is informative in three ways. The customer has many alternatives. The pain is real but the switching cost is high. The customer has few alternatives. The market is underserved; a new solution has room. The customer has one alternative that they love. The pain is real but the bar is high; a new solution must demonstrably beat the existing favorite.

5. Pre-order and deposit tests

The most expensive, most diagnostic method, and the one that closes the problem-solution fit loop.

A pre-order is the customer giving the founder money in exchange for a future product. A deposit is the same signal with a smaller commitment. Both are behavior, not opinion. A founder who can collect five to ten pre-orders from distinct customers has evidence the problem-solution fit is real and the willingness to pay is concrete.

The full playbook lives in Willingness to Pay Validation. The relevant principle here is: a pre-order or deposit is the cleanest single signal that the proposed solution would replace an existing workaround, because the customer has committed something scarce.

6. Concierge workaround

The method that combines interview and pre-order. The founder does the work the customer currently does, manually, for a small group of customers, for a few weeks, at a price that proves willingness to pay.

A founder who delivers a concierge workaround to five customers and four of them are still paying at week four has evidence the proposed solution would retain. A founder who delivers the same workaround to five customers and all five have canceled by week two has evidence the pain was real but the solution shape was wrong.

The concierge workaround is also called the "concierge MVP" (Minimum Viable Product) in Eric Ries's The Lean Startup (2011). The full method lives in MVP Validation.

The problem-solution fit framework: Customer → Problem → Pain Signal → Workaround → Solution Hypothesis → Validation Evidence

The six-step framework below is what every problem-solution fit method is a sub-test of. Each rung must hold for the next rung to be meaningful.

Customer. A specific, reachable group of people has a problem the founder can describe without prompting. The cheapest test is a problem interview that asks "tell me about the last time this came up." Without this rung, the rest is abstract.

Problem. The customer can describe the problem in concrete terms — when it happens, what triggers it, what it costs, what workarounds they have tried. The cheapest test is five interviews scored on whether the customer can name the problem unprompted. Without this rung, the founder is pitching a problem they invented.

Pain Signal. The customer has translated pain into action. The signal is observable: a workaround, a paid alternative, time spent, money spent, or work abandoned. The cheapest test is workaround analysis. Without this rung, the polite-yes problem dominates the signal.

Workaround. The customer has built a system, paid a person, or chosen a tool to solve the problem today. The cheapest test is the workaround analysis above. The workaround's cost is the price anchor for any future solution.

Solution Hypothesis. The proposed solution would meaningfully replace the workaround. The cheapest test is a solution concept interview that asks the customer what would change if the problem disappeared. Without this rung, the founder is solving a problem nobody has described a solution for.

Validation Evidence. The customer has committed something scarce — time in a longer interview, an email address, a deposit, a pre-order — in exchange for the proposed solution. The cheapest test is a paid pilot or a concierge workaround at a price that covers the founder's time.

The framework is sequential. A founder who has not confirmed the customer rung should not test the solution hypothesis, because they will not know whether the solution is for the right audience. A founder who has not tested the pain-signal rung should not collect pre-orders, because they will not know whether the pre-orders are from customers with the problem or from customers who liked the idea.

The framework is also cumulative. Each rung produces evidence that the next rung depends on. A founder who skips the workaround rung and jumps straight to pre-orders can still learn something — they will learn the pre-order conversion rate — but they will not know whether the conversion is high because the pain is real or because the price is low.

Problem-solution fit vs product-market fit

The two concepts are often confused. They are different rungs on the same ladder.

The two rungs are sequential. A founder who has not earned problem-solution fit cannot test product-market fit, because product-market fit requires a product to retain. A founder who has earned problem-solution fit but skips to scaling has skipped the rung that tells them whether the product retains.

The most common mistake is conflating the two. A founder who builds a product, sees retention, and declares "I have product-market fit" without first testing whether the proposed solution addressed a real problem is reading the wrong data. PMF (Product-Market Fit) without problem-solution fit is retention of a product that may be solving a problem the customer does not have.

Signs you have not found problem-solution fit

The failure modes that show up before the founder notices them. Each is recognizable, named, and preventable.

Polite-yes failure. The customer agrees the problem is real but cannot describe a workaround. The agreement is politeness, not signal. The fix is to stop asking whether the problem is real and start asking what the customer has done about it.

Imaginary-problem failure. The founder has identified a problem that is real in the abstract but does not produce action. The fix is to test the pain-signal rung before testing the solution hypothesis.

Feature-asking failure. The customer asks for features without describing a workaround. The customer is curious, not in pain. The fix is to ask what the customer would pay for, in a transaction, before any feature discussion.

Workarounds-that-actually-work failure. The customer has a workaround that works well. The pain is real but the switching cost is too high. The fix is to test whether the proposed solution is ten times better than the workaround, not two times better.

Segment-too-broad failure. The customer describes the problem but is not in the founder's target segment. The signal is real; the audience is wrong. The fix is to redefine the ICP (Ideal Customer Profile) before continuing.

Solution-irrelevance failure. The proposed solution solves a problem the customer does not have. The customer has the problem; the founder's solution does not address it. The fix is to listen to the customer's described workaround and propose a solution that replaces it, not a solution the founder imagined.

Common mistakes

The mistakes I see founders make in roughly the order they make them.

Asking customers about features too early. A customer interview that asks "would you use a feature that did X?" produces polite answers. A customer interview that asks "what did you do last time X happened?" produces behavior. The first question produces the polite-yes problem; the second produces workaround analysis.

Confusing inconvenience with urgent pain. A customer who complains about a slow tool has an inconvenience. A customer who pays a freelancer to fix the tool has a pain. The validator's job is to ask: what is the cost of the current workaround in dollars, hours, or missed opportunities? If the answer is "I just live with it," the problem may be real but the willingness to act is not.

Assuming everyone is a customer. A founder who has identified a real problem has not yet identified the right segment. Most problems are real for some people and not for others. The job of the customer rung is to narrow the segment to the people for whom the problem is severe enough to act on. A founder who skips this rung is building for an abstract audience.

Building before validating. A founder who has heard polite agreement from a few interviews and started building has skipped the workaround and pre-order rungs. The polite-yes problem is real. The fix is to do the interviews that produce workaround analysis before writing a line of code. Eric Ries's The Lean Startup (2011) is the canonical citation: build-measure-learn loops require validated learning, not enthusiasm.

Skipping the pre-order test. A founder who has done workaround analysis and confirmed the pain is real can still be wrong about the solution shape. The pre-order test is the cheapest signal that the proposed solution would replace the workaround. A founder who skips this test will find out, three months after launch, that the solution was wrong.

Treating problem-solution fit as a one-time check. The fit erodes. Customers' workarounds improve, competitors ship better solutions, regulations change. The discipline of maintaining the fit is the same as the discipline of finding it. Re-run the workaround analysis every six months.

Worked example

A founder I worked with last year had spent four months building an AI tool that summarized legal contracts for solo lawyers. The polite-yes problem had hit hard. Eleven interviews, eleven variations of "yes, contract review is a huge pain," and the founder had started building in week three.

The first thing we changed was the interview script. The new script asked: "Tell me about the last contract you reviewed. Walk me through what you did." The answers were revealing. Most lawyers had a workflow already: a paralegal who read the contract first, a checklist of clauses to flag, and a software tool (often a Word plug-in) that highlighted changes. The workaround existed. The cost was concrete: two to four hours per contract for the paralegal, plus $80 to $200 per contract for the plug-in.

The second thing we changed was the solution hypothesis. The original hypothesis was "summarize the contract." The new hypothesis was "flag the ten clauses that need lawyer review." The two are not the same. The first replaces the paralegal; the second replaces the checklist. The founder's AI could do the second more reliably than the first.

The third thing we changed was the pre-order test. The founder offered three lawyers a one-week free trial of the AI tool, with no obligation. Two of the three accepted. After one week, one of those two had paid for a month. That one lawyer became the first customer.

The fit was not in the idea. The fit was in the workaround analysis, the reframed hypothesis, and the willingness-to-pay signal from a customer with a real, paid alternative. The polite-yes problem had hidden the fit in the original interviews; the workaround analysis had surfaced it.

The takeaway: the polite-yes problem is real, but it is fixable. The fix is to stop asking customers whether the problem is real and start asking what they have done about it.

FAQ

What is problem-solution fit?

Problem-solution fit is the state in which a defined customer has a real, recurring problem that a defined solution would meaningfully improve — before either the customer or the founder has committed to building or buying anything. The full definition and the five rungs of evidence are in the Startup Validation glossary.

How do startups validate a problem before building a solution?

By testing the six-step framework — Customer → Problem → Pain Signal → Workaround → Solution Hypothesis → Validation Evidence — and stopping to fix each rung before moving to the next. The most common error is skipping the pain-signal and workaround rungs and starting to build on the basis of polite-yes interviews. The method is explained in the canonical How to Validate a Startup Idea Before Building.

What is the difference between problem-solution fit and product-market fit?

Problem-solution fit tests whether the proposed solution addresses a real, recurring problem for a defined customer. Product-market fit tests whether the finished product retains customers and produces organic growth. The two are sequential rungs on the same ladder. Problem-solution fit is the prerequisite for building an MVP (Minimum Viable Product); product-market fit is the prerequisite for scaling acquisition. The full PMF method lives in Product-Market Fit Validation.

How do you know if a problem is worth solving?

A problem is worth solving when the customer has translated the pain into action — they have built a workaround, paid for an alternative, or spent time solving the problem themselves. Customers who just agree the problem is real have not demonstrated pain severity. Customers who can describe a workaround they have tried have demonstrated that the pain is acute enough to act on. The cheapest signal is workaround analysis: ask five potential customers what they have done about the problem, and look for concrete behavior in their answers.

Why do startups fail to identify real problems?

Three reasons, in increasing order of consequence. First, the polite-yes problem — most customers will agree a problem is real to be polite, even when they have not acted on the problem. Rob Fitzpatrick's The Mom Test (2013) is the canonical citation. Second, confirmation bias — the founder asks leading questions that produce the answer they want to hear. Third, building before validating — the founder starts building on the basis of enthusiasm, not workaround analysis. The fix for all three is to ask customers what they have done about the problem, not what they think about the problem.

How long does problem-solution fit validation take?

There is no honest answer. The validation takes as long as it takes to confirm six rungs: a defined customer, a real problem, observable pain, an existing workaround, a proposed solution that would replace the workaround, and a small group of customers who have committed something scarce. For most early-stage teams, the median is between two and six weeks from idea to validated problem-solution fit; the variance is enormous. The right answer is "however long it takes to find five customers with workarounds," not "however long it takes to feel ready."

Can AI predict problem-solution fit?

No. AI is useful for summarizing patterns in customer interviews, drafting interview scripts, and clustering workaround descriptions. It cannot predict whether the proposed solution will address a real problem, because problem-solution fit is a behavioral state that depends on customer workarounds, pain severity, and switching costs the model cannot observe. Treat AI as a tool for the analysis; treat problem-solution fit as a state the founder must earn.

What is a solution hypothesis?

A solution hypothesis is a specific, testable claim about what the proposed product would do for a defined customer. The hypothesis is testable: a founder who can describe what would change for the customer if the solution existed has a hypothesis; a founder who can describe only the product features has a feature list. The full method for testing a solution hypothesis is in the canonical How to Validate a Startup Idea Before Building.

What is the difference between a workaround and an alternative?

A workaround is what the customer does today to address the problem — a spreadsheet, a freelancer, a process, an abandoned workflow. An alternative is a product or service the customer could choose instead. The two are not the same. A customer with a spreadsheet workaround may not have tried the available alternatives; a customer with three abandoned tool subscriptions has tried alternatives and not found one that fits. The validator's job is to map both — workarounds and alternatives — and to identify the gap the proposed solution would fill.

What is a pain point?

A pain point is a specific, observable instance of pain — the moment a customer loses money, time, or opportunity because of a problem. The term is often confused with "problem," but the two are different. A problem is the general category; a pain point is the specific instance. A customer who says "I hate contract review" is naming a problem; a customer who says "I lost a client last month because the contract took three weeks" is naming a pain point. The cheaper signal is the pain point.

What is the difference between a customer pain and a customer need?

A customer need is what the customer would like to have. A customer pain is what the customer is currently losing or struggling with. The two are not the same. A customer who says "I need a better project tracker" is naming a need; a customer who says "I missed two deadlines last quarter because my current tracker does not remind me" is naming a pain. The cheaper signal is the pain, because pain produces action and need often does not.

What is a user need?

A user need is what the user is missing in their current workflow — the gap between what they have and what they would need to solve their problem. The full method for identifying user needs is in the canonical Customer Discovery playbook. The relevant principle here is: a need that does not produce action is not a pain, and pain severity — not need enumeration — is what problem-solution fit tests.

How is problem-solution fit different for B2B vs B2C?

The framework is the same; the benchmarks are different. B2B products typically have smaller customer counts, longer sales cycles, and higher pain thresholds (because businesses have budgets to solve problems). The problem-solution fit signal for B2B is usually a workaround with a measurable cost in employee hours or missed opportunities. B2C products typically have larger customer counts, shorter consideration cycles, and lower per-customer willingness to pay. The problem-solution fit signal for B2C is usually a workaround the customer has built personally — a spreadsheet, a routine, a habit. The B2B-specific playbook lives in How to Validate a B2B Startup Idea Before You Build It.

How is problem-solution fit different for marketplaces?

Marketplaces have two customer segments — supply and demand — and each must reach problem-solution fit independently. A marketplace founder who has confirmed the demand-side problem but not the supply-side problem has half a fit. The two-sided validation method lives in How to Validate a Marketplace Startup Before You Build It.

Can problem-solution fit be lost?

Yes. Problem-solution fit is a state that depends on the relationship between a customer, a problem, and a proposed solution. Move any of the three — change the customer, change the problem, change the proposed solution — and the fit may disappear. Most products lose problem-solution fit as customers find better workarounds, competitors ship better solutions, and customer needs shift. A founder who treats the fit as a one-time check will eventually find the fit has slipped. The discipline of maintaining the fit is the same as the discipline of finding it: re-run the workaround analysis every six months.

How does problem-solution fit relate to customer discovery?

Customer discovery is the discipline of finding and talking to the people who have the problem. Problem-solution fit is the state the discovery conversation is trying to confirm. The two are sequential: discovery produces the interviews; the interviews produce the evidence; the evidence produces the fit. The full discovery playbook lives in How to Find Your First Customers Before You Build. The conversation discipline is in The Mom Test Explained for Solo Founders.

What comes after problem-solution fit?

After problem-solution fit, the founder has earned the right to build an MVP (Minimum Viable Product) — the smallest version of the product that tests the solution hypothesis in the customer's life. The MVP method is in MVP Validation. After the MVP, the next rung is product-market fit, in Product-Market Fit Validation. The framework ladder is: Problem-Solution Fit → MVP → Product-Market Fit → Scale.

How does Startup MRI help with problem-solution fit?

Startup MRI is a structured startup evaluation tool that scores ideas across eight dimensions — market demand, competition, distribution, monetization, build difficulty, founder fit, opportunity, and overall startup score. The tool does not test problem-solution fit directly; problem-solution fit is a customer-facing discipline that requires interviews and workaround analysis. What the tool does is surface the assumptions in the founder's idea that, if wrong, would prevent the solution from addressing a real problem. The full evaluation method lives in How to Validate a Startup Idea Before Building and in Startup MRI's analysis tool.

Summary

Problem-solution fit is the state in which a defined customer has a real, recurring problem that a defined solution would meaningfully improve — before either the customer or the founder has committed to building or buying anything. It is observed in customer behavior, not declared in interviews. The polite-yes problem is real and well-documented; Rob Fitzpatrick's The Mom Test (2013) is the canonical citation.

The six-step validation framework is Customer → Problem → Pain Signal → Workaround → Solution Hypothesis → Validation Evidence. Each rung must hold before the next rung is meaningful. The five rungs of evidence are: customers describe the problem unprompted, customers have built a workaround that costs them time or money, the workaround produces measurable pain the customer names without coaching, the proposed solution would replace the workaround rather than sit beside it, and a small group of those customers commit something scarce in exchange for the solution.

The six failure modes are predictable: polite-yes failure, imaginary-problem failure, feature-asking failure, workarounds-that-actually-work failure, segment-too-broad failure, and solution-irrelevance failure. Each has a recognizable signature; each has a fix that starts with the framework rung that broke.

Problem-solution fit is the rung between market validation and product-market fit. The framework ladder is: Problem-Solution Fit → MVP → Product-Market Fit → Scale. The goal is not to declare the fit. The goal is to find out, in two to six weeks and for under $500 in tooling, whether the proposed solution would address a real, recurring problem the customer has already tried to solve. If it would, build. If it would not, return to the rung that broke.

Related reading

• How to Validate a Startup Idea Before Building — the canonical four-stage framework this article sits inside.
• The Mom Test Explained for Solo Founders — the conversation discipline that surfaces real pain without the polite-yes problem.
• How to Find Your First Customers Before You Build — the customer-discovery playbook that finds the people who have the problem.
• Willingness to Pay Validation — the pricing signal that follows problem-solution fit; pre-orders and paid pilots are the validation-evidence rung.
• How to Test Willingness to Pay Before You Build — the deeper playbook on the six pricing experiments and the seven-day payment plan.
• MVP Validation — the rung that follows problem-solution fit; the smallest version of the product that tests the solution hypothesis.
• Product-Market Fit Validation — the rung that follows the MVP; the four signals and seven failure modes that prove the product retains.
• Startup Validation Checklist — the operational checklist that turns the framework into a 30-day plan.
• Why Founders Build Before Validating — the psychology of skipping the problem-solution fit rung; sunk cost, optimism bias, identification with the idea.
• How to Validate a SaaS Idea Before You Build It — the SaaS-specific assumption stack, including the recurring-revenue cliff.
• How to Validate a B2B Startup Idea Before You Build It — the B2B-specific playbook, including the buying-committee interview and the design-partner path.
• The Startup Validation hub — the full reading path and topical taxonomy.
• The Startup Validation glossary — plain-language definitions of problem-solution fit, customer pain, pain point, user need, and the rest of the validation vocabulary.

What to do next

If you have read this far, the question is what you will do in the next 14 days.

The smallest useful action is a workaround analysis. Find five potential customers and ask each one: "What did you do the last time this problem came up?" Listen for behavior — a spreadsheet, a freelancer, a tool, an abandoned workflow. If four of the five describe a workaround, the problem-solution fit signal is real. If four of the five describe nothing, the polite-yes problem is hiding the signal.

The next action is a solution concept test. Ask the same five customers: "If you could magic away this problem tomorrow, what would change?" Listen for specificity. Customers who can name a specific change have a concrete mental model of the solution; customers who say "anything would help" have not yet identified the gap.

The third action is a pre-order test. Offer the same five customers a one-week free trial at a price that covers the founder's time. Two paying customers out of five is evidence the proposed solution would replace the workaround. Zero is evidence the solution shape was wrong. None of these requires a finished product. None requires permission. None requires a team.

If you would like a structured second opinion on which assumptions in your idea carry the most problem-solution risk before you run the interviews, Startup MRI's validation analysis helps. It takes about five minutes and surfaces the parts of your idea most likely to break under the workaround-analysis rung, so the interviews you run are the ones with the highest signal.

For a worked example of what a real validation report looks like, see the SaaS validation report example, the AI startup validation report example, or the mobile app validation report example. Each shows every section your own report will contain, including the critical-assumption callout.

The right validator landing depends on the audience: the Startup Idea Validator for general ideas, the Startup Idea Evaluator for founders who use "evaluate" as the verb, and the Startup Score Calculator for a numeric 0–100 read on the same eight dimensions.

Behavior is stronger than compliments. Run the workaround analysis. Find the workarounds. Listen for what the customer would switch to.