You Don't Know If Your Startup Idea Is Good (And That's the Point)

Ask any founder if their startup idea is good and they'll say yes. Ask them how they know, and things get quiet. Here's the uncomfortable truth we repeat at every Kiuas workshop: you don't know. Neither do we. That's exactly why we validate.

The stakes are real. According to CB Insights, the most common reason startups fail is lack of market need. Not bad code, not slow fundraising. People simply built something nobody wanted. Validation is how you avoid spending months, or years, on that mistake.

Start with the problem, not the idea

Ideas are everywhere. The only thing worth building solves a pain that's urgent, frequent, and expensive. So before anything else, write a problem statement that answers three things: who feels the pain, what the pain is, and why it matters now.

Then turn it into a hypothesis you can test and falsify: "We believe [specific customer group] experiences [specific pain] because of [underlying cause]." Your job isn't to be right. It's to find out fast.

A valid problem shows green flags: it's popular (enough people have it), growing, urgent (can't be postponed), expensive (costs time or money), and frequent. The more flags, the better the startup potential.

Know your customer by name, not persona

"Consultants" or "enterprise sellers" is not a customer segment. Think in faces, not personas: what company do they work at, what's their role, where are they, and how do you reach them? Our rule of thumb: pick a segment and find five real people you could message today. If you can't name five, the segment is too vague.

When you talk to them, ask about their life, not your idea. "Would you use this?" and "Do you think this is a good idea?" produce polite lies. Ask about specifics in the past instead: "Walk me through the last time this happened." "How often did it happen this year?" "How much did you spend to fix it?"

Try to kill your idea

This is the part most founders get backwards. The goal of customer interviews isn't to confirm you're right, it's to disprove your hypotheses. Negative observations are good data. Filter out fluff (hypotheticals, future intent), compliments ("cool idea"), and feature requests, none of it is validation.

Then decide: scrap when no one cares, pivot when some hypotheses are disproven, proceed when you've found a pain that's urgent, frequent, and expensive.

You've truly validated an idea when you've interviewed more than 15 people and found recurring pain points, identified early adopters and can define your ICP, the problem is a must-solve rather than a nice-to-have, and you can describe the existing solutions your idea improves in detail. One Kiuas alumni founder did 100 validation interviews before writing a line of product code.

And remember: validating an idea is not the same as validating a product, which is not the same as validating a business model.

Build the smallest thing you can sell tomorrow

Only now does building enter the picture. An MVP exists to test whether your solution solves the validated problem, so optimize for learning, not scaling. Deliver the service manually before automating it. Sell with a Figma or Lovable mock-up. Put up a landing page with a waitlist button and a 50 euro ad campaign to test conversion. Ask yourself: what can I build in 24 hours that I could put in front of a customer tomorrow?

The best validation of all? Paying customers. That's the Kiuas way of building: customer-obsessed, sales-led, and validation-focused, because the most expensive thing you can do as a founder is build something nobody needs.

Ready to put this into practice? Set a 14-day sprint: decide how many customers to contact, which MVP tests to run, and which metric to follow. Then analyze and iterate.