Problem-Solution Fit¶

The lean-startup gate that demands cheap, need-side evidence — a real, important problem for an identified user, and a solution preferred over their current workaround — before committing to build at scale, guarding against 'build it and they will come.'

Core Idea¶

Problem-solution fit is the lean-startup milestone at which a team has gathered evidence — through customer interviews, problem-validation experiments, and prototype tests — that a proposed solution actually addresses a real, important problem for an identified user, establishing a need-side basis for further investment before committing to build at scale. The structural commitment is that the relevant gate before scaling is need-side, not supply-side: a beautifully engineered solution to a non-problem is the canonical failure, and the methodology insists on establishing that the problem exists, that it matters enough to the user to act on, and that the proposed solution is preferred over the user's current workaround before any significant build commitment is made. The check is sequential — problem-solution fit precedes product-market fit, which precedes scaling — and the test is qualitative and small-n (customer interviews, concierge MVPs, paper prototypes, Wizard-of-Oz simulations) rather than statistical, because at this stage the goal is to kill bad hypotheses cheaply, not to measure market size. The failure mode the concept names and guards against is supply-side commitment without need-side evidence: the "build it and they will come" pattern in which technical execution substitutes for demand validation and the organisation discovers the problem was wrong, or unimportant, or already adequately solved, only after sinking the build investment.

Structural Signature¶

Sig role-phrases:

the identified user — a specific individual or segment hypothesised to have the problem, not an abstract market
the current workaround — the way the user addresses the problem today, whose existence (a cobbled spreadsheet, manual stopgap, paid patch) is the diagnostic signature of a real, live problem
the proposed solution — the hypothesised remedy under consideration, not yet built at scale
the need-side test — the cheap, kill-oriented instrument: small-n customer interviews, concierge MVPs, paper prototypes, Wizard-of-Oz simulations, pre-sales, run before any significant build
the fit criterion — qualitative, three-part: the problem exists for the user, it matters enough that they would act, and the solution is preferred over the current workaround
the sequenced position — the gate sits before product-market fit, which sits before scaling; out-of-order investment is the predicted waste
the gate decision — the go/no-go on committing further build resources, with a defensible default of no until the need is shown
the failure mode guarded against — supply-side commitment without need-side evidence (the "build it and they will come" pattern, engineering excellence substituted for demand validation)

What It Is Not¶

Not product-market fit. It is the earlier gate: problem-solution fit asks whether a problem worth solving exists for an identified user, while product-market fit asks whether a market of sufficient size will adopt at a viable price. Collapsing the two leads a team that has talked to a dozen enthusiastic users to read need-side evidence as market traction and scale prematurely. The sequence is fixed — fit precedes market fit precedes scaling — and out-of-order investment is the predicted waste.
Not "build it and they will come." Supply-side excellence is not need-side evidence: "we shipped it and it works" does not answer "have you validated the need." The canonical failure the concept guards against is exactly committing to build before the problem is shown, so engineering quality and demand are separately accountable, and a working artefact tells you nothing about whether the problem was real.
Not validated by enthusiastic interview responses. A user agreeing that something "sounds useful" reveals nothing; the diagnostic signature of a live problem is what the user has already done about it — a cobbled spreadsheet, a manual stopgap, a paid patch. Polite interest with no existing workaround is a not-yet-validated problem wearing the costume of traction, and reading stated enthusiasm as evidence is the characteristic error.
Not a statistical or market-sizing exercise. At this stage the instrument is deliberately qualitative and small-n — interviews, concierge MVPs, paper prototypes, Wizard-of-Oz simulations — because the goal is to kill bad hypotheses cheaply, not to measure a market. Reaching for survey statistics or large-n market sizing here applies the wrong instrument to the regime; those belong downstream at product-market fit.
Not always the binding constraint. Where the problem is already overwhelmingly validated — a known, acute, universally-felt pain — problem-solution fit is a formality and the real risk has moved downstream to distribution or unit economics. Treating the gate as decisive everywhere wastes motion; the move is to spend effort only on the stage that is actually broken.

Scope of Application¶

Problem-solution fit lives within the lean-startup and product-and-innovation methodology family; its reach is within that domain, wherever a team practises customer-development discipline and gates a need-side validation before committing to build. Strip the customer-development apparatus and only the substrate-general parents travel (validation, sequenced-gate logic, user-centered design) — those, not the named milestone, carry the cross-domain lesson.

Lean startup / customer development — the origin: Steve Blank's customer-development cycle and Eric Ries's lean loop both pivot on problem-solution fit as the explicit pre-build gate.
Product-discovery practice — Marty Cagan's discovery-then-delivery and Teresa Torres's opportunity-solution trees operationalise the gate through continuous interviews and prototype tests.
Seed-stage venture and angel due diligence — investors asking for problem-solution-fit evidence (customers-talked-to, prototype interest) before product-market-fit evidence is expected.
Corporate-innovation stage-gates — Amazon's Working Backwards and Google X embedding an explicit need-validation gate before build commitment.
Social enterprise and human-centered design — IDEO-style design embedding the same need-validation step before a social product is built.

Clarity¶

Naming problem-solution fit makes the order of validation legible and separates two questions a founder is otherwise prone to collapse: is there a problem worth solving? and will a market of sufficient size adopt this at a viable price? The first is the problem-solution-fit gate; the second is product-market fit. Without the distinction, a team that has talked to a dozen enthusiastic users reads that as traction and starts scaling, conflating need-side evidence with market-side evidence; or, conversely, a team with a slick build and no early adopters cannot say what is missing. The label localizes the breakdown: it asks whether the failure is upstream (no validated problem) or downstream (validated problem, no scalable market), so effort lands on the stage that is actually broken rather than on building more features into a solution no one needed.

It also sharpens the distinction between engineering quality and demand, which "build it and they will come" silently equates. Once problem-solution fit is a named gate, "we shipped it and it works" is no longer an answer to "have you validated the need" — supply-side excellence and need-side evidence become separately accountable, and a founder gains a defensible no to any feature that does not trace back to a validated problem. The sharper question it licenses is not "can we build this?" but "is the user's current workaround painful enough that they would switch?" — relocating the test from the team's capability to the user's revealed willingness to abandon the status quo.

Manages Complexity¶

The space a founder actually faces is overwhelming: dozens of possible features, distribution channels, pricing schemes, and pivots, each entangled with market sizing, competitive dynamics, fundraising, and team capability, all live at once. Problem-solution fit compresses the should-we-keep-going question by ruling that, before scaling, only the need side is decisive, and reduces that to three checks read in fixed order — does the problem exist for an identified user, does it matter enough that the user would act, and is the proposed solution preferred over the current workaround. Whether to commit further build resources then follows from those few qualitative readings rather than from re-litigating the whole venture: the market-size, pricing, and distribution questions are deferred downstream to product-market fit, and supply-side excellence is set aside as not-yet-relevant. A founder tracks a handful of validated-need signals from small-n interviews and prototype reactions and reads the go/no-go off them, instead of trying to forecast the full business at once — turning an open-ended, high-dimensional bet into a staged gate with a short checklist and a defensible default of no until the need is shown.

Abstract Reasoning¶

Problem-solution fit licenses a tight set of inference moves, all turning on the need-side gate the compression isolates.

Diagnostic — read hidden demand from behavioral surface, not from stated enthusiasm. The characteristic move is to distrust verbal endorsement and infer the true state of the need from what the user has already done about the problem. A user who has cobbled together a spreadsheet, a manual workaround, or a paid stopgap reveals a problem live enough to act on; a user who is merely agreeable in an interview ("yes, that sounds useful") reveals nothing — the existence of a workaround is the diagnostic signature of a real problem, and its absence is the signature of a manufactured one. From "they say they'd buy it" the move is to ask what are they doing about it today? — and to read polite interest with no workaround as a not-yet-validated problem wearing the costume of traction. Likewise the move infers, from a team that answers "have you validated the need?" with "we shipped it and it works," that they have substituted a supply-side fact for the need-side question and so do not actually know whether the problem exists.

Interventionist — to find out whether the need is real, raise the cost of a fake yes. Because the failure is committing to build before the need is shown, the licensed interventions are the cheap, kill-oriented experiments that force a costly signal before the build: the concierge MVP, the Wizard-of-Oz simulation, the paper prototype, the pre-sale or letter-of-intent. Each is a prediction with a falsifiable edge — if the problem matters enough to switch, the user will tolerate the manual, ugly, or partial version; if they will not abandon their current workaround even for a working stopgap, the predicted demand was illusory and the hypothesis is killed before the build investment is sunk. The interventionist reading of a feature request is the inverse: the move is to trace every proposed feature back to a validated problem and, finding none, to withhold the build — the defensible "no" is itself the intervention, conserving the resource the methodology exists to protect.

Boundary-drawing — which gate is this, and is qualitative small-n the right instrument? The concept draws two regime lines. First, it separates the problem-solution-fit regime from the product-market-fit regime: while you are still asking does a problem worth solving exist, the correct instrument is qualitative and small-n (interviews, prototypes) and statistical market-sizing is premature noise; only once fit is established does the question become will a market adopt at a viable price, where large-n and pricing belong. Reaching for survey statistics during the fit stage, or for more customer interviews during the scaling stage, is applying the wrong instrument to the regime. Second, it bounds when the gate is even the binding constraint: in a domain where the problem is already overwhelmingly validated (a known, acute, universally-felt pain), problem-solution fit is a formality and the real risk has moved downstream to distribution or unit economics — invoking the gate there wastes motion. The move is to ask which stage is actually broken — no validated problem (upstream) or validated problem with no scalable market (downstream) — and to spend effort only on the stage that is.

Order-of-events — the sequence is itself a prediction. The fixed ordering (validate problem → establish problem-solution fit → establish product-market fit → scale) is a predictive claim that out-of-order investment is wasted: a team that scales before fit is predicted to acquire users who churn, to build features no validated problem demanded, and to discover the problem was wrong only after the spend — so observing premature scaling licenses the forecast of an expensive late correction. The move runs both directions in time: forward, fit predicts that further build is warranted; backward, a failed scale-up is read as evidence the gate was skipped or falsely passed.

Knowledge Transfer¶

Within lean-startup and the broader product-and-innovation methodology, problem-solution fit transfers as mechanism across the contexts that practice the same customer-development discipline, because the gate, the instrument, and the failure it guards against are identical wherever it is applied. The need-side-before-supply-side ordering, the qualitative small-n test (interviews, concierge MVPs, paper prototypes, Wizard-of-Oz simulations), the workaround-as-diagnostic-signature heuristic, and the defensible-no intervention carry intact from Steve Blank's customer-development cycle and Eric Ries's lean loop, to product-discovery practice (Marty Cagan, Teresa Torres' opportunity-solution trees), to seed-stage venture and angel due diligence (asking for problem-solution-fit evidence before product-market-fit evidence is expected), to corporate-innovation stage-gates (Amazon's Working Backwards, Google X), to social enterprise and IDEO-style human-centered design embedding the same need-validation step before build. These are one methodological construct with the setting swapped — the gate sits at the same point in the sequence and asks the same question — not analogies between separate ideas.

Beyond that methodological family the situation is not "mechanism within, metaphor beyond" so much as the third case: the named milestone does not travel, but the structural commitment underneath it is already a set of substrate-general patterns that recur everywhere (case B). Strip the startup vocabulary and problem-solution fit reduces to demand-side validation before supply-side build, gated before further commitment — which factors cleanly into existing primes: validation (does the proposed remedy actually solve the intended problem for the intended user?), sequenced-gate / stage_gate logic (a need-side check that must pass before resources flow to the next stage), and user_centered_design (the test is the user's revealed willingness to abandon the status quo, not the team's capability). Those parents are genuinely substrate-independent — the "validate the need before building the solution" move is older than the term and recurs across engineering, public policy, healthcare-intervention design, and edtech under their own names — and the cross-domain lesson should be carried by them, not by "problem-solution fit." Crucially there is no substrate-independent residue left over once those primes are extracted: the concept's distinctive content is not a new structural primitive but the lean-startup operationalisation (the specific interview protocols, the catalogue of cheap kill-oriented experiments, the qualitative fit-criteria, the explicit pairing with the later product-market-fit gate), and that operationalisation is methodological and home-bound. The honest report is therefore: across the lean-startup and product-discovery world the milestone transfers as mechanism with only vocabulary changed; for genuinely distant domains, carry the general validation-before-commitment / sequenced-gate / user-centered-design patterns, while the customer-development apparatus and the "problem-solution fit" name stay home as the domain accent. (See Structural Core vs. Domain Accent.)

Examples¶

Canonical¶

Zappos is the textbook concierge-MVP validation. In 1999, before building any warehouse, inventory system, or logistics operation, founder Nick Swinmurn tested a single need-side hypothesis: would people buy shoes online, sight-unfitted? He went to local shoe stores, photographed their stock, posted the photos on a bare website, and when an order came in, bought the shoes at retail and shipped them himself — losing money on each sale by design. The point was not margin but evidence: real strangers, not agreeable interviewees, were willing to pay and wait for shoes bought online. Only after that revealed-willingness signal did the company commit to building inventory and fulfillment at scale.

Mapped back: Shoe shoppers are the identified user and driving to a store is the current workaround. The photograph-and-manually-fulfill scheme is the need-side test — a cheap, kill-oriented instrument run before any real build — and a paying order is the fit criterion (the solution preferred over the store trip). Committing to build only afterward is the gate decision with its defensible default of no.

Applied / In Practice¶

Dropbox's launch is a widely-cited deployment of the same discipline in a domain where the build was genuinely expensive and hard. Rather than first constructing the full file-syncing infrastructure, founder Drew Houston made a short demonstration video in 2008 showing the intended product working seamlessly, narrated with in-jokes for a technical audience, and posted it to Hacker News and Digg. The beta waiting list reportedly jumped roughly from 5,000 to 75,000 people overnight. That surge was need-side evidence that the file-synchronization pain was real and that this solution was wanted, gathered before the costly engineering was finished — precisely the check against pouring months into infrastructure for a problem that might not have mattered enough to switch for.

Mapped back: People juggling files across machines are the identified user; emailing files to themselves or carrying USB drives is the current workaround. The explainer video is the need-side test, a cheap kill-oriented experiment standing in for the unbuilt product; the signup surge is the fit criterion as revealed willingness. Validating before building is the answer to the failure mode guarded against — "build it and they will come."

Structural Tensions¶

T1: Cheap-kill instrument versus reliable signal (the small-n trade-off). The gate's whole efficiency comes from using deliberately qualitative, small-n instruments — a handful of interviews, a concierge MVP, an ugly paper prototype — to kill bad hypotheses cheaply before any real build. But cheapness and kill-orientation buy speed at the cost of confidence: a small sample of the wrong early users, or a stopgap that failed for reasons incidental to the underlying need (a confusing prototype, a mispriced pre-sale), can produce a false negative that buries a real problem, while a handful of unusually enthusiastic recruits can produce a false positive that passes a dead one. The very design that makes the test affordable — small, manual, fast — is what makes its verdict noisy. The tension is that the instrument optimized to reject hypotheses cheaply is not the instrument that would tell you reliably whether the rejection was right. Diagnostic: Did the need-side test fail because the demand is truly absent, or because a small, artifact-prone experiment mis-measured a demand that a better-targeted test would have found?

T2: Workaround-as-signature versus latent demand (the heuristic that over-rejects the novel). Reading an existing workaround — a cobbled spreadsheet, a manual stopgap, a paid patch — as the diagnostic fingerprint of a live problem is the concept's sharpest defense against polite interview enthusiasm. But it is systematically biased against genuinely novel needs the user has never framed: a problem can be real and acute yet leave no workaround because the user never conceived that a solution was possible, so the absence of a workaround is read as an absent problem when it may be an unarticulated one. The heuristic that filters out fake yes-saying also filters out the latent demand that breakthrough products exist to serve. The tension is that the workaround signature makes the gate rigorous against manufactured problems precisely by discounting the demand that has no precedent to point to. Diagnostic: Does the missing workaround mean there is no real problem, or that the problem is latent and unframed because the user never imagined it could be solved?

T3: Defensible default-no versus premature abandonment (capital discipline against conviction). The gate's default of "no until the need is shown" conserves the build resource and gives a founder a principled refusal to any feature not tracing to a validated problem — the core guard against pouring engineering into a non-problem. But a rigid default-no is also a machine for killing ventures that required persistence through an unconvincing early signal: some real opportunities show weak, ambiguous problem-validation at first and reward conviction, and a strict gate cannot distinguish "no real problem" from "a real problem the early test undersold." The same conservatism that prevents wasted builds can prevent the tolerance-for-ambiguity that non-obvious opportunities demand. The tension is that capital discipline and founder conviction pull opposite at exactly the moment the evidence is thin. Diagnostic: Is a weak fit signal grounds to kill the hypothesis, or a case where the gate's default-no would abandon a real but hard-to-validate problem?

T4: Binding constraint versus formality (when the gate is even the right question). Problem-solution fit is decisive only where the problem's existence is genuinely in doubt; where the pain is already acute, known, and universally felt, the gate is a formality and the real risk has moved downstream to distribution, pricing, or unit economics. So the methodology's own discipline can become theater: a team religiously running interviews to re-validate an obvious problem is applying the gate where it no longer binds, burning motion on a passed check while the actual failure sits in a stage they are not testing. Conversely, skipping the gate where the problem was merely assumed is the fatal case. The tension is that the same gate is essential in one regime and wasted motion in another, and the concept supplies no automatic signal for which regime you are in beyond the analyst's judgment of which stage is broken. Diagnostic: Is the venture's binding risk actually the unproven problem (gate it hard), or is the problem obvious and the real risk downstream in distribution or economics (gating it is theater)?

T5: Autonomy versus reduction (a lean-startup milestone or an operationalization of validation). Problem-solution fit is a genuine, named milestone with a home-bound operational apparatus — the interview protocols, the catalogue of cheap kill-oriented experiments (concierge MVP, Wizard-of-Oz, paper prototype), the qualitative fit-criteria, the explicit pairing with the later product-market-fit gate — and within lean-startup and product-discovery practice it transfers as literal mechanism with only the setting swapped. But its cross-domain reach is unusually thin, because stripping the startup vocabulary leaves no substrate-independent residue: the structural commitment factors entirely into the parents it composes — validation (does the remedy solve the intended problem for the intended user), stage_gate logic (a need-side check that must pass before resources flow onward), and user_centered_design (the test is revealed willingness to abandon the status quo). "Validate the need before building" is older than the term and recurs across engineering, policy, and healthcare under their own names. The concept's distinctive content is the operationalization, not a new structural primitive. Diagnostic: Resolve toward the parents (validation, stage-gate, user-centered design) whenever the lesson must travel beyond startups; toward "problem-solution fit" only when the specific customer-development apparatus is the object in situ.

Structural–Framed Character¶

Problem-solution fit sits at the framed-leaning end of the spectrum — a prescriptive methodological gate rather than a mechanism nature runs, close to how a practice-constituted diagnosis like primitive obsession patterns, and much further from structure than the mathematical construct of a probability distribution. On evaluative_weight it points clearly framed: the concept is a best-practice prescription, not a neutral description — it exists to license a go/no-go decision with a "defensible default of no," telling teams what they ought to do (validate need before committing to build) and naming the "build it and they will come" pattern as a failure to be guarded against. That normative charge is the concept's whole reason for being. On human_practice_bound it is framed in the strongest sense: the gate is constituted entirely by the human practice of customer development — teams, users, ventures, builds, funding decisions — and dissolves the instant that practice is removed; there is no problem-solution fit in an observer-free world the way there is an isostatic rebound or a decay-count distribution. On institutional_origin likewise framed: it is furniture of a specific methodological tradition (Blank's customer-development cycle, Ries's lean loop, Cagan and Torres's discovery practice, Amazon's Working Backwards), an artifact of a management culture rather than a fact anyone discovered in nature.

The remaining two criteria confirm the placement and set its domain boundary. On vocab_travels it is pinned: concierge MVP, Wizard-of-Oz test, pivot, product-market fit, customer-development gate are irreducibly lean-startup vocabulary that loses its referents off that substrate. On import_vs_recognize the transfer is bimodal but with an unusually thin structural residue — within the lean-startup and product-discovery family (venture diligence, corporate stage-gates, IDEO-style design) it moves as recognition of one mechanism with only the setting swapped, while beyond it there is, by the entry's own account, no leftover primitive: the lesson is carried wholesale by the parents, so distant-domain uses are recognitions of those parents, not imports of "problem-solution fit."

The portable structural skeleton is a composite the entry demonstrably requires rather than a single parent: demand-side validation gated before supply-side commitment, which factors cleanly into validation (does the remedy actually solve the intended problem for the intended user), stage_gate (a check that must pass before resources flow to the next stage), and user_centered_design (the test is the user's revealed willingness to abandon the status quo). That composite skeleton is genuinely substrate-general and older than the term, which is what gives the gate any structural footing at all — but it is exactly what problem-solution fit instantiates from those three parents, not what makes "problem-solution fit" itself travel: the cross-domain reach belongs to validation/stage-gate/user-centered-design, while the customer-development operationalization (interview protocols, cheap kill-oriented experiments, the paired product-market-fit gate) stays home. Its character: a prescriptive, practice-constituted validation gate whose entire portable content is the validation-before-commitment composite it operationalizes, framed-leaning because everything distinctive about it is lean-startup methodology and nothing structural is left over once the parents are extracted.

Structural Core vs. Domain Accent¶

This section decides why problem-solution fit is a domain-specific abstraction and not a prime, and carries the case for its domain-specificity — a case sharpened by how little structural residue the concept leaves behind.

What is skeletal (could lift toward a cross-domain prime). Strip the lean-startup vocabulary and a thin relational structure survives: before committing resources to build a solution, test cheaply that the need it addresses is real and preferred over the status quo, and pass a gate on that need-side evidence before proceeding. Unusually, this skeleton is not one abstract core but a composite of three that the entry demonstrably requires — validation (does the proposed remedy actually solve the intended problem for the intended user?), stage_gate (a check that must pass before resources flow to the next stage), and user_centered_design (the decisive test is the user's revealed willingness to abandon the current workaround, not the team's capability). All three are genuinely substrate-portable, and "validate the need before building" is older than the term and recurs under its own names across engineering, public policy, and healthcare-intervention design. But this composite is the core problem-solution fit shares — indeed is fully composed from — not a new structural primitive it uniquely owns.

What is domain-bound. What makes the concept problem-solution fit in particular is customer-development operationalization, none of which survives extraction. Its content is a lean-startup apparatus: the identified user and current workaround framing (the cobbled spreadsheet or manual stopgap as the diagnostic signature of a live problem), the catalogue of cheap, kill-oriented instruments (concierge MVP, Wizard-of-Oz simulation, paper prototype, pre-sale, letter-of-intent), the qualitative three-part fit criterion, and — most tellingly — the explicit sequenced pairing with the downstream product-market-fit gate and the "build it and they will come" failure it is defined against. These are worked methodological vocabulary and cases (Zappos's photograph-and-fulfill scheme, Dropbox's demo video), all specific to the venture-building substrate. The decisive test: remove the practice of customer development — teams, users, builds, funding decisions — and there is nothing left to gate; the milestone dissolves entirely, because unlike a mechanism nature runs it exists only inside that practice.

Why this does not clear the prime bar. A prime's vocabulary travels and its transfer is recognition of the same mechanism, not analogy. Problem-solution fit's transfer is bimodal, but with an unusually thin structural residue. Within the lean-startup and product-discovery family — Blank's and Ries's cycles, Cagan's and Torres's discovery practice, seed-stage venture diligence, corporate stage-gates like Amazon's Working Backwards, IDEO-style human-centered design — it moves intact as recognition of one mechanism with only the setting swapped. Beyond that family the named milestone does not travel, and here is the sharp point: once the three parent primes are extracted there is no substrate-independent residue left over — the concept's distinctive content is entirely the operationalization, not a new primitive. So when the bare lesson is needed cross-domain — validate demand before committing to build — it is already carried, in more general form, by the composite of validation, stage_gate, and user_centered_design that problem-solution fit merely operationalizes. The cross-domain reach belongs wholly to those parents; "problem-solution fit," as named, is the customer-development apparatus that should stay home.

Relationships to Other Abstractions¶

Current abstraction Problem-Solution Fit Domain-specific

Parents (2) — more general patterns this builds on

Problem-Solution Fit is part of, conditional Smoke Test Domain-specific

A fake door, pre-order, or landing-page Smoke Test can be one cheap need-side instrument inside a Problem–Solution Fit gate before the product is built.
Problem-Solution Fit is a decomposition of Validation Prime

The milestone asks whether the proposed remedy solves the intended user's real, important problem in context, not merely whether the team can build it correctly.

Not to Be Confused With¶

Product-market fit. The next gate in the same sequence: problem-solution fit asks whether a problem worth solving exists for an identified user; product-market fit asks whether a market of sufficient size will adopt at a viable price and pull the product through. It is the sibling milestone one step downstream, with its own metric apparatus (CAC, LTV, retention cohorts). Tell: is the open question "is this a real problem someone would act on?" (problem-solution fit) or "will a reachable market retain and pay at scale?" (product-market fit)? Reading a dozen enthusiastic interviews as market traction is exactly the collapse this boundary prevents.
Minimum viable product / concierge MVP. The cheap, kill-oriented instrument — paper prototype, Wizard-of-Oz, concierge fulfillment — used to run the need-side test. It is the tool, not the milestone: an MVP is a thing you build to probe for fit, whereas problem-solution fit is the evidential condition the probe is trying to establish. Tell: are you naming the artifact run to gather evidence (MVP), or the go/no-go conclusion that evidence supports (problem-solution fit)?
Customer development. The broader lean-startup methodology (Blank's search-then-execute cycle) within which problem-solution fit is one gate. It is the containing practice, not the milestone: customer development is the whole discipline of iteratively searching for a business model; problem-solution fit is a single validated checkpoint inside it. Tell: is the referent the ongoing search process (customer development) or the specific need-side gate that must pass within it (problem-solution fit)?
Market sizing / TAM analysis. The large-n, quantitative estimation of how big an addressable market is. It is a downstream, wrong-instrument neighbor: problem-solution fit is deliberately qualitative and small-n because its goal is to kill bad hypotheses cheaply, not to measure a market — market sizing belongs at product-market fit and after. Tell: are you counting the size of a market (sizing), or testing qualitatively whether a real, actionable problem exists at all (problem-solution fit)?
Validation / stage-gate / user-centered design (parent primes). The substrate-general patterns problem-solution fit composes from and instantiates — does the remedy solve the intended problem (validation); a check that must pass before resources flow onward (stage_gate); the test is the user's revealed willingness to abandon the status quo (user_centered_design). They are the generalizations that carry the "validate the need before building" lesson to engineering, policy, and healthcare, not confusable peers. Tell: these parents travel cross-domain under their own names; problem-solution fit is the lean-startup operationalization of the composite, treated more fully in the sections above.

Neighborhood in Abstraction Space¶

Problem-Solution Fit sits in a sparse region of the domain-specific corpus (65^th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Lean Validation & Startup Signal Theater (8 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-07-12