Primer: What Is Problem–Solution Fit and How Do You Validate It?
TL;DR / Executive Summary
Problem–solution fit is the demonstrated alignment between a customer’s recognized problem and the way your solution resolves it, and it comes before any attempt to scale, fundraise, or formalize a business plan. The concept matters because founders routinely invest months and significant capital building products that customers never adopt, while investors routinely back teams that describe a market without proving that a specific customer group will pay to have a defined problem solved. This primer provides a research-grounded framework for identifying, testing, and validating problem–solution fit before the next stage of company building. It draws on work from Harvard Business School’s research on product-market alignment, the Harvard Innovation Labs demand validation framework, and the jobs-to-be-done method developed at HBS. The primer connects directly to the existing MD-Konsult sequence on the Business Model Canvas, business-model design, business-plan development, and customer-requirement prioritization with MoSCoW, filling the validation step that sits before those tools become useful.
- Problem–solution fit requires evidence that a specific customer group recognizes a problem, actively seeks a solution, and has budget authority to address it.
- Validation happens through structured customer interviews, behavioral observation, prototype testing, and willingness-to-pay confirmation rather than internal conviction.
- Founders who skip this stage risk building a technically sound product that customers never adopt because the problem was never validated as urgent, frequent, or costly enough to matter.
1. What Problem–Solution Fit Means
Problem–solution fit describes the degree to which a proposed solution resolves a problem that a specific group of customers recognizes, experiences repeatedly, and considers important enough to address. The concept sits at the earliest stage of company development, before product-market fit, before scaling, and before any serious capital deployment. Harvard Business School Senior Lecturer Jeffrey Bussgang defines product-market fit as the alignment between a company’s product and its target customers’ needs, which implies that a company must first understand those needs before attempting to align a product with them. Problem–solution fit is the discipline that produces that understanding through direct customer contact, structured questioning, and measurable evidence.
The distinction between problem–solution fit and product-market fit matters because the two concepts answer different questions. Problem–solution fit asks whether the customer has a real problem and whether the proposed solution addresses it effectively. Product-market fit asks whether the broader market embraces the product at a level that supports a viable business. A company can achieve problem–solution fit with a handful of early customers and still lack the market size, distribution efficiency, or unit economics required for product-market fit. Conversely, a company can pursue a large market without first confirming that the problem it addresses carries enough urgency and frequency to justify a purchase decision.
Practically, problem–solution fit requires the founder or team to answer three questions with evidence. First, does the customer recognize that a problem exists? Second, does the customer actively seek a solution or currently use a workaround that costs time, money, or quality? Third, does the customer have the budget and authority to pay for a better solution? The Harvard Innovation Labs framework for validating customer demand organizes these questions into a structured process that focuses on confirming the problem, testing whether the customer is seeking solutions, and evaluating budget availability. These questions provide a practical filter that separates genuine market opportunities from ideas that generate polite interest during a conversation.
2. Why Problem–Solution Fit Matters for Founders and Investors
The commercial case for problem–solution fit rests on a straightforward observation: companies that solve problems customers do not care about fail regardless of how well they execute the technical or operational plan. The HBS working paper Beyond a Technology Lens: Characterizing the Problems Entrepreneurs Solve examined 88,336 U.S. startups and found that 67.9% of identified problem clusters reflect enduring human or organizational needs rather than temporary shifts in technology or regulation. This finding suggests that the strongest startup opportunities often address problems that persist across technology cycles, meaning that a founder who identifies and validates a persistent problem early can build a more durable business than one who chases a fashionable technology category.
Investors should care about problem–solution fit because it provides the earliest reliable signal that a startup addresses a genuine market need rather than an internally compelling idea. The same HBS research found that the ten largest problem clusters absorb roughly one-third of the $2.80 trillion in disclosed venture capital analyzed by the researchers, which means that capital concentrates heavily around recognized problem areas. A founder who can demonstrate problem–solution fit with early customer evidence has a stronger position in a competitive funding environment than one who relies on a technology narrative without customer proof. The HBS entrepreneurship research overview also indicates that founders tend to select problems connected to their own expertise, and that ventures with founder–problem fit raise significantly more capital, which reinforces the importance of domain knowledge in problem identification.
For corporate innovation teams, problem–solution fit offers a structured way to evaluate whether a proposed internal venture addresses a real customer pain or an internal priority that customers do not share. A company can use the same validation framework to test new product lines, service extensions, or digital transformations before committing engineering resources or marketing budget. The process works equally well for a technology company evaluating a new software feature, a healthcare organization testing a patient-experience improvement, or a manufacturer exploring a maintenance-service offering. The common thread is that the team must identify a specific customer group, define the problem in the customer’s language, and gather evidence that the customer will change behavior or spend money to resolve it.
3. How to Validate Problem–Solution Fit
Validation of problem–solution fit follows a structured sequence that moves from problem identification through customer contact to measurable evidence. The process does not require a finished product, a formal business plan, or a large research budget. It requires discipline in asking the right questions, recording customer responses accurately, and interpreting the results without confirmation bias. The HBS Rock Center customer discovery framework emphasizes that interviewing target personas is one of several ways to validate assumptions about pain points and to confirm that those personas represent the right customer segment.
Step 1: Define the Problem in the Customer’s Language
The first step requires the team to state the problem in terms that a customer would use to describe their own experience. This means avoiding internal jargon, product-feature language, or technology categories and instead focusing on the operational, financial, or emotional cost the customer bears. A healthcare administrator does not describe a problem as “a need for better data integration”; they describe it as “I spend three hours every morning reconciling patient records across systems that do not talk to each other.” A supply-chain manager does not describe a problem as “a need for real-time visibility”; they describe it as “I find out about a delayed shipment after the customer has already called to complain.” The difference between these formulations matters because the customer’s language reveals the specific context, frequency, and cost of the problem, which the team needs to evaluate its validity.
The jobs-to-be-done framework developed at HBS by Clayton Christensen provides a useful tool for this step. Christensen defined a job to be done as “a problem or opportunity that somebody is trying to solve” and emphasized that customers “hire” products to accomplish specific tasks in specific circumstances. The framework encourages teams to complete statements such as “Help me…” or “I need to…” from the customer’s perspective, which forces the problem definition to reflect the customer’s situation rather than the company’s product roadmap. A team that can complete these statements with specific, observable customer evidence has a stronger foundation for problem–solution fit than one that begins with a technology capability and searches for a problem to attach to it.
Step 2: Identify and Interview the Right Customers
The second step involves identifying the specific customer segment that experiences the problem most acutely and conducting structured interviews to test whether the problem exists as the team understands it. The Harvard Innovation Labs validation framework recommends focusing on three questions during customer interviews: whether the customer recognizes the problem, whether the customer is actively seeking a solution, and whether the customer has budget to address it. These questions provide a practical filter that separates genuine opportunities from situations where customers acknowledge a problem but have no intention of paying to solve it.
The quality of the interview process matters as much as the questions asked. The Harvard Innovation Labs guidance emphasizes asking non-leading questions that focus on the customer’s experiences rather than their opinions about the proposed solution. Instead of asking “Would you buy this product?” the team should ask “What challenges do you face in this area?” or “How do you handle this situation today?” This approach reduces the risk of receiving polite but misleading positive feedback and instead produces information the team can use to refine its understanding of the problem. The guidance also suggests that volunteering or directly working with target customers can provide firsthand experience of their pain points, which strengthens the team’s ability to design a relevant solution.
A practical interview protocol includes a consistent set of questions across all interviews, a recording method that preserves the customer’s exact language, and a structured way to categorize responses. The team should interview at least 15 to 25 potential customers within the target segment before drawing conclusions, because a handful of enthusiastic responses from early contacts can create false confidence. The interviews should focus on the customer’s current behavior, the cost of the problem, the alternatives the customer currently uses, and the circumstances that would cause the customer to seek a better solution. The team should avoid presenting the product or solution during these interviews, because the goal is to understand the problem before evaluating the solution.
Step 3: Test the Solution with a Minimum Viable Product
The third step involves creating the smallest version of the solution that can deliver the core value proposition and testing it with real customers. This is not a marketing exercise or a formal product launch. It is a learning exercise designed to test whether the solution resolves the problem in a way that customers find valuable enough to continue using or paying for. The Lean Startup framework describes a six-step process that includes determining the target customer, identifying underserved needs, defining the value proposition, specifying the minimum viable product feature set, creating a prototype, and testing it with customers. This sequence ensures that the team builds only what is necessary to test its core assumptions before investing in additional features or infrastructure.
The minimum viable product should focus on the single most important customer outcome that the problem–solution fit hypothesis predicts. If the team believes that a supply-chain manager will pay for earlier notification of shipment delays, the minimum viable product should deliver that notification with enough reliability and speed to test the customer’s willingness to use it. The team does not need to build a full dashboard, integrate with every transportation management system, or create a mobile application. It needs to deliver the core value proposition in the simplest possible form and observe whether customers use it, return to it, and recommend it to others.
Step 4: Measure Willingness to Pay and Behavioral Evidence
The fourth step involves collecting measurable evidence that customers will pay for the solution or change their behavior in a way that validates the problem–solution fit hypothesis. The Harvard Innovation Labs framework identifies a key metric as the percentage of customers who would be “very disappointed” if they could no longer use the product, with a 40% or higher rate indicating strong product-market fit. For problem–solution fit specifically, the team should look for evidence that customers recognize the problem, actively use the solution, and express willingness to pay or invest time in a way that confirms the problem matters.
Behavioral evidence carries more weight than stated intentions. A customer who says they would pay for a solution provides weaker evidence than one who actually signs a contract, completes a purchase, or integrates the solution into a daily workflow. A customer who says the problem is important provides weaker evidence than one who has already spent money or time on a workaround. The team should track concrete behaviors such as sign-ups, pilot agreements, paid trials, workflow integration, and repeat usage. These behaviors provide the strongest possible evidence that the problem–solution fit hypothesis is valid.
The team should also look for negative evidence with equal rigor. If customers acknowledge the problem but do not use the solution, the team should investigate whether the solution addresses the problem effectively or whether the problem lacks sufficient urgency to drive adoption. If customers use the solution but do not pay for it, the team should investigate whether the pricing model aligns with the customer’s budget authority or whether the solution delivers enough value to justify a purchase. Negative evidence at this stage is more valuable than positive evidence at a later stage, because it allows the team to redirect resources before significant capital is committed.
4. Common Mistakes That Undermine Problem–Solution Fit
Founders and teams make several predictable mistakes when attempting to validate problem–solution fit. The most common mistake is confusing customer interest with customer demand. A customer who says “That sounds interesting” or “I would definitely try that” has not demonstrated willingness to pay, willingness to change behavior, or willingness to integrate the solution into an existing workflow. The team must distinguish between politeness and genuine demand by observing actual behavior rather than relying on verbal expressions of interest.
A second common mistake is testing the solution before validating the problem. Teams that begin with a technology or product concept and search for a problem to attach to it often find customers who are willing to discuss the product but who do not experience the problem with sufficient frequency or cost to justify a purchase. The HBS research on entrepreneurial problem selection found that individual problems attract multiple technologies and participants from several industries, which means that a technology-first approach can obscure the underlying customer need. Teams that start with the problem and then evaluate which technology can solve it most effectively produce more reliable evidence of problem–solution fit.
A third common mistake is relying on a small sample of enthusiastic early customers without testing whether the broader market shares the same problem. Early adopters often tolerate incomplete solutions, invest time in learning new tools, and provide positive feedback that does not reflect the experience of the average customer. The team should test the problem–solution fit hypothesis across a range of customer types within the target segment, including customers who are less technically sophisticated, less motivated, or less willing to change established workflows. This broader testing provides a more accurate picture of whether the problem is widespread enough to support a viable business.
A fourth common mistake is ignoring the competitive landscape during validation. Customers rarely face a problem with no available solution, even if the existing solutions are inadequate. The team should identify what customers currently use to address the problem, how much they spend on those alternatives, and what dissatisfaction they express. This competitive analysis provides context for the value proposition and helps the team understand what improvement customers would need to see before switching from an existing solution to a new one.
5. Connecting Problem–Solution Fit to the Broader Business-Building Process
Problem–solution fit does not exist in isolation. It connects directly to the business-model, business-plan, and prioritization frameworks that founders and teams use to build and scale a company. Once the team has validated that a specific customer group recognizes a problem, actively seeks a solution, and has budget to pay for it, the next step is to design a business model that captures value from solving that problem. The MD-Konsult Business Model Canvas primer provides a structured way to connect the validated customer problem to a customer segment, value proposition, channel, revenue model, and operating model. The canvas becomes useful only after the team has validated the problem, because it requires specific answers about customer segments, value propositions, and revenue streams that depend on accurate problem understanding.
The MD-Konsult business-model primer provides a broader framework for thinking about how a company creates and captures value, which the team can use to test whether the problem–solution fit translates into a sustainable business model. A company can achieve problem–solution fit and still fail to build a viable business if the cost of acquiring customers exceeds the revenue those customers generate, if the market is too small to support the operating model, or if competitors can replicate the solution at lower cost. The business-model framework helps the team test these questions before committing to a specific plan.
The MD-Konsult business-plan primer provides the next step in the sequence, translating the validated problem, business model, and market opportunity into a formal plan that can support fundraising, team building, and execution. A business plan written before problem–solution fit validation is speculative; a business plan written after validation is evidence-based. The MD-Konsult MoSCoW prioritization primer then helps the team prioritize which features and capabilities to build based on customer requirements, ensuring that development resources focus on the capabilities that matter most to the validated customer problem.
6. Real-World Examples of Problem–Solution Fit
Zipline’s medical delivery service in Rwanda provides a concrete example of problem–solution fit validation in action. The problem is specific and measurable: health facilities in rural Rwanda face difficulty obtaining vaccines, blood, and medical supplies through conventional ground logistics, which creates delays that can affect patient outcomes. The Rwanda Biomedical Center and Zipline vaccine program addressed this problem through on-demand drone deliveries, reaching 119 health posts during its first ten months and delivering 76,182 vaccine doses to rural communities in 2024. The company reports that delivery cost declined from $1.87 per dose using traditional ground logistics to $0.24 per dose with its service, which provides a measurable economic outcome that validates the problem–solution fit hypothesis. The problem existed before Zipline built its technology, and the solution addresses the problem in a way that produces a quantifiable improvement in cost and availability.
Stripe provides a different example of problem–solution fit in a technology market. The problem is that businesses need a reliable way to accept payments, manage billing, and access revenue as they expand across borders and business models. Stripe reports that businesses using its platform generated $1.9 trillion in total payments volume in 2025, an increase of 34% from 2024, while its revenue-products suite approached a $1 billion annual run rate in 2026. The company’s 2025 annual letter describes the problem in terms of business friction: companies need to collect payments, manage subscriptions, handle taxes, and access working capital without building internal financial infrastructure. Stripe’s solution addresses this problem through a platform that combines payments, billing, and financial tools, and the reported growth figures provide evidence that customers find the solution valuable enough to process significant transaction volume through it.
MIT Sloan’s September 2026 delta v cohort provides examples of early-stage problem–solution fit testing. The Trade Lab addresses the problem that importers face when interpreting tariff and customs requirements for specific products and supply chains. Exo AI addresses the problem that smaller financial institutions face when processing commercial loan applications manually. Gander Robotics addresses the problem of rapid response when someone falls overboard from a vessel. Each of these startups identified a specific customer problem, developed a solution that addresses it, and tested the solution with early customers before raising significant capital. The cohort collectively raised nearly $20 million and increased revenue by 139% during the accelerator, which suggests that the problem–solution fit validation process produced companies that investors found credible enough to fund.
7. Frequently Asked Questions
What is problem–solution fit?
Problem–solution fit is the demonstrated alignment between a customer’s recognized problem and the way your solution resolves it. It requires evidence that a specific customer group experiences the problem with sufficient frequency and cost to justify paying for a better solution. The concept sits at the earliest stage of company development, before product-market fit and before any significant capital deployment.
How do you validate problem–solution fit?
Validation requires four steps: define the problem in the customer’s language, identify and interview the right customers, test the solution with a minimum viable product, and measure willingness to pay and behavioral evidence. The Harvard Innovation Labs validation framework recommends asking whether the customer recognizes the problem, is actively seeking a solution, and has budget to address it. Behavioral evidence such as paid trials, workflow integration, and repeat usage provides stronger validation than verbal expressions of interest.
What is the difference between problem–solution fit and product-market fit?
Problem–solution fit asks whether the customer has a real problem and whether the proposed solution addresses it effectively. Product-market fit asks whether the broader market embraces the product at a level that supports a viable business. HBS Senior Lecturer Jeffrey Bussgang defines product-market fit as the alignment between a company’s product and its target customers’ needs, which implies that problem–solution fit must precede product-market fit. A company can achieve problem–solution fit with a handful of early customers and still lack the market size or unit economics required for product-market fit.
How many customer interviews are enough to validate a problem?
A practical guideline is to conduct at least 15 to 25 structured interviews within the target customer segment before drawing conclusions about problem–solution fit. The HBS Rock Center customer discovery framework emphasizes that interviewing target personas is one of several ways to validate assumptions about pain points. The interviews should focus on the customer’s current behavior, the cost of the problem, the alternatives the customer uses, and the circumstances that would cause the customer to seek a better solution.
What is a minimum viable product?
A minimum viable product is the smallest version of the solution that can deliver the core value proposition and test the problem–solution fit hypothesis with real customers. The Lean Startup framework describes a six-step process that includes determining the target customer, identifying underserved needs, defining the value proposition, specifying the minimum viable product feature set, creating a prototype, and testing it with customers. The minimum viable product should focus on the single most important customer outcome that the problem–solution fit hypothesis predicts.
How do you measure willingness to pay?
Willingness to pay can be measured through behavioral evidence such as paid trials, pilot agreements, signed contracts, workflow integration, and repeat usage. The Harvard Innovation Labs framework identifies a key metric as the percentage of customers who would be “very disappointed” if they could no longer use the product, with a 40% or higher rate indicating strong product-market fit. For problem–solution fit specifically, the team should look for evidence that customers recognize the problem, actively use the solution, and express willingness to pay or invest time in a way that confirms the problem matters.
What are common mistakes in problem–solution fit validation?
Common mistakes include confusing customer interest with customer demand, testing the solution before validating the problem, relying on a small sample of enthusiastic early customers, and ignoring the competitive landscape. The HBS research on entrepreneurial problem selection found that individual problems attract multiple technologies and participants from several industries, which means that a technology-first approach can obscure the underlying customer need. Teams that start with the problem and then evaluate which technology can solve it most effectively produce more reliable evidence of problem–solution fit.
How does problem–solution fit connect to the Business Model Canvas?
Problem–solution fit provides the validated customer problem that the Business Model Canvas requires as input. The canvas becomes useful only after the team has validated the problem, because it requires specific answers about customer segments, value propositions, and revenue streams that depend on accurate problem understanding. A company can use the canvas to test whether the validated problem translates into a sustainable business model by examining the cost of customer acquisition, the size of the addressable market, and the competitive landscape.
