Problem-Solution Fit: The Stage Before PMF (And Why It Matters More Now)

Ash Maurya’s line — “Life’s too short to build something nobody wants” — landed in 2012, when “building” still meant months of engineering effort. It was an efficiency argument back then. In 2026 it reads differently. Building is nearly free. The cost of building something nobody wants is now measured in support burden, sales theatre, and opportunity cost — not engineering weeks. That makes the argument sharper, not softer.

Problem-solution fit is the discipline that sits upstream of product-market fit. PSF asks: is the problem real, painful, and worth paying to solve? PMF asks: does our specific solution serve that problem well enough that users pull it out of our hands? Skip PSF and you end up measuring PMF on a product solving a problem that didn’t need solving in the first place. No amount of Sean Ellis survey optimisation rescues that.

Most teams conflate the two. Most content on the internet conflates the two. The usual pattern is: founders build, ship, discover nobody cares, and reverse-engineer a “problem” to justify the solution. That’s solution-in-search-of-problem — the most expensive mistake in early-stage product work and one that AI has made dramatically easier to commit.

Problem-solution fit is the state in which a team has validated three things: the problem is real (people experience it regularly), painful enough (they actively seek or buy workarounds), and their proposed solution is a directionally credible fix. It is measured through customer-discovery interviews, workaround evidence, and a small cohort of “earlyvangelists” — ideally three to five paying customers who would be very disappointed without the solution. PSF is a prerequisite for, not a substitute for, product-market fit .

Sign up (free) to protect time for problem discovery before you build

What Problem-Solution Fit Actually Is

The canonical treatment is Ash Maurya’s Running Lean (O’Reilly, first edition 2012, third edition 2022). Maurya built on Steve Blank’s Customer Development model — Customer Discovery → Customer Validation → Customer Creation → Company Building — and turned the first two stages into a practical sequence any founder can run.

PSF sits in Blank’s Customer Discovery stage, with Customer Validation as the bridge to PMF. Blank’s threshold for progression is three to five satisfied paying “earlyvangelists” — customers so enthusiastic about the solution that they will evangelise it to peers even before it’s polished. That’s the empirical signal that the problem is worth solving and your solution is plausibly the right one.

Three things distinguish PSF from PMF:

Crucially, PSF is about problem validation not solution praise. A customer saying “your solution is interesting” is not PSF. A customer saying “I currently spend two hours a week on this, I’ve tried and rejected three competitors, and I would pay you £200 a month to fix it” is PSF. Mistaking the first for the second is the single most common and most expensive error in early-stage work.

The Canvases: Lean Canvas and PSF Canvas

Two tools are worth knowing.

Lean Canvas (Maurya’s adaptation of Alex Osterwalder’s Business Model Canvas) is a one-page, nine-block map of your hypothesis: Problem, Customer Segments, Unique Value Proposition, Solution, Channels, Revenue Streams, Cost Structure, Key Metrics, Unfair Advantage. You fill it in before you build. You update it after every customer interview. The blocks left blank are the hypotheses you still need to test.

Problem-Solution Fit Canvas (Daria Nepriakhina and Dave Gray) is a ten-block diagnostic specifically for PSF: Customer State Fit, Problem-Behaviour Fit, Communication-Channel Fit, and so on. It’s more discovery-oriented than Lean Canvas and is useful when you want to stress-test why the customer will behave in a certain way, not just what they’ll pay for.

Either tool works. The discipline is the same: make your hypotheses explicit, test them in interviews, update the canvas weekly, kill hypotheses that die under contact with customers. The canvases are not precious documents; they’re scratch paper for thinking.

The 2026 Reframe: PSF Matters More When Building Is Free

The standard argument for PSF was always efficiency — don’t build before you validate. In 2026 that argument is stronger, not weaker, for a counter-intuitive reason.

When building cost six months and £500k, the cost alone forced some problem-validation discipline. A founder who couldn’t articulate the problem clearly enough to raise the money couldn’t start building. The economic friction performed the diagnostic work.

Now a founder with a laptop and an LLM can have a working prototype in a week. The economic friction that used to filter out solution-in-search-of-problem ideas has evaporated. What replaces it? Nothing, unless the team deliberately replaces it with PSF discipline.

The AI-era failure mode is now predictable: a team shortcuts straight from idea to prototype, skips problem validation, launches into a market that didn’t want the product, and then tries to retrofit PMF measurement onto a product that never had PSF. Ten prototypes in, nothing has found traction, and the team concludes “PMF is hard in this market”. No — PSF was hard in this market, and they never did it.

This is the thesis that threads through the whole early-stage validation cluster and pairs with the AI-era lifecycle reframe . AI collapses build cost; sell cost is unchanged. Selling without PSF is selling nothing anyone wants, and that costs exactly as much as it ever did.

Products, Not Companies: PSF Is Per-Product

A common mistake in PSF content is framing it as a one-time event in a company’s life — you achieve PSF, then you’re done. Wrong. Every new product a mature company launches has to re-achieve PSF for its specific market and problem, whether or not the parent company has PMF on its existing products.

Microsoft had PSF for Excel forty years ago. That tells you nothing about whether Microsoft has PSF for Teams Premium today. Stripe had PSF for Payments fifteen years ago. That tells you nothing about whether Stripe has PSF for their newest product line. A mature company’s portfolio contains products at different lifecycle stages and different validation stages (see the product lifecycle directory ). Several of those products — specifically the new bets — are pre-PSF. The discipline required to work on a pre-PSF product inside a mature company is completely different from the discipline required to ship a release for a post-PMF product.

The governance implication: the board should know which products in the portfolio are pre-PSF, which are pre-PMF, and which are scaling. Conflating the three — treating a new bet as if it were scaling — is how mature companies kill good ideas.

The Side-of-Desk Anti-Pattern in PSF Work

PSF work looks fundamentally different from delivery work, and teams that try to do it alongside delivery usually fail at both. Here’s why.

PSF work is customer-facing. It’s heavy on interviews (15–20 in the first few weeks), prototype testing, and hypothesis revision. It’s fundamentally discovery work — which is why the product discovery cluster matters so much. A team also responsible for sprint delivery will skip the interviews first. They always do. Delivery has deadlines; discovery doesn’t.

The fix is the same one this blog has argued for repeatedly: a dedicated minimum viable team for the new bet. Two engineers, one product person, full-time, with a proper business case and protected capacity. Measured on outcomes (earlyvangelists, problem validation confidence, paying reference customers), not output. Protected from interrupt work by WIP limits and the discipline of not changing priorities every time a Run fire breaks out.

Companies that can’t or won’t afford a dedicated PSF team almost never find PSF. They find excuses, and eventually they find their way to “that market was too hard” as the post-mortem. The market wasn’t too hard. The allocation was too thin.

Try RoadmapOne to protect dedicated PSF team capacity — free sign-up

Cagan’s Risk of Value and PSF

Marty Cagan’s four product risks — value, usability, feasibility, viability — map onto PSF cleanly. PSF is principally a value risk test performed early: will anyone choose to use this because the problem it solves is worth solving?

Usability risk matters but is a smaller deal at the PSF stage — you can run a chunky prototype. Feasibility risk is almost never the binding constraint in 2026; AI tooling has commoditised it for most software problems. Viability risk (will the business model work?) is the risk Cagan correctly identifies as often underweighted — and it’s the one that kills products with real PSF but no sustainable economics. This is where Brian Balfour’s Four Fits framework becomes essential reading: PSF doesn’t prove Channel-Model or Model-Market fit, and a product that has PSF but wrong Channel-Model will still fail.

The product operating model that Cagan describes in Transformed is the structural enabler for honest PSF work: empowered teams who spend real time with customers, measure outcomes not outputs, and can kill a bad hypothesis without political cost.

The Interview Is the Work

If I had to pick one activity that distinguishes teams that find PSF from teams that don’t, it would be: whether they have actually talked to 20+ target customers about the problem, without leading the witness.

The rules for honest interviews are well-codified in Rob Fitzpatrick’s The Mom Test (covered in full in the Mom Test article ). The headline rule: never ask if they’d buy your product. Ask about their life, their problem, their current workarounds, and what they’ve already paid to solve it. Anyone will tell you your idea sounds great — even your mother. That’s worthless data. The signal you’re looking for is past behaviour: have they tried to solve this already? What did they spend? What did they abandon? Why?

Twenty honest interviews will tell you whether you have PSF. Two hundred surveys won’t. The teams who skip this step are the teams who end up with prototypes nobody adopts.

How to Know You Have Problem-Solution Fit

PSF is not a score. It’s a pattern of signals. I look for these in order:

1. Problem frequency. Do target customers encounter the problem at least weekly? (Monthly problems rarely generate buying behaviour.)
2. Workaround evidence. Are they already paying for workarounds — spreadsheets, contractors, competing tools, internal hacks? Real pain produces real spending.
3. Prototype pull. When shown a credible prototype, do they ask “when can I get this?” — or do they politely nod? The first is PSF signal. The second is validation theatre.
4. Earlyvangelists. Do you have 3–5 customers prepared to pay (even a small amount) before the product is polished, and willing to introduce you to peers with the same problem?
5. Workable UVP. Can you articulate the unique value proposition in a single sentence a customer nods at — without needing to explain the solution first? Maurya’s test: if you need a demo to communicate value, you don’t have PSF yet.
6. Repeatable interview signal. Across 20 interviews, does the same problem formulation come back unprompted? Or do you hear 20 different problems? Divergence is a signal you haven’t found the segment yet.

If all six fire, you have PSF. If only one or two fire, you don’t — and no amount of building will create it.

The PE / NED Diagnostic for Pre-PSF Companies Claiming PMF

From a board seat, the giveaway that a company is pre-PSF but claims PMF is almost always in how they describe their customers. Healthy PSF language talks about the problem — “our customers were spending four hours a week on X, now they spend ten minutes”. Pre-PSF language talks about features — “we shipped the integration, the reports module, and the admin console”. The linguistic tell is binary and almost always correct.

The sharper diagnostic is cohort behaviour. Post-PSF customers tend to behave similarly (same pain, same usage shape, same retention curve). Pre-PSF “customers” tend to behave wildly differently because the product is solving a different implicit problem for each of them. A flat retention curve averaged across 50 customers with five different use cases looks like a mediocre product; it’s often a pre-PSF product serving five different (tiny) segments simultaneously.

The third tell is pipeline composition. A post-PSF company has inbound leads who describe the problem using the company’s language. A pre-PSF company has outbound-driven pipeline where the sales team is educating prospects about a problem they didn’t know they had. Education pipelines can work; they cost three times as much to convert and produce a bad-salesperson pattern of asking engineering for more features to close the next prospect. That’s theatre; a good salesperson sells what you have to the narrow segment that has the problem.

PSF and the Roadmap

PSF work does not look like a normal roadmap. The outputs are interview insights, validated hypotheses, killed hypotheses, and evolving canvas versions — not shipped features. That means your roadmap tool has to accommodate outcome-based planning and not collapse “work done” into “tickets closed” (see outcome vs output vs input ).

The dual-track agile model — a discovery track running alongside a delivery track — is the structural answer. In the PSF stage, the discovery track is the primary track; the delivery track exists only to produce the prototypes needed to test hypotheses. As PSF hardens into PMF, the balance shifts. This is also where allocating discovery capacity as a first-class roadmap item pays back.

How RoadmapOne Helps

RoadmapOne ’s grid makes PSF-stage team allocation visible. A PSF squad tagged as Transform work — dedicated engineers and a PM, protected from Run interrupt — shows up clearly against the rest of the portfolio. The OKR model lets you set the PSF team’s objective as “reach 3 paying earlyvangelists by end of Q2” rather than “ship the feature list” (see objectives to key results ). And the Run / Grow / Transform analytics tell the board exactly how much capacity is on PSF hunting vs Run — usually much less than the board thinks, which is often the honest conversation that needs to happen.

Frequently Asked Questions

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

PSF is about the problem: is it real, frequent, and painful enough that people will pay to solve it, and does your proposed solution look directionally credible? It’s measured through interviews, workaround evidence, and 3–5 paying earlyvangelists. PMF is about the market: does your built, shipped product serve a wide enough slice of that market that users pull it out of your hands? PMF is measured through cohort retention, the Sean Ellis 40% test , and organic growth. PSF is a prerequisite; PMF is the next milestone.

How many customer interviews do I need to reach problem-solution fit?

The practical rule: 20 interviews with target segment customers, run with Mom Test discipline (no leading questions, focus on past behaviour, not hypothetical intent). If after 20 interviews the problem description is converging and 3–5 of them are willing to pay for a credible solution, you have PSF signal. If the problem descriptions are still diverging after 20 interviews, you have a segment problem: your target customer isn’t who you thought, and you need to change who you’re talking to rather than interview more.

Can you have problem-solution fit without a product?

Yes — and you should. PSF is a pre-build milestone. The prototype you use to test it can be a clickable mock-up, a concierge service run by humans, a spreadsheet, a video, or a landing page. Maurya and Blank both emphasise that PSF is achieved through evidence of problem and evidence of willingness to pay for a credible solution — not through a working product. Jumping to build before PSF is the classic early-stage mistake; it’s cheaper now than it used to be, but still wasteful.

What is the Lean Canvas and how does it help with problem-solution fit?

The Lean Canvas is Ash Maurya’s nine-block one-page business model canvas, adapted from Alex Osterwalder’s Business Model Canvas. The blocks are Problem, Customer Segments, Unique Value Proposition, Solution, Channels, Revenue Streams, Cost Structure, Key Metrics, Unfair Advantage. At the PSF stage you fill it with hypotheses before building, and update it after every customer interview. Blocks you can’t fill are the hypotheses that still need to be tested. The discipline is not the canvas itself — it’s making your hypotheses explicit and updating them against evidence.

What are earlyvangelists and why do they matter?

Steve Blank’s term for your first paying customers — they’re not just willing to buy your rough product, they’ll actively evangelise it to peers because the problem they have is painful enough that your solution is a relief even when imperfect. The threshold of 3–5 earlyvangelists is the traditional PSF signal: enough to prove the problem is real and the solution is credible, but small enough that you haven’t yet tested whether the market is big. They are the bridge from problem validation to product-market fit.

How is problem-solution fit different in 2026 with AI?

AI has collapsed build cost, which has removed the economic friction that used to force some problem-validation discipline on early-stage teams. That makes PSF more important, not less, because nothing else filters solution-in-search-of-problem ideas now. The fail-fast dynamic has flipped: it used to be that you failed at the building stage (too expensive), now you fail at the selling stage (nobody wants it). The only defence is disciplined problem validation before building — which is exactly what PSF is.

Sign up (free) to validate problems before you build solutions

Conclusion

Problem-solution fit is the discipline that keeps early-stage teams honest. It is the customer-interview-driven, workaround-evidence-heavy, earlyvangelist-counting stage that comes before product-market fit and before any serious scale investment. It’s cheap, it’s unglamorous, and it’s the highest-leverage work any early-stage team does.

The AI-era temptation is to skip it. Build is so cheap; why not just ship the prototype and see what happens? The answer is that ten unwanted prototypes are exponentially worse than one, because each one consumes attention, credibility, and opportunity cost the team cannot get back. Teams that treat PSF as a serious, bounded, measured stage — with a dedicated minimum viable team, a canvas they update weekly, twenty honest interviews, and a kill criterion agreed in advance — ship one product that has a chance, not ten that don’t.

Love the problem. Not the solution. That’s the whole discipline, one line long.

Baxter image prompt (photorealistic, 4:3): Baxter the wirehaired dachshund as a 1950s-era door-to-door market researcher in a slightly rumpled brown suit and narrow tie, clipboard clutched in his paws, standing on a suburban front porch in early evening light. Pencil tucked behind his ear. The clipboard has a printed survey visible with only one question ringed in red: “How do you currently solve this?” — the other questions crossed out. Behind him, a quiet residential street with 1950s cars. Slightly sceptical, patient expression — as if he’s heard a lot of polite lies today.