Primer: What Is Founder–Problem Fit and Why Does It Matter to Investors?

MD-Konsult Technology & Business Research | Primer Series

TL;DR / Executive Summary

Founder–problem fit describes the alignment between a founder’s professional experience, domain knowledge, and operational insight and the specific customer problem the venture addresses. The concept matters because investors routinely evaluate team quality, market size, and product differentiation without systematically assessing whether the founding team possesses the direct experience required to understand the problem deeply enough to build a credible solution. A September 2026 Harvard Business School working paper examining 88,336 U.S. startups found that founders are about five times more likely to pursue problems linked to their occupational background than a randomly assigned founder, and that ventures with founder–problem fit raise roughly 9% to 13% more capital than otherwise comparable founders. MIT Sloan research on founder age and experience found that a 50-year-old founder is 1.8 times more likely to achieve upper-tail growth than a 30-year-old founder, and that founders with at least three years of experience in the startup’s industry see substantially greater success rates. HBS Professor Tom Eisenmann’s research on startup failure identifies founder–problem fit as a critical factor in avoiding the “false start” pattern that accounts for many early-stage failures. This primer connects directly to the existing MD-Konsult sequence on Business Model Canvas, business-model design, business-plan development, and customer-requirement prioritization with MoSCoW, filling the founder-assessment step that sits alongside problem validation.

• Founder–problem fit requires evidence that the founding team possesses direct experience with the customer problem, the operational context, and the buyer decision process.
• Validation happens through structured founder background review, customer reference checks, operational scenario testing, and evidence that the team can navigate the specific constraints of the problem space.
• Investors who skip this assessment risk backing technically capable teams that lack the domain knowledge required to build a credible solution or navigate the operational complexity of the problem space.

1. What Founder–Problem Fit Means

Founder–problem fit describes the degree to which a founder’s professional experience, domain knowledge, operational insight, and buyer relationships align with the specific customer problem the venture addresses. The concept sits at the earliest stage of investment evaluation, alongside problem–solution fit and before any serious capital deployment. The HBS working paper on entrepreneurial problem selection found that founders are about five times more likely to pursue problems linked to their occupational background than a randomly assigned founder, which suggests that founder experience plays a material role in problem identification and solution design.

The distinction between founder–problem fit and founder–market fit matters because the two concepts answer different questions. Founder–problem fit asks whether the founding team possesses the direct experience required to understand the problem deeply enough to build a credible solution. Founder–market fit asks whether the founding team possesses the broader market knowledge, distribution relationships, and competitive insight required to build a viable business. A founder can achieve founder–problem fit by having worked in the specific operational environment where the problem exists, while lacking the broader market knowledge required to scale the business. Conversely, a founder can possess strong market knowledge without understanding the specific operational constraints that make the problem difficult to solve.

Practically, founder–problem fit requires the investor or diligence team to answer three questions with evidence. First, does the founder possess direct professional experience with the customer problem? Second, does the founder understand the operational context, buyer decision process, and constraint environment that make the problem difficult to solve? Third, does the founder possess the buyer relationships, operational credibility, and domain knowledge required to navigate the problem space effectively? The HBS research found that ventures with founder–problem fit raise roughly 9% to 13% more capital than otherwise comparable founders, which suggests that investors recognize and reward this alignment.

2. Why Founder–Problem Fit Matters for Investors

The commercial case for founder–problem fit rests on a straightforward observation: founders who understand the problem deeply can build more credible solutions, navigate operational constraints more effectively, and earn customer trust more quickly than founders who lack direct experience. The MIT Sloan research on founder age and experience found that a 50-year-old founder is 1.8 times more likely to achieve upper-tail growth than a 30-year-old founder, and that founders with at least three years of experience in the startup’s industry see substantially greater success rates. The research also found that founders with closer and longer experience in the specific industrial sector of the startup see substantially greater success rates, with founders having no experience in the two-digit industry achieving a 0.11% success rate for creating a one-in-1,000 highest-growth firm.

Investors should care about founder–problem fit because it provides an early signal that the founding team can navigate the operational complexity, buyer decision process, and constraint environment that make the problem difficult to solve. The HBS research on startup failure identifies founder–problem fit as a critical factor in avoiding the “false start” pattern that accounts for many early-stage failures. Professor Tom Eisenmann’s research found that many startups fail because founders rush to build products without conducting sufficient customer research, and that founders lacking domain expertise are more likely to make this mistake. The research also found that founders who lack domain expertise in spaces that require it face significantly higher failure rates than founders who possess the relevant experience.

For corporate innovation teams, founder–problem fit offers a structured way to evaluate whether an internal venture team possesses the direct experience required to build a credible solution. A company can use the same assessment framework to evaluate whether the team understands the customer problem deeply enough to navigate operational constraints, earn buyer trust, and design a solution that customers will adopt. The process works equally well for a technology company evaluating a new software venture, a healthcare organization testing a patient-experience improvement, or a manufacturer exploring a maintenance-service offering. The common thread is that the team must possess direct experience with the problem space or compensate for that gap through hiring, partnerships, or advisory relationships.

3. How to Assess Founder–Problem Fit

Assessment of founder–problem fit follows a structured sequence that moves from founder background review through customer reference checks to operational scenario testing. The process does not require a formal business plan, a large research budget, or a lengthy diligence process. It requires discipline in asking the right questions, verifying founder claims through independent sources, and interpreting the results without confirmation bias.

Step 1: Review Founder Background for Direct Problem Experience

The first step requires the investor or diligence team to examine the founder’s professional background for direct experience with the customer problem. This means looking beyond job titles and company names to understand what the founder actually did, what problems the founder encountered, and what operational constraints the founder navigated. A founder who worked as a supply-chain manager at a logistics company possesses different problem experience than a founder who worked as a consultant advising logistics companies. A founder who built software for healthcare administrators possesses different problem experience than a founder who used software as a healthcare administrator.

The HBS research on entrepreneurial problem selection found that founders sort into problems that benefit from their own expertise, which suggests that founder background plays a material role in problem identification. The research also found that ventures with founder–problem fit raise significantly more capital, which suggests that investors recognize and reward this alignment. The diligence team should examine the founder’s background for evidence of direct problem exposure, including roles that involved managing the problem, solving the problem, or advising others on how to solve the problem.

The team should also examine the founder’s background for evidence of operational credibility, including roles that required navigating the constraint environment, managing the buyer decision process, or earning customer trust. A founder who worked in a regulated industry possesses different credibility than a founder who worked in an unregulated industry. A founder who managed a complex operational process possesses different credibility than a founder who advised others on how to manage that process. The team should verify these claims through independent sources, including former colleagues, customers, and industry contacts.

Step 2: Conduct Customer Reference Checks

The second step involves conducting structured reference checks with customers, former colleagues, and industry contacts to verify the founder’s problem experience and operational credibility. The HBS Rock Loan Reduction Program evaluates founder commitment and venture viability through a structured process that includes faculty recommendations, pitch deck review, and evidence of founder alignment with long-term career goals. The program’s selection criteria emphasize the match between the applicant’s background and previous experience as evidence of commitment to the venture and potential to succeed.

The reference check process should focus on three questions. First, does the founder possess the direct problem experience claimed? Second, does the founder possess the operational credibility required to navigate the constraint environment? Third, does the founder possess the buyer relationships and domain knowledge required to earn customer trust? The team should conduct these reference checks with a consistent set of questions, record responses accurately, and verify claims through multiple independent sources.

The team should also examine the founder’s network for evidence of buyer relationships, operational contacts, and industry credibility. A founder who possesses strong relationships with potential customers possesses different credibility than a founder who lacks those relationships. A founder who possesses strong relationships with operational partners possesses different credibility than a founder who lacks those relationships. The team should verify these relationships through independent sources and examine whether the founder can leverage those relationships to accelerate customer acquisition, partnership development, or operational problem-solving.

Step 3: Test Operational Scenario Knowledge

The third step involves testing the founder’s knowledge of the operational scenarios, constraint environments, and buyer decision processes that make the problem difficult to solve. The MIT Sloan 2026 startup cohort provides examples of founders who possess direct problem experience. The Trade Lab addresses tariff and customs requirements for importers, a problem that requires direct experience with trade compliance, supply-chain operations, and regulatory navigation. Exo AI addresses manual commercial lending workflows, a problem that requires direct experience with credit analysis, loan processing, and financial-institution operations. Gander Robotics addresses rapid response to maritime emergencies, a problem that requires direct experience with vessel operations, emergency response, and maritime safety protocols.

The operational scenario testing process should focus on three questions. First, can the founder describe the specific operational scenarios that make the problem difficult to solve? Second, can the founder describe the constraint environment, buyer decision process, and competitive landscape that shape the problem? Third, can the founder describe the operational workarounds, existing solutions, and failure modes that customers currently experience? The team should test these questions through structured interviews, scenario walkthroughs, and operational deep-dives that require the founder to demonstrate detailed knowledge of the problem space.

The team should also examine the founder’s ability to navigate the specific constraints of the problem space. A founder who understands the regulatory environment, operational constraints, and buyer decision process can design a solution that customers will adopt more quickly than a founder who lacks that understanding. A founder who understands the competitive landscape, existing solutions, and failure modes can design a solution that differentiates more effectively than a founder who lacks that understanding. The team should test these capabilities through scenario-based questions, operational walkthroughs, and competitive analysis exercises.

4. Common Mistakes That Undermine Founder–Problem Fit Assessment

Investors and diligence teams make several predictable mistakes when attempting to assess founder–problem fit. The most common mistake is confusing founder charisma with founder credibility. A founder who presents well, communicates effectively, and generates enthusiasm has not necessarily demonstrated the direct problem experience, operational credibility, or buyer relationships required to build a credible solution. The team must distinguish between presentation quality and problem knowledge by testing the founder’s operational understanding, verifying background claims, and conducting independent reference checks.

A second common mistake is assessing founder–problem fit without examining the specific operational constraints that make the problem difficult to solve. A founder who possesses general industry experience may lack the specific problem experience required to navigate the operational complexity, regulatory environment, or buyer decision process. The HBS research on startup failure found that founders lacking domain expertise in spaces that require it face significantly higher failure rates, and that the need for domain expertise depends on the complexity of operations in the specific problem space.

A third common mistake is relying on a small sample of positive references without testing whether the broader network shares the same assessment. A founder who provides three enthusiastic references has not necessarily demonstrated the operational credibility, buyer relationships, or problem experience required to build a credible solution. The team should conduct reference checks across a range of sources, including former colleagues, customers, industry contacts, and operational partners. The team should also examine the founder’s network for evidence of buyer relationships, operational contacts, and industry credibility.

A fourth common mistake is ignoring the team composition during assessment. A single founder who possesses strong problem experience may lack the operational expertise, technical capability, or buyer relationships required to build a credible solution. The team should examine whether the founding team collectively possesses the direct problem experience, operational credibility, and buyer relationships required to navigate the problem space. The team should also examine whether the founding team can compensate for gaps through hiring, partnerships, or advisory relationships.

5. Connecting Founder–Problem Fit to the Broader Investment Process

Founder–problem fit does not exist in isolation. It connects directly to the problem-validation, business-model, and business-plan frameworks that investors and founders use to build and scale a company. Once the investor has assessed that the founding team possesses the direct problem experience, operational credibility, and buyer relationships required to build a credible solution, the next step is to validate that the problem exists and that the solution addresses it effectively. 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 MD-Konsult business-model primer provides a broader framework for thinking about how a company creates and captures value, which the investor can use to test whether the founder–problem fit translates into a sustainable business model. A founder who possesses strong problem experience may 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 investor test these questions before committing to a specific investment.

The MD-Konsult business-plan primer provides the next step in the sequence, translating the validated problem, founder–problem fit, and business model into a formal plan that can support fundraising, team building, and execution. A business plan written before founder–problem fit assessment is speculative; a business plan written after assessment 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 Founder–Problem Fit

Zipline’s medical delivery service in Rwanda provides a concrete example of founder–problem fit in action. The founder, Keller Rinaudo, possessed direct experience with robotics, autonomous systems, and healthcare logistics before founding the company. The Rwanda Biomedical Center and Zipline vaccine program addressed the problem that health facilities in rural Rwanda face difficulty obtaining vaccines, blood, and medical supplies through conventional ground logistics. 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 founder’s problem understanding. The founder’s background in robotics and autonomous systems provided the technical credibility required to design a solution that addresses the problem, while the company’s operational partnerships with the Rwanda Biomedical Center provided the domain knowledge required to navigate the healthcare logistics environment.

Stripe provides a different example of founder–problem fit in a technology market. The founders, Patrick and John Collison, possessed direct experience with software development, payment systems, and online commerce before founding the company. The Stripe 2025 annual letter describes the problem that businesses need a reliable way to accept payments, manage billing, and access revenue as they expand across borders and business models. The company reports that businesses using its platform generated $1.9 trillion in total payments volume in 2025, an increase of 34% from 2024, which provides evidence that the founders understood the problem deeply enough to build a solution that customers find valuable. The founders’ background in software development and online commerce provided the technical credibility required to design a solution that addresses the problem, while the company’s operational partnerships with financial institutions provided the domain knowledge required to navigate the payments environment.

MIT Sloan’s September 2026 delta v cohort provides examples of early-stage founder–problem fit testing. The Trade Lab addresses tariff and customs requirements for importers, a problem that requires direct experience with trade compliance, supply-chain operations, and regulatory navigation. Exo AI addresses manual commercial lending workflows, a problem that requires direct experience with credit analysis, loan processing, and financial-institution operations. Gander Robotics addresses rapid response to maritime emergencies, a problem that requires direct experience with vessel operations, emergency response, and maritime safety protocols. Each of these startups identified a specific customer problem, assembled a founding team with relevant problem experience, and tested the solution with early customers before raising significant capital.

7. Frequently Asked Questions

What is founder–problem fit?

Founder–problem fit is the alignment between a founder’s professional experience, domain knowledge, and operational insight and the specific customer problem the venture addresses. It requires evidence that the founding team possesses direct experience with the customer problem, the operational context, and the buyer decision process. The concept sits at the earliest stage of investment evaluation, alongside problem–solution fit and before any serious capital deployment.

How do you assess founder–problem fit?

Assessment requires three steps: review founder background for direct problem experience, conduct customer reference checks, and test operational scenario knowledge. The HBS research on entrepreneurial problem selection found that founders are about five times more likely to pursue problems linked to their occupational background than a randomly assigned founder, which suggests that founder experience plays a material role in problem identification. The assessment should focus on the founder’s direct problem exposure, operational credibility, and buyer relationships.

What is the difference between founder–problem fit and founder–market fit?

Founder–problem fit asks whether the founding team possesses the direct experience required to understand the problem deeply enough to build a credible solution. Founder–market fit asks whether the founding team possesses the broader market knowledge, distribution relationships, and competitive insight required to build a viable business. A founder can achieve founder–problem fit by having worked in the specific operational environment where the problem exists, while lacking the broader market knowledge required to scale the business.

How much capital do ventures with founder–problem fit raise?

The HBS research on entrepreneurial problem selection found that ventures with founder–problem fit raise roughly 9% to 13% more capital than otherwise comparable founders. This finding suggests that investors recognize and reward founder–problem fit, although the research does not establish that founder–problem fit causes higher valuations or better outcomes. The finding does provide a reason to investigate founder experience as part of the diligence process.

What role does founder age play in founder–problem fit?

The MIT Sloan research on founder age and experience found that a 50-year-old founder is 1.8 times more likely to achieve upper-tail growth than a 30-year-old founder, and that founders with at least three years of experience in the startup’s industry see substantially greater success rates. The research also found that founders with closer and longer experience in the specific industrial sector of the startup see substantially greater success rates. These findings suggest that founder age and experience play a material role in founder–problem fit, although the relationship is not linear and depends on the specific problem space.

What are common mistakes in founder–problem fit assessment?

Common mistakes include confusing founder charisma with founder credibility, assessing founder–problem fit without examining the specific operational constraints that make the problem difficult to solve, relying on a small sample of positive references without testing whether the broader network shares the same assessment, and ignoring the team composition during assessment. The HBS research on startup failure found that founders lacking domain expertise in spaces that require it face significantly higher failure rates, which suggests that domain knowledge plays a material role in founder–problem fit.

How does founder–problem fit connect to the Business Model Canvas?

Founder–problem fit provides the founder assessment that the Business Model Canvas requires as input. The canvas becomes useful only after the investor has assessed that the founding team possesses the direct problem experience, operational credibility, and buyer relationships required to build a credible solution. A founder who possesses strong problem experience may 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.

8. Related MD-Konsult Reading

• Primer: What Is a Business Model Canvas and How Does It Support Strategic Decisions?
• Primer: What Is a Business Model and How Should Leaders Build One?
• Primer: What Is a Business Plan and How to Write It
• Primer: How to Prioritize Customer Requirements Using MoSCoW
• MD-Konsult Business Primers

Read More

Primer: What Is Problem–Solution Fit and How Do You Validate It?

MD-Konsult Technology & Business Research | Primer Series

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.

8. Related MD-Konsult Reading

• Primer: What Is a Business Model Canvas and How Does It Support Strategic Decisions?
• Primer: What Is a Business Model and How Should Leaders Build One?
• Primer: What Is a Business Plan and How to Write It
• Primer: How to Prioritize Customer Requirements Using MoSCoW
• MD-Konsult Business Primers

Read More

Primer – How to Use Claude Code on Windows 11 (Paid & Free)

Primer – How To Use Claude Code on a Windows 11 Laptop (With and Without Subscriptions)

Questions addressed by this primer:

• What is Claude Code and how is it different from “regular” Claude?
• How do you install Claude Code on a Windows 11 personal laptop using VS Code?
• How do you use Claude Code with a paid Claude subscription (Pro / Max or API)?
• How do you use a Claude Code–style setup without a Claude subscription, using free local models via Ollama?
• What are the pros and cons of paid vs free Claude Code setups for individual developers and small teams?

---

What is Claude Code?

Claude Code is an AI coding assistant built around Anthropic’s Claude models that integrates directly into your developer workflow. Unlike chatting with Claude in a browser, Claude Code is designed to:

• Read and understand your entire codebase (or large parts of it).
• Propose multi‑file changes, including generating new files and refactoring existing ones.
• Apply those changes automatically (with your approval) through your editor or the command line.

From a developer’s perspective, Claude Code gives you:

• A “pair programmer” that can see the same files and project structure as you.
• A refactoring engine that can plan and execute series of edits.
• A teacher that can explain unfamiliar code, libraries, and frameworks in natural language.

The key design idea is that Claude Code is agentic: it does not just answer questions; it can plan steps, propose patches, and then apply those patches to your repository.

---

Pre‑requisites: What you need before installing Claude Code

Before you install and use Claude Code on a Windows 11 personal laptop, you need a few basic components in place.

1. Windows 11 and a browser

• Confirm that your machine is running Windows 11.
  • Go to Start → Settings → System → About and check the version.
• Ensure you have a modern browser such as Microsoft Edge, Google Chrome, or Firefox for downloading tools and signing into accounts.

2. Visual Studio Code (VS Code)

Claude Code integrates most naturally with Visual Studio Code (VS Code), which is free and widely used. To install VS Code on Windows 11:

1. Open your browser and go to the official Visual Studio Code website (search for “Download Visual Studio Code” and select the official result).
2. Click “Download for Windows” and save the installer.
3. Once downloaded, double‑click the installer file (for example VSCodeUserSetup‑x64‑…exe).
4. Accept the license agreement and keep the default options.
5. Click “Install”, then “Finish” to launch VS Code.

You should now see the VS Code welcome screen.

---

Using Claude Code with a Claude subscription (Pro / Max / API)

In this section, we cover the “official” way to use Claude Code: you call Anthropic’s Claude models through a paid plan or API. This is similar to how cloud‑hosted coding copilots operate.

Claude subscription and API options

As of 2026, Anthropic provides two main access paths for individuals and small teams:

• Claude consumer subscription (Pro / Max)
  • Pro: monthly subscription with higher usage limits than the free tier, suitable for regular coding work.
  • Max: premium tier for heavy users (e.g., production developers, power users).
• Claude API (pay‑as‑you‑go)
  • You create an API key in Anthropic’s developer portal.
  • You pay per token for models like Claude Haiku, Sonnet, or Opus.

Claude Code can work with both: either it signs you in via browser (using your Pro/Max account), or it uses an API key you configure.

---

Step 1 – Create your Claude account and (optionally) subscribe

1. Open your browser and search for “Claude AI”.
2. Go to the official Anthropic Claude website.
3. Click “Sign up” or “Get started”.
4. Create an account with your email and password; verify your email.

To subscribe:

1. Inside the Claude app, go to “Account”, “Billing”, or “Plans”.
2. Choose a plan such as Claude Pro or Claude Max.
3. Enter your payment information and confirm.

To enable the API:

1. Go to the “Developer” or “API” section of your Anthropic/Claude account.
2. Click “Create API key”.
3. Copy the key and store it securely.
4. (Optional) Set up billing if you want to go beyond free or trial credits.

---

Step 2 – Install the Claude Code extension in VS Code

Anthropic provides an official Claude Code extension for VS Code. To install:

1. Open VS Code.
2. Click the “Extensions” icon on the left (four squares) or press Ctrl + Shift + X.
3. In the search bar at the top, type: Claude Code.
4. Locate the extension published by Anthropic.
5. Click “Install”.
6. If prompted, click “Reload” to activate the extension.

Alternatively:

1. Visit the official Claude Code extension page in the Visual Studio Marketplace.
2. Click “Install” on the web page.
3. Allow it to open VS Code and complete the installation.

---

Step 3 – Connect Claude Code to your Claude account or API key

Once the extension is installed, you configure it to talk to Claude’s servers.

1. In VS Code, press Ctrl + Shift + P to open the Command Palette.
2. Type Claude Code to filter commands related to the extension.
3. Run a command such as “Claude Code: Open Settings” or “Claude Code: Sign in”.

You will typically see two main options:

• Sign in with your Claude account (Pro / Max)
  • Click “Sign in”.
  • A browser window opens.
  • Log in with the same email and password you used for Claude.
  • Confirm that you want to allow the extension access.
• Use an Anthropic API key
  • Enter your API key into the text box for API token.
  • Save the settings.

Once configured, the extension can call Claude models on your behalf.

---

Step 4 – Run your first Claude Code session in VS Code

To test Claude Code with your subscription or API:

1. Create a folder on your machine, for example C:\Users\<your‑name>\Desktop\ClaudeDemo.
2. Open VS Code and go to File → Open Folder, then choose ClaudeDemo.
3. Create a new file, for example hello.py.
4. Add a comment describing what you want:

   # I want a Python script that prints the numbers 1 to 10
   

5. Select this line or place your cursor near it.
6. Open the Claude Code side panel or right‑click and choose a context menu entry such as “Ask Claude” or “Claude: Generate Code”.
7. Ask Claude to “Generate the script”, and wait a few seconds.

Claude Code will propose the code. You can insert the suggestion, run it, and ask for refinements like “Add error handling” or “Explain what this script does line by line”.

---

Step 5 – Recommended settings for individual developers

Within VS Code, open Settings and search for “Claude Code”. Key settings to consider:

• Default model
  • Use Claude Sonnet for balanced speed and quality.
  • Use Claude Haiku for quick, low‑cost suggestions on smaller tasks.
  • Use Claude Opus for deep reasoning on complex refactors, while watching cost.
• Context visibility
  • Enable reading of the current file, open editors, and optionally the project tree, depending on privacy and performance needs.
• Telemetry
  • Decide whether to allow anonymous usage data being sent to the extension authors. You can switch this off if privacy is a higher priority.

---

Using Claude Code without a Claude subscription: local models via Ollama

Not every developer or small business wants to commit to another monthly subscription or pay‑as‑you‑go API. An increasingly popular alternative is to:

• Keep the Claude Code–style experience (planning changes, giving instructions in natural language).
• Replace Claude’s hosted models with local, open‑source models running through Ollama.

Conceptually, you are using:

• Claude Code as the agent or shell.
• Ollama as the local model runtime.

Instead of sending prompts to Anthropic’s servers, Claude Code sends them to Ollama running on your own machine, and Ollama uses an open‑source model (such as Qwen or Llama) to answer.

---

Step 6 – Install Ollama on Windows 11

Ollama is a free tool that downloads and runs large language models on your machine and exposes a local API endpoint for tools like Claude Code.

6.1 Download and install Ollama

1. Open your browser and search for “Ollama Windows”.
2. Go to the official Ollama site and download the Windows installer.
3. Save the installer (for example OllamaSetup.exe).
4. Open your Downloads folder and right‑click the installer.
5. Choose “Run as administrator”.
6. If Windows shows a SmartScreen warning, click “More info”, then “Run anyway”.
7. In the setup wizard:
   • Accept the license terms.
   • Keep the default installation location.
   • Make sure “Add Ollama to PATH” is checked.
   • Complete the installation.

6.2 Verify Ollama installation

1. Press Start, type “PowerShell”, and open Windows PowerShell.
2. Type:

   ollama --version
   

3. Press Enter.

If you see a version string, Ollama is installed correctly. If not, restart PowerShell or your computer, or re‑run the installer and confirm the PATH option.

---

Step 7 – Download a local model via Ollama

To use Claude Code without Claude’s cloud, you need an actual model to answer prompts. Ollama maintains a library of models, including several that can handle coding tasks.

7.1 Choose an appropriate model

• On a laptop with 8 GB RAM, prefer smaller models that fit comfortably in memory.
• On a laptop with 16 GB RAM or more, you can try larger code‑centric models with better output quality.

Check the Ollama model library page for recommended models for coding tasks.

7.2 Pull a model

1. Open PowerShell.
2. Use the ollama pull command to download a model, for example:

   ollama pull qwen
   

   or

   ollama pull codellama
   

3. Wait for the download to complete.

7.3 Test the model locally

1. In PowerShell, run:

   ollama run qwen
   

   (replace qwen with your chosen model name).
2. At the prompt, type:

   Write a JavaScript function that returns the square of a number.
   

3. Press Enter and review the response.
4. Press Ctrl + C to exit.

If the model responds sensibly, you are ready to integrate it into a Claude Code–style flow.

---

Step 8 – Connect Claude Code to Ollama instead of Anthropic’s cloud

This is where the “free Claude Code” setup becomes real. Instead of using Anthropic’s endpoint and key, you point Claude Code at Ollama’s compatible interface. At a high level, you will:

1. Install and configure Claude Code or its CLI interface.
2. Set configuration or environment variables so that the Anthropic base URL used by Claude Code is actually http://localhost:11434, which is Ollama’s default local URL.
3. Configure the model name in Claude Code to match the model you pulled in Ollama (for example qwen).

Once this mapping is in place:

• Claude Code sends Anthropic‑style prompts to localhost:11434.
• Ollama passes the request to your chosen open‑source model.
• Claude Code receives the response and continues its agentic workflow: planning changes, proposing edits, and applying patches.

Important note: even though the tool is called Claude Code, in this mode you are running Claude Code as a shell around non‑Claude models. You are not running Anthropic’s Claude itself for free.

---

Step 9 – First end‑to‑end free session (Claude Code + Ollama) on Windows 11

To validate that your free setup works:

1. Ensure Ollama is running. If needed, open PowerShell and run:

   ollama serve
   

2. Ensure Claude Code is configured to use the local endpoint and your chosen model.
3. Open a small project folder in VS Code.
4. Ask Claude Code to perform a realistic task such as:
   • “Scan this repository and suggest a better folder structure.”
   • “Refactor this legacy function into smaller, more testable components.”
5. Observe the planning steps and proposed patches.
6. Approve the patches and verify the edits are applied as expected.

At this point, you have a functional, Claude Code–style coding assistant on your Windows 11 laptop without any Claude subscription.

---

Comparing paid vs free Claude Code approaches

Advantages of the paid Claude Code setup

• Best‑in‑class model quality for reasoning and complex code understanding.
• Simpler setup: sign in, add an API key or subscription, and start working.
• Scales well for large or critical projects.

Disadvantages of the paid setup

• Ongoing subscription or API cost.
• Code and prompts leave your machine to be processed in the cloud.

Advantages of the free Claude Code + Ollama setup

• No Claude subscription cost when using local models.
• Greater control over data if everything runs locally.
• Freedom to experiment with different open‑source models.

Disadvantages of the free setup

• More complex installation and configuration.
• Performance depends heavily on your hardware.
• Open‑source models may still be weaker than Anthropic’s Claude on the hardest tasks.

---

When should you use which approach?

Use a paid Claude Code setup if:

• You want the highest possible code understanding and reasoning quality.
• You prefer minimal configuration and are comfortable paying for usage.
• Your projects are large, complex, or safety‑critical.

Use the free Claude Code + Ollama setup if:

• You are cost‑sensitive (student, hobbyist, early‑stage founder).
• You prioritize keeping code and prompts on your own machine.
• You enjoy experimenting with tools and models and can handle some setup work.

---

Closing thoughts

Claude Code offers a powerful way to bring AI deeper into your daily development workflow. On a Windows 11 personal laptop, you can:

• Install VS Code, add the official Claude Code extension, and connect to Claude via subscription or API for a high‑quality, cloud‑backed coding assistant.
• Or, if you prefer not to subscribe, combine Claude Code’s agentic workflow with free, local models via Ollama and achieve a similar experience without ongoing Claude costs.

Both paths are viable. The right choice depends on your budget, your privacy requirements, and how much configuration you are willing to manage on your own machine.

Read More

Primer - Startup Positioning Narrative Framework For Founders

Startup Positioning Narrative Framework: Claim A Wedge For Founders

Questions Addressed By This Primer

• How do you build a startup positioning narrative framework that investors and customers can repeat in one sentence?
• What are the concrete steps to turn a vague vision into a sharp, testable wedge story that guides product and GTM decisions?
• How should founders define the “enemy,” the “wedge,” and one flagship proof moment so the story feels credible rather than inflated?
• What recent shifts in fundraising and AI-heavy markets make wedge-focused positioning more important than generic category claims?
• What risks come from an over-broad or fundraising-only narrative, and what signals show that the story is starting to drift?

Executive summary / TL;DR

A startup positioning narrative framework turns “what the product does” into a crisp belief about why the market is changing, why the old way is failing, and why the team’s wedge is the fastest path to proof. Done well, it doesn’t inflate the vision. It makes the vision credible by anchoring it to a narrow, winnable first beachhead and a clear tradeoff that competitors won’t take. The practical outcome is sharper investor meetings, faster customer learning, and fewer deck rewrites because the story drives the slides, not the other way around. The playbook below helps founders pick the right enemy, define a wedge that buyers can repeat, and connect early evidence to a long-term arc without overpromising. It’s built to work whether the motion is sales-led, PLG, services-first, or marketplace.

Background and context

Most early-stage companies don’t lose because the product is confusing. They lose because the story is indistinguishable from everyone else’s story, so prospects and investors can’t form a simple mental model of what the company will be “known for” first.

Positioning is the choice of a battleground, not a description of features. Narrative is how that choice becomes memorable and transferable across a deck, a website, outbound messages, demos, and hiring conversations. When narrative and positioning drift apart, the company starts pitching an empire while operating a wedge, and the wedge never compounds into a category.

A strong narrative does two jobs at once. It reduces perceived risk by making the wedge feel inevitable, and it creates urgency by making the status quo feel fragile, expensive, or outdated.

Startup positioning narrative framework essentials

A useful startup positioning narrative framework can be judged by three tests. It should be repeatable by someone else, defensible in a competitive conversation, and usable as a decision filter for product and GTM choices.

Repeatability means a buyer can explain the company in one sentence without needing a follow-up call. Defensibility means the story has a sharp tradeoff that rules out a credible alternative, not just a “better” version of the same approach. Usability means the story tells the team what to say no to, even when the opportunity looks tempting.

If any one of those tests fails, the narrative might still sound good, but it won’t steer the company. And when the story doesn’t steer the company, the market ends up steering it.

Step-by-step playbook (4–7 numbered steps)

1. Name the change, not the trend.
   Start with a market shift that changes what buyers can do, not a buzzword they’ve already heard. “AI is everywhere” isn’t a shift. “Decision-making moved from dashboards to workflows, so the UI is no longer the product” is a shift. If the shift can’t be linked to a concrete before-and-after in the buyer’s day, it’s too abstract.

2. Pick a single enemy the buyer already hates.
   The enemy is rarely “competition.” It’s the costly behavior the buyer is stuck in: manual reconciliation, long security reviews, spreadsheet approvals, brittle integrations, or the constant swivel-chair between tools. Don’t describe the enemy as incompetence. Describe it as an outdated default that smart teams still fall into because incentives and tooling push them there.

3. Define the wedge as an unfair tradeoff.
   A wedge isn’t a small market. It’s a small promise that can be proven quickly. The wedge should include a tradeoff competitors won’t match without breaking their model: setup time vs control, speed vs customization, self-serve vs compliance, automation vs explainability, or breadth vs depth. If there’s no tradeoff, the wedge is just a niche label.

4. Write the “because” sentence.
   Create one sentence that ties the shift to the wedge:
   “For [ICP], the old way fails because [enemy], so [company] wins by [wedge mechanism], which shows up as [measurable outcome].”
   This sentence becomes the spine for the deck’s problem slide, solution slide, and why-now slide. It also keeps messaging from drifting into feature tours.

5. Prove the wedge with one flagship moment.
   Pick a single moment that makes the wedge tangible: a 10-minute onboarding, a “first report” delivered in a day, a security review completed with one evidence pack, or a workflow that closes the loop without handoffs. That moment should be demonstrable live. It’s okay if the rest of the product is still evolving, but that flagship moment can’t be fuzzy.

6. Connect early proof to a believable expansion path.
   Investors and buyers will ask, “What happens after the wedge works?” The answer shouldn’t be “we’ll go upmarket” or “we’ll add features.” It should be a sequence: adjacent user, adjacent workflow, adjacent buyer, adjacent channel. That sequence keeps the long-term vision intact without claiming every customer on day one. If the expansion path can’t be described in three steps, it’s too loose.

Deep dive: tradeoffs and examples

A wedge story often breaks in two predictable ways. The first is when the narrative promises a platform but the wedge only delivers a tool, so the buyer hears “extra risk.” The second is when the wedge is real but framed as a category that’s too broad, so the company picks a fight with incumbents before it has proof.

One way to keep the narrative honest is to separate “vision language” from “wedge language.” Vision language explains the direction of travel and the future default. Wedge language explains what ships now, why it’s different, and what it replaces first. The deck and website can hold both, but the opening must lead with wedge language or the meeting turns into a debate about market size instead of execution.

For an investor-facing example of keeping ambition while tightening the first claim, adapt the narrative discipline used in Series A investor expectations. The story earns attention by making the first proof point concrete and then letting the category expansion read as a consequence, not a hope.

For a customer-facing example, a wedge narrative gets stronger when it ties to ROI and pricing reality instead of generic efficiency claims. The thinking behind AI ROI and pricing reality maps well here because it forces a “what replaces what” answer and a measurable outcome that a buyer can defend internally.

For a category narrative example, it helps to study how large players frame “owning the stack” to justify focus, sequencing, and why-now. Even if the product is different, the narrative mechanics in owning the stack as strategy can inspire a clearer cause-and-effect chain between wedge, control points, and long-term leverage.

What changed lately 

More founders are competing in crowded markets where surface-level differentiation disappears fast, especially in AI-enabled categories. That’s pushed investors to look harder for what Andreessen Horowitz describes as an “earned secret,” meaning a differentiated approach and head start that isn’t available to every fast follower with the same tools.​

Alongside that, the wedge conversation has matured. The most credible wedge pitches aren’t “smaller versions of the end state.” They’re deliberately chosen entry points that set the competitive arena by choosing words, scope, and the first buyer where winning is plausible, a point emphasized in a16z Speedrun guidance on finding a wedge.​

The practical implication is simple. Positioning work is shifting from clever taglines to proof-backed narrative choices: a narrower first promise, a clearer tradeoff, and a sharper explanation of why the new default should exist now, not someday.​

Risks and what to watch next 

A wedge story can become a trap if it’s optimized only for fundraising. If the wedge doesn’t map to a repeatable acquisition channel and a repeatable activation moment, the company can win meetings and still lose quarters.

Another risk is “vision inflation,” where the story keeps expanding to avoid saying no. That can quietly reset the competitive set from “small and winnable” to “broad and crowded,” which slows down learning and makes every objection feel valid. A useful corrective is the reminder to sell the wedge that can be proven, not the empire that might exist later.

Watch for one operational signal. If sales calls and product decisions keep requiring exceptions to the narrative, the narrative isn’t acting as a filter, and the wedge likely isn’t sharp enough to defend.

Next step

For a fast rewrite that turns the current deck and website into one coherent story, use the framework above and then book a call to pressure-test the wedge, tradeoffs, and flagship proof moment against real investor and buyer objections.

A narrative that compounds doesn’t need to be loud. It needs to be specific, provable, and consistent across every touchpoint, so the market starts repeating it for you.

Read More