Most failed SaaS products didn’t fail because the code was bad. They failed because they solved a problem nobody was willing to pay to fix. The good news: you can find that out in a couple of weeks, before you write a single line of code, and save yourself months of wasted effort.
Start with a problem you can describe in one sentence
If you can’t state the problem clearly — who has it, when it hurts, and what it costs them — you don’t understand it well enough to solve it yet. “Small e-commerce owners lose sales because their product photos look amateur” is a problem. “A better tool for stores” is not. Write your one sentence and keep sharpening it until a stranger nods immediately.
Talk to ten real people before building anything
This is the step everyone skips and everyone regrets. Find ten people who genuinely have the problem and have a real conversation — not a pitch. Ask how they handle it today, what they’ve tried, and what the workaround costs them in time or money. You’re listening for frustration, not politeness.
Pay attention to the exact words they use. When someone says “I waste every Sunday night reconciling orders by hand,” that sentence is worth more than any survey. It tells you the problem is real, recurring, and painful — and it becomes your marketing copy later.
Watch what people do, not just what they say
People are optimistic in interviews. “Yeah, I’d definitely use that” is cheap. Real signals cost something: would they give you their email, join a waitlist, pay a small deposit, or spend an hour helping you shape it? Action is the only honest vote. If nobody will take a small step now, they won’t take a big one later.
Build a landing page, not a product
Put up a single page that describes the outcome your product delivers, with one clear call to action — usually an email signup or an “early access” button. Drive a little traffic to it, from communities where your people already gather or a small ad budget. The signup rate tells you whether the promise resonates. This costs a weekend and teaches you more than three months of building.
Try to pre-sell before you build
The strongest validation of all is money. If you can get even a handful of people to pay — for early access, a founding-member discount, or a pilot — you’ve proven demand in the only way that counts. Free interest is easy; paid interest is rare and real. A few paying pilots also give you committed early users who’ll shape the product with you.
Know what a “no” is telling you
If validation fails, that’s not wasted time — it’s a cheap lesson. Maybe the problem is real but not painful enough to pay for. Maybe you’re aimed at the wrong audience. Maybe the timing is off. A failed test before building is a gift; a failed product after a year of building is a wound. Adjust and test again.
Then, and only then, build the smallest thing
Once you have signal — interviews full of frustration, a landing page that converts, a few people who paid — build the smallest version that delivers the core value. Not the vision. The core. You’ll refine everything else with real users guiding you.
Validation isn’t a phase you rush through to get to the “real work.” It is the real work at the start. Do it honestly and you’ll either build with confidence or dodge a costly mistake. If you’d like help pressure-testing an idea or building that first version once it’s validated, that’s exactly the kind of work I do with founders.