Problem-Solution Fit in 5 steps

Startups rarely die because the code was bad. They die because nobody needed the thing.

Problem-Solution Fit is the checkpoint that catches that, and it sits earlier than most founders think. It is not Product-Market Fit. It is the evidence, gathered before you commit, that a specific group of people has a problem worth solving and that your proposed solution actually relieves it.

Product-Market Fit comes later, when a market starts pulling the product out of you. It is a hypothesis you can define and test, not a feeling, and you will not get near it if you skipped this step.

Here is the sequence I run with founders, in the order that keeps it cheap.

1. Start with a beachhead market

Do not try to serve everyone. Pick a specific niche you can realistically dominate.

This is how we took FOUND, a Swiss recruitment platform, from zero to Product-Market Fit: focus on one narrow beachhead, validate demand there, and only then widen.

Narrowing is not modesty, it is economics. A narrow segment makes every later step cheaper. You can actually find ten of them. They share the same problem, so their answers converge instead of averaging into noise. And when something works, you can tell why.

A useful test: can you name where to find twenty of these people this week? If not, your segment is a description, not a market.

2. Do primary research

Talk to real people in that segment and uncover the needs nobody is meeting.

Ask story questions, not opinion questions. "Tell me about the last time you ran into this. Walk me through what you did." Never "would you use this" - people are poor at predicting their own behaviour and generous about your ideas. The practical version of this is simple enough to start on Monday: talk to five customers this week.

What you are listening for is a workaround. Real problems have scar tissue: a spreadsheet, a WhatsApp group, a manual process someone does every Friday, an intern. A workaround is evidence that the problem costs enough for someone to have already paid to reduce it. "That sounds useful" is evidence of politeness.

3. Define the product in benefits, not features

Now translate what you heard into a solution your team is genuinely capable of building. Your expertise is part of the input, not an afterthought.

Then describe it by what it delivers, not what it contains. Quantify the core value proposition: "saves two days of work a week", "cuts the approval loop from five days to one". If you cannot put a number on the benefit, you have not understood the problem well enough yet, and that is a research gap rather than a copywriting gap.

4. Test your riskiest assumptions, cheapest first

Write down what has to be true for this to work, then sort by what would hurt most if it were false. Assumptions cluster into desirability (do they want it), viability (does it work as a business), and feasibility (can we build it). A product trio is set up to cover all of them at once rather than in sequence.

Order matters, because the tests get more expensive as you go:

• Demand first. Ads, landing pages, smoke tests. A fake door test tells you whether anyone reaches for the thing before you have built any of it.
• Then value and viability. Wizard of Oz tests, where you deliver the outcome manually, and prototypes people can react to. You are checking whether the solution actually relieves the problem, and whether the economics survive contact with a price.

One discipline makes the difference between testing and theatre: write the assumption as a falsifiable sentence with a number in it before you run anything. "At least 3 of 10 will book a call" is a test. "Let's see how it goes" is a way of interpreting any result as encouraging.

5. Build an MVP that solves one problem

Minimum does not mean a shrunken version of everything you eventually want. It means one core problem, solved properly, for that beachhead.

The build is the cheap part now. No-code platforms and AI app builders will get a working version in front of real users in days rather than months, which is why the sequencing above matters more than it used to - the expensive mistake is no longer building the thing, it is building the wrong thing quickly. If you need a starting point, the tools I actually recommend are listed with what each one is for.

Then iterate on real feedback until the signal changes.

How you know you have it

Problem-Solution Fit is not a vote. It looks like this:

• People come back without being nudged. Repeat usage you did not prompt is the single strongest signal at this stage.
• They ask to pay, or they pay, or they push you on pricing rather than on whether they need it.
• They explain the value to someone else in their own words, and their words match your value proposition.
• They complain when it breaks. Indifference is the real failure mode, not criticism.

Only after that does it make sense to worry about growth, and to start measuring properly. Early on, the numbers play a different role than most founders expect - worth understanding before you build a dashboard you cannot yet trust, which is what metrics for 0 to 1 products is about.

Running this whole sequence in one focused pass, on your idea, with your assumptions on the wall, is exactly what the 0 to 1 Product Development Workshop is for.

The point of doing it in this order

Every step above is cheaper than the one after it. Choosing a beachhead costs an afternoon. Interviews cost hours. A smoke test costs a day. An MVP costs weeks. Building first and validating later inverts that, which is why it feels fast right up to the moment it turns out to have been the slowest possible route.

Start with who. Then the problem. Then the evidence. The code comes last, and it comes cheap.