How to validate a product idea before spending months building

Most product ideas that fail didn’t fail because of poor execution. They failed because the team built something nobody wanted, and found out too late.

Validation exists to compress the feedback loop. Instead of spending four months building to find out if the idea works, you spend two weeks finding out if it’s worth building at all.

This is the checklist we run through at Succedo Labs before scoping any new product build. It’s short, intentionally uncomfortable, and designed to surface the truth faster than the build process will.

Move 1: State the riskiest assumption

Every product idea rests on assumptions. Most founders can list ten. Only one of them is the riskiest — the one that, if it’s wrong, makes the entire business case collapse.

Write it down in one sentence: “This product only works if [specific assumption] is true.”

Examples of riskiest assumptions:

“Users will switch from Excel to our tool for this task”
“Businesses will pay £200/month for this, not just use a free alternative”
“Operations teams will actually log data into the system rather than work around it”

If you can’t name the riskiest assumption, you’re not ready to validate. The entire point of validation is to test this one thing as quickly and cheaply as possible.

Move 2: Run the landing page test

Before anything else: build a one-page website that describes the product as if it exists. Write it like it’s live. Include a clear value proposition, a feature list, and a call-to-action — “Join the waitlist,” “Request early access,” or “Book a demo.”

Then drive 200–300 targeted visitors to it. Use a small budget on LinkedIn or Meta ads targeted at your exact persona.

What you’re measuring:

Click-through rate on the CTA (above 5% is a positive signal)
Email capture rate (above 15% of visitors is strong interest)
The questions people ask when they sign up or email you

The landing page test takes one week and costs £200–£500 in ad spend. It gives you real signal before you’ve written a line of code.

Move 3: The manual version test

Before building the automated version, manually do the thing your product will do.

If you’re building a platform that automatically matches freelancers to projects — manually match ten freelancers to projects yourself, using email and a spreadsheet. If you’re building a dashboard that aggregates supplier pricing — manually pull the data and send a weekly email to five test users.

This is sometimes called “concierge MVP” or “Wizard of Oz testing.” It lets you:

Discover what actually matters to users before locking in your feature set
Learn whether people value the outcome enough to pay, before they know it’s manual
Find the edge cases and exceptions that will define your product requirements

If users don’t value the manual version enough to pay for it or use it regularly — they won’t value the automated version either.

Move 4: Find five people who will pay before you build

The clearest validation signal is not a waitlist sign-up. It’s a payment.

Before committing to a full build, find five people who fit your target customer profile and tell them exactly what you’re building. Then ask them: “Would you pay X per month for this if it existed today? Can I put a card on file?”

This conversation is uncomfortable. That discomfort is the point.

If you can’t find five people willing to commit, one of two things is true: either your idea isn’t solving a real problem, or you’re not talking to the right people. Either is important to know before you build.

If you find them — you don’t just have a validated idea, you have your first five customers before you’ve written a line of code.

Move 5: The teardown audit

Before committing to your product, build a clear picture of the competitive landscape.

List every existing solution — direct competitors, indirect competitors, and substitutes (including doing nothing, using a spreadsheet, or hiring a person). For each one:

Who uses it?
What does it cost?
What are the top five user complaints? (Check reviews on G2, Capterra, Reddit, App Store)
Why would someone switch to your product?

The teardown audit usually produces one of three findings:

A crowded space with undifferentiated offerings: Real demand, but entering requires a meaningful different angle.

An existing solution with a clear gap: Users are paying but complaining about specific things. Your product can own the thing they hate.

No solution exists: Either a genuine opportunity nobody has seen, or a graveyard of failed attempts. Research which one.

What a passing validation looks like

Not a perfect score — a realistic signal.

Green flags: Meaningful CTR on a landing page, real users completing the manual version, at least three people willing to pay upfront, a clear competitive gap your product can own.

Red flags: A strong network effect driving all your interest (friends and family saying “great idea!” doesn’t count), no willingness to pay at any price, a competitor with strong reviews and network effects already in the market.

The honest test: After running these five moves, would you bet your own money on this idea? Not confident, comfortable money — real, this-could-go-wrong money.

If the answer is no, you haven’t found your riskiest assumption yet. Keep digging. If the answer is yes — you’re ready to scope and build.

The build is the expensive part. Two weeks of uncomfortable validation is the best investment you’ll make.