Solution in search of a problem: the YC term for the mistake I made

There's a name for what I did with my first startup. I just didn't know it in 2015.

I co-founded a restaurant concierge app, built it, signed more than ten partners, and launched, without validating a single assumption first. I had a solution I liked. I went looking for a problem to attach it to, and told myself I'd already found one. Y Combinator has a name for that pattern now: a SISP, a Solution In Search of a Problem.

What SISP actually means

A SISP is a product built backwards. Instead of starting with a real, painful problem and designing a solution for it, you start with a technology, a clever idea, or something that's simply fun to build, and go looking for a problem it might solve.

Here's the trap: the solution part is usually genuinely impressive. The engineering works. The design is clean. The demo gets applause. None of that tells you whether anyone has the problem badly enough to change their behavior, pay money, or bother switching from whatever they use now, including doing nothing at all.

Why it happens to smart people

SISPs aren't built by lazy founders. They're built by capable ones, which is exactly why the pattern is so persistent. Building feels like momentum. Every feature you ship looks like proof you're moving forward. Validating a problem, by contrast, feels slow, uncomfortable, and unglamorous: you have to ask strangers hard questions and sit with answers you don't want to hear.

So teams skip it. Not because they're careless, but because building is more fun than doubting, and a working prototype feels more real than an uncomfortable conversation. That's exactly what I described happening with Eminatio: activity that looked like traction but wasn't evidence of demand.

A famous public example

The most cited SISP in tech is a juicer. A well-funded startup built an internet-connected machine, engineered down to the last detail, to squeeze proprietary juice packets. It worked exactly as designed. Reporters later demonstrated that the packets could be squeezed by hand, without the machine, in roughly the same time.

The technology wasn't the problem. The technology was excellent. The problem was that "squeezing a juice packet" was never painful enough, for enough people, to justify what the solution cost to build, buy, and use. That's a SISP in one sentence: an impressive answer to a question nobody was really asking.

Are you building one right now? A quick self-check

You're probably building a SISP if:

• You can describe your product in detail, but struggle to name the specific person who has this problem badly enough to pay for a fix.
• Your validation so far is "everyone I've shown this to thinks it's cool," not "I found people already trying to solve this themselves."
• The idea started with "what if we built X," not "I keep seeing people struggle with Y."
• You haven't asked anyone what they currently do instead of your product, because it hasn't occurred to you that "nothing" is a real answer.

You're probably not if:

• You can point to specific people who are already spending time or money on a worse version of the fix.
• You've heard the same complaint, unprompted, from people who don't know each other.
• You built the smallest possible version first, specifically to see if anyone cared before you invested further.

SISP is the cause. "No market need" is the outcome.

These two ideas describe the same failure from different ends. A SISP is what you're doing while you build: solving a problem you assumed exists instead of one you confirmed exists. "No market need" is what CB Insights calls it afterward, when the product ships and nobody shows up. One is the mistake in progress. The other is the autopsy.

Most no-market-need failures started as a SISP. The founders didn't set out to build something nobody wanted. They fell in love with a solution first and mistook their own enthusiasm for market validation.

The fix isn't "stop building"

Building fast is not the problem. Building the wrong thing fast and confidently is. The fix is sequencing: find the problem and confirm it's painful for a specific group of people before you invest in a solution, or if you've already built it, get an honest read on demand before you invest further.

That's what a Jobs to Be Done conversation is for on the front end, and what a PMF survey is for on the back end. Both ask the same underlying question in different tenses: does this problem matter enough that people would be genuinely upset without a solution to it?