Problem-Solution Fit in 5 steps

Most startups fail because nobody needed what they built. Not because the code was slow, not because the design was ugly, and rarely because a competitor was faster. The demand was never there in the first place, and everybody found out eighteen months and a seed round too late.

Problem-Solution Fit is the checkpoint that catches this. It comes before Product-Market Fit and it asks a much smaller question: does a specific group of people have a problem painful enough that they would use your specific solution to it?

Here is the sequence I run with founders. Five steps, in this order, and the order is the part people get wrong.

1. Start with a beachhead market

Do not try to serve everyone. Pick one narrow segment you can realistically dominate, and be specific enough that you could list the names of fifty people in it.

Airbnb began as air mattresses in a San Francisco apartment during an Industrial Designers Society of America conference, aimed at designers who could not get a hotel room in a city where everything was booked. Not "travellers". Not "people who need accommodation". Attendees of one conference, in one city, one weekend. That is what a beachhead looks like from the inside.

The reason to go narrow is not modesty. It is signal. A broad segment gives you weak, contradictory feedback from people with nothing in common. A narrow one gives you a pattern after five conversations, because everybody in it has the same job and the same constraints. When we took FOUND from zero to Product-Market Fit, the work that mattered most was choosing the beachhead and refusing to widen it early.

2. Do primary research before you define anything

Talk to real people in that segment. Not a survey, not your investor's opinion of the space, not a market report. Conversations.

The goal is to understand the problem as it currently exists for them, including whatever ugly workaround they are using instead of a product. That workaround is your real competitor, and it is usually a spreadsheet.

Ask story questions. "Tell me about the last time you did this" or "walk me through what happened the last time this went wrong." Past behaviour is fact. Predicted behaviour is fiction, and asking people what they want hands them a job that is yours. That is the whole trap behind the Product Death Cycle. If you need a starting point, five conversations this week is a real plan.

3. Define the product by the benefit, not the feature list

Now translate what you heard into a solution, using whatever your team is actually good at. This is where founders reach for the feature list, and it is the wrong artefact.

Write the benefit, and quantify it. "We save two days of work per week" is a value proposition. "AI-powered workflow automation" is a description of a technology and tells a buyer nothing about whether their week gets better.

The test: read your one-sentence value proposition to someone in your beachhead segment and watch their face. If they ask a clarifying question about what it does, rewrite it. If they ask when they can have it, keep going.

4. Test the riskiest assumptions, in the right order

You are now holding a set of assumptions, not a plan. Write them down and sort them into three buckets:

• Desirability. Do they want it? Will they choose it over the spreadsheet?
• Viability. Does it work as a business? Will anyone pay enough, often enough?
• Feasibility. Can you actually build and run it?

Test demand first. It is the cheapest to test and the most likely to kill the idea, which makes it the highest-value test you can run. Landing pages, ads, smoke tests, and fake door tests all answer the desirability question in days rather than quarters.

Once something wants to exist, validate value and viability with prototypes and Wizard of Oz tests, where you deliver the outcome manually behind the scenes while the user experiences the finished thing. It is unglamorous and it works. You learn what people do with the value before you spend anything automating the delivery of it.

Feasibility goes last for most software products, because it is usually the assumption you are least wrong about. The exception is genuinely novel technology, where feasibility is the risk and belongs at the front.

5. Build the smallest thing that solves one problem

Only now does an MVP make sense, and only if it solves one core problem completely rather than five problems partially.

No-code platforms and AI-assisted builders have collapsed the cost of this step to close to nothing, which is exactly why the discipline of the first four steps matters more than it used to. When building was expensive, cost forced you to think. Now it does not, and the only thing standing between you and a beautifully built product nobody needs is whether you did the work above.

Then iterate against real usage until the loop closes: they have the problem, they use your thing for it, and they come back. That is Problem-Solution Fit.

How you know you have it

You have Problem-Solution Fit when people in your beachhead use the product repeatedly without being chased, when they describe the problem back to you in the words you now use, and when taking it away would visibly annoy them.

What you do not have yet is Product-Market Fit. That is the next question and a much bigger one: whether the market is large enough and reachable enough to build a business on. It has its own definition and its own measurement, and it is worth being precise that PMF is a hypothesis you test rather than a feeling you get.

The founders who move fastest through these five steps are not the ones who skip them. They are the ones who compress each step into days instead of months, which mostly comes down to knowing which assumption to attack first. That is the whole shape of our 0 to 1 Product Development Workshop: one day, from raw idea to a validated value proposition and a test plan for the assumption that would sink it.

Nobody needs another well-built product that nobody needed. Spend the two weeks before you build. It is the cheapest two weeks in the whole company's life.