A founder walked into my office at the Startup Burgenland accelerator and said: “I want to build an AI-powered scheduling assistant.” I asked him what problem it solved. He paused. “Well… scheduling is hard.” I asked who specifically found scheduling hard, and what they were doing about it currently. Longer pause. “Everyone? And they use calendars?”
He had a solution looking for a problem. This is the default mode for most founders, and it’s the primary reason most startups fail. Not because the solution is bad — often it’s technically impressive — but because nobody asked for it.
Problem-first thinking inverts the process. You start with a specific, painful, recurring problem experienced by a definable group of people. The solution comes later — and often looks nothing like what you would have built if you’d started with a solution in mind.
Why Solution-First Thinking Is the Default
We start with solutions because solutions are more fun to think about.
A solution is tangible. You can sketch it. You can imagine the interface. You can describe the features. You can get excited about the technology. There’s creative energy in designing something new.
A problem, by contrast, is messy. It’s about someone else’s frustration, not your creativity. It requires empathy rather than engineering. And understanding a problem deeply often reveals that the problem is more complex than you assumed, which is deflating rather than energizing.
There’s also a cultural bias at play. The startup world celebrates products. We celebrate launches, features, and designs. We put products on Product Hunt and applaud them. We don’t celebrate “I spent three weeks understanding why accounts receivable managers hate Tuesdays” even though that understanding is worth more than any launch.
The media reinforces this. Every startup profile focuses on the product: what it does, how it works, what technology it uses. The problem investigation that preceded the product — the months of conversations, failed experiments, and dead ends — is compressed into one sentence or omitted entirely.
The result is that every aspiring founder thinks the way to build a business is to think of a product. The actual way is to find a problem that people will pay to solve and then build the simplest possible thing that solves it.
The Problem Stack: Going Deeper Than the Surface
Most problems have layers. The surface-level problem is what people say. The real problem is usually two or three layers down.
Consider this example from a coaching client of mine.
Surface problem: “I can’t find good freelance developers.”
One layer down: “The developers I find can’t work within my budget.”
Two layers down: “I don’t know how to scope projects accurately, so I get quotes that are 3x what I expected.”
Three layers down: “I don’t understand what’s technically complex versus what’s simple, so I can’t distinguish between a fair quote and an inflated one.”
If you build a solution for the surface problem, you create another freelancer marketplace. The world has fifty of those. If you build for the deepest layer, you create a “technical scoping for non-technical founders” service. That’s a far more specific and defensible business.
Here’s how I dig through the layers with customer conversations:
- Start with: “What’s the problem?” (Surface)
- Then: “Why is that a problem?” (First layer)
- Then: “What have you tried?” (Reveals which layer they’re solving at)
- Then: “What specifically didn’t work about that?” (Goes deeper)
- Then: “If that were fixed, what would still be frustrating?” (Deepest layer)
This is essentially the “Five Whys” technique adapted for customer conversations. It’s simple. It’s tedious. It works.
The deepest layer is usually where the real business lives because nobody else has bothered to dig that far. Everyone’s building freelancer marketplaces because that’s the surface-level problem. Almost nobody’s helping non-technical founders scope projects because that requires understanding both the customer’s world and the developer’s world. Complexity at the problem level is actually a moat at the business level.
The Problem Validation Checklist
Not every problem is worth solving as a business. I use this checklist to determine if a problem clears the bar.
Is it frequent? Does the person encounter this problem at least weekly? Monthly at minimum? A problem someone faces once a year generates a one-time transaction. That’s fine for some businesses, but recurring problems create recurring revenue.
Is it painful? On a scale of “mild annoyance” to “actively costing me money or sleep,” where does this fall? If people describe the problem with emotional language — frustration, dread, anger — it’s painful enough. If they shrug, it’s not.
Is it currently being solved badly? This is the most important filter. If people are already spending money or time on inadequate solutions, you have a market. If they’re not trying to solve it at all, either the problem isn’t painful enough or they’ve accepted it as unchangeable.
Can you reach the people who have this problem? A problem experienced by a scattered, undefined group of people is almost impossible to build a business around. A problem experienced by “freelance accountants in the DACH region” is very buildable because you can find those people.
Can you solve it 10x better than the current solution? Not 10% better — 10x. Incremental improvements don’t motivate switching behavior. Dramatic improvements do. If your solution is only marginally better than what exists, you’ll struggle to convert even the most frustrated customers.
If a problem passes all five checks, you have something worth pursuing. If it fails any two, keep looking. I’ve used this checklist to say no to dozens of appealing ideas that felt right but didn’t pass the logic test.
Mapping Problems to Business Models
Once you have a validated problem, the next step isn’t to jump to a product. It’s to map the problem to the right business model.
Problem type: “I need this done for me.” Business model: Service or done-for-you offering. Example: “I need my taxes filed correctly” → Accounting service.
Problem type: “I need to do this faster.” Business model: Tool or software. Example: “I need to create invoices without spending 30 minutes each time” → Invoicing tool.
Problem type: “I need to learn how to do this.” Business model: Education or training. Example: “I need to understand Facebook ads” → Course or coaching.
Problem type: “I need to find the right [thing/person].” Business model: Marketplace or curation. Example: “I need to find a developer who understands my industry” → Specialized marketplace.
Problem type: “I need ongoing support with this.” Business model: Membership or subscription. Example: “I need regular guidance on growing my business” → Community or coaching subscription.
The mapping matters because it determines your revenue model, your cost structure, and your scalability path. A problem that maps to “I need this done for me” produces a service business with limited scalability but high margins. A problem that maps to “I need to do this faster” produces a tool with high scalability but requires development investment.
Most founders pick the business model first (I want to build a SaaS!) and then try to find a problem that fits. Problem-first thinking inverts this: find the problem, let the problem tell you what model it needs, and build accordingly.
Problem-First Case Studies
Let me share two stories — one where problem-first thinking worked and one where solution-first thinking failed.
Success: The compliance notification service.
A founder at our accelerator noticed that small business owners in Austria constantly missed regulatory deadlines — tax filings, compliance updates, license renewals. Not because they were lazy, but because the regulatory environment changed frequently and nobody aggregated the information.
Instead of building a compliance platform, she started with the problem. She interviewed 30 small business owners and found that the specific pain was missing deadlines that resulted in fines. The problem was frequent (monthly deadlines), painful (average fine was €800), and being solved badly (most owners relied on their accountant to remember, which was unreliable).
Her first product was an email newsletter. Every month, she manually compiled a list of upcoming deadlines and sent it to subscribers. She charged €9/month. Within three months, she had 200 paying subscribers. The problem told her the solution should be simple, recurring, and information-based. If she’d started with “I want to build a platform,” she’d still be coding.
Failure: The AI meeting scheduler.
Remember the AI scheduling assistant founder from the beginning of this article? He built it anyway. It was technically impressive — natural language processing, calendar integration, conflict resolution. Beautiful product.
But the problem he thought he was solving (scheduling is hard) wasn’t actually how people experienced it. Most professionals had already adapted to scheduling friction. They used Calendly, Doodle, or just emailed back and forth. It took a few minutes each time. Mildly annoying, not painful.
The product attracted early adopters — tech-savvy people who liked trying new AI tools. But they weren’t paying for a solution to a painful problem. They were playing with a novelty. Retention was terrible. Revenue never materialized.
If he’d started with the problem, he would have discovered through proper customer conversations that scheduling friction is a symptom, not a cause. The actual problem — for the people who were genuinely frustrated — was back-to-back meetings leaving no time for focused work. That’s a different problem with a different solution (a scheduling tool that blocks focus time and automatically declines conflicting meetings).
Same technology. Different problem. Completely different business outcome.
Key Takeaways
- Start with the problem, not the solution. Solutions are fun to design but useless without a validated problem. Problems are messy but they’re the foundation of every real business.
- Dig through the problem layers. The surface problem is where everyone competes. The problem three layers deep is where the real business lives.
- Use the five-check validation checklist: frequent, painful, currently solved badly, reachable customers, 10x improvement possible.
- Let the problem determine the business model. “I want to build a SaaS” is backwards. Find the problem, map it to the right model, build that.
- Problem-first thinking takes discipline because our brains prefer solution-first creativity. The discipline pays off in businesses that actually have customers.
