A friend of mine runs a small catering business in Graz. A few years ago, she came to me frustrated. “I spend more time chasing invoices than cooking,” she said. She knew the problem cold. But she had no idea how to think about solutions in a structured way. She just kept oscillating between “I should build an app” and “maybe I need to hire someone.”
This is where most people get stuck. They can feel the problem. They can describe it vividly. But the gap between “this sucks” and “here’s the fix” feels enormous and formless.
It doesn’t have to be. Over 20+ years of innovation consulting and running the Startup Burgenland accelerator, I’ve distilled the problem-to-solution process into five steps that work whether you’re building a side project or launching a company. They’re not revolutionary. They’re just disciplined.
Step 1: Define the Problem in One Sentence
This sounds easy. It isn’t.
Most people describe symptoms, not problems. “I can’t get enough customers” is a symptom. “My target market doesn’t know I exist because I have no distribution channel” is a problem. “I’m always busy but never profitable” is a symptom. “My service delivery takes 12 hours but I can only charge for 6” is a problem.
A properly defined problem has three characteristics: it identifies a specific group of people, it describes what’s going wrong for them, and it hints at why existing solutions don’t work.
Here’s the template I use: “[Specific group] struggles with [specific problem] because [reason existing solutions fail].”
For my catering friend, it became: “Solo caterers spend 4+ hours per week chasing unpaid invoices because their current tools (spreadsheets, email reminders) have no automated follow-up.”
That one sentence changes everything. Suddenly you’re not solving “invoicing” — you’re solving automated follow-up for solo operators. The specificity narrows your solution space dramatically, which is exactly what you want.
Your action: Write your problem statement now. If it takes more than one sentence, it’s too vague. If it doesn’t name a specific group and a specific failure, revise it. I talk more about this in problem-first thinking.
Step 2: Talk to Ten People Who Have This Problem
Not five. Not three. Ten.
The reason is statistical: with fewer than ten conversations, you’ll over-index on individual quirks. One person’s weird workflow will seem like a pattern. Ten conversations give you enough data to see what’s consistent across the group.
These conversations should follow a simple structure:
- Confirm the problem exists. “How do you currently handle [problem]?” If they say “it’s not really an issue for me,” that’s data. Don’t argue with it.
- Understand the current solution. “Walk me through what you do today.” This reveals the workarounds people have built, which tells you what they value enough to spend time on.
- Find the pain points. “What’s the most annoying part of your current approach?” This is where gold lives.
- Test willingness to switch. “If something better existed, what would it need to do?” This tells you the minimum bar for adoption.
Do not pitch your solution during these conversations. You’re gathering intelligence, not selling. The moment you start explaining your idea, the conversation shifts from honest discovery to polite validation.
When I was working with startups at Startup Burgenland, the teams that skipped this step or half-did it (talking to three friends) consistently built solutions that solved the wrong version of the problem. The ten-conversation minimum isn’t arbitrary — it’s the threshold where patterns become visible.
Your action: Identify ten people with this problem and schedule the conversations. If you can’t find ten people, that itself is a signal about whether the demand is real.
Step 3: Map the Existing Solutions and Their Gaps
After your ten conversations, you should be able to map what people currently use and where those solutions fall short.
Create a simple table:
| Current Solution | What It Does Well | Where It Fails |
|---|---|---|
| Spreadsheets | Free, flexible | No automation, easy to forget |
| Accounting software | Professional | Too complex for solo operators, expensive |
| Email reminders | Simple | Manual, easy to miss, feels uncomfortable |
The “Where It Fails” column is your opportunity space. If every existing solution fails in the same way, that’s where your solution needs to win.
But here’s the critical insight: you don’t need to be better at everything. You need to be dramatically better at the one thing that matters most. My friend’s catering contacts all said the same thing: “I just wish it would follow up for me without me having to think about it.” They didn’t care about beautiful invoices or accounting integration. They cared about one thing: automation of the awkward follow-up.
This is the subtraction principle in action. Strip away everything that doesn’t address the core gap. The simpler your solution is, the faster you can build it and the easier it is for people to understand.
Your action: Build your table from the ten conversations. Circle the gap that appeared most often. That’s your target.
Step 4: Design the Smallest Possible Solution
Now you know the problem, you’ve confirmed it with real people, and you’ve identified the specific gap in existing solutions. Time to design something.
The temptation here is to build the complete vision. Resist it violently.
Your first solution should address exactly one gap for exactly one type of user. Nothing more. This is harder than it sounds because your brain will keep generating “wouldn’t it also be great if…” ideas. It would be great. Later. Not now.
For the catering example, the smallest possible solution was: a simple form where you enter a client’s email and invoice amount, and the system sends three automated reminders at 7, 14, and 21 days. No invoicing. No accounting. No client portal. Just the reminders.
Could you build that in a weekend? Probably. Could you build the full-featured invoicing platform in a weekend? Absolutely not. And the weekend version tests the core hypothesis: do solo caterers actually want automated follow-up badly enough to use it?
This connects directly to the concept of shipping it ugly. Your first version isn’t supposed to be impressive. It’s supposed to be testable.
Design your smallest solution by answering three questions:
- What is the single most important thing it does?
- Who is the single most likely user?
- What is the fastest way to deliver this to them?
Your action: Sketch your smallest possible solution. If it would take more than two weeks to build (or assemble from existing tools), it’s not small enough. Cut more.
Step 5: Get It in Front of Real People and Measure
The final step is the one that separates people who think about businesses from people who run them. You put your solution in front of the people you interviewed and watch what happens.
Not what they say about it. What they do with it.
There are only three metrics that matter at this stage:
- Activation: Do people actually use it after signing up? If 50 people sign up and 3 use it, you have an activation problem — the solution is either too confusing or doesn’t match what they expected.
- Retention: Do they come back? If people use it once and never return, the problem might not be frequent enough or your solution might not be good enough.
- Willingness to pay: Will they give you money for it? Not “would they hypothetically pay” but “did they actually pay when you asked?” This is the ultimate validation, and it’s why landing your first paying customer matters more than any other metric.
My friend’s catering tool? She built a basic version using a no-code automation tool, gave it to the ten people she’d interviewed, and four of them used it consistently. Two of those four said they’d pay for it. That’s a 20% conversion rate from interview to paying customer, which is strong enough to keep building.
If zero people use it, go back to Step 2. You likely misunderstood the problem. If people use it but won’t pay, go back to Step 4. Your solution might be nice-to-have rather than need-to-have.
Your action: Set a deadline to get your smallest solution in front of at least five of the people you interviewed. Track the three metrics above. Give it two weeks, then decide: kill or commit.
The Full Loop
These five steps form a loop, not a line. Most successful products go through this cycle multiple times, refining the problem definition, talking to more people, mapping new gaps, simplifying the solution, and testing again.
The mistake is treating this as a one-time process. It’s not. It’s how good businesses stay good — they keep returning to the problem, keep talking to real people, and keep asking whether their solution still fits.
But you have to start the loop somewhere. And you start it by writing one sentence that defines the problem.
Takeaways
- Define the problem in one sentence. Include who has it, what’s going wrong, and why existing solutions fail. If you can’t do this, you don’t understand the problem yet.
- Talk to ten real people. Not friends, not family — people who actually have the problem. Listen more than you talk.
- Map existing solutions and their gaps. Find the one failure that comes up most often. That’s your target.
- Design the smallest possible solution. Address one gap for one user type. If it takes more than two weeks to build, cut more.
- Measure behavior, not opinions. Activation, retention, and willingness to pay are the only three metrics that matter at this stage.
