💰 She Raised $2M Without a Product—Here’s How
Don’t build blind. Use these validation experiments to find true product-market fit.
👋 Hey, Chris here! Welcome to BrainDumps—a weekly series from The Founders Corner. Every Thursday, I share unfiltered insights and stories from decades of first-hand experience. It’s a Substack exclusive, inspired by topics in my upcoming book, The Big Book of BrainDumps. Let’s get into it! 👇
Table of Contents
Why Most Products Fail Before They Launch
First Principles: Validation Isn’t About Perfection
Layer 1: “Market Engagement”—Is Anyone Even Interested?
Layer 2: “Minimal Products”—Build Only What You Need to Learn
Layer 3: “Feasibility Prototypes”—Can We Actually Build This?
Layer 4: “User Prototypes”—Observe Real Behavior
Layer 5: “Experiments in Production”—Learn While You Grow
Layer 6: Tools That Make Validation Fast and Simple
Founder Case Study: The Validation-First SaaS That Raised $2M
Final Thoughts: Make Validation Part of Your Culture
Why Most Products Fail Before They Launch
Let’s cut straight to it: most early-stage software founders build too much, too soon, for too few.
They pour months of development into a product without ever proving whether anyone actually wants it. Then they’re baffled when users don’t show up, or worse—show up and bounce.
What you should be doing is testing your riskiest assumptions first—cheaply, quickly, and repeatedly. That’s where this framework comes in.
We call it the “Product Validation Experiments Cheat Sheet”, and it’s one of the most underused tools in early product strategy. Think of it as your launch insurance policy. It’s what you do before spending your kid’s inheritance on engineers and marketing campaigns.
In this post, I’ll unpack the full framework, add founder stories from the trenches, and show you how to build momentum before you’ve even written a line of production code.
First Principles: Validation Isn’t About Perfection
Validation experiments exist to answer three critical questions:
Does it solve a real problem?
Will users engage with it?
Can it scale?
This isn’t about building a perfect product. It’s about building the right product—and knowing that it will resonate before you invest time, money, and credibility.
The core of this approach is simple: each experiment should test a specific hypothesis. Not a hope, not a hunch—a focused, falsifiable idea.
Here are a few solid hypotheses I’ve seen:
“HR managers will click on an ad promising 2x faster onboarding.”
“Users will complete an interactive demo if it leads to a free tool.”
“Our system can process 100k records in under 3 seconds using this API.”
Anchoring every experiment to a hypothesis like this does three things:
It keeps your team focused.
It accelerates your learning loop.
It keeps you honest.
One of the biggest killers in early product development is building based on wishful thinking. These experiments are your antidote.
Layer 1: “Market Engagement”—Is Anyone Even Interested?
The first category in the cheat sheet is “Market Engagement”. This is your first line of defence against wasted effort. It asks one question:
“Does the market care?”
Too many founders skip this. They fall in love with their solution before even confirming the pain is felt by others. Don’t be that founder.
🔍 Simple Experiments to Try:
Smoke Test Landing Page
Build a landing page describing your product’s core value proposition. Use Unbounce, Carrd, or Launchrock. Drive traffic via paid ads or cold outreach. Measure click-throughs and sign-ups.
Founder's tip: Add a “coming soon” form and see how many give you an email. That’s basic proof of interest.
Ad Campaigns
Run £100 worth of ads on Facebook, Google, or LinkedIn. Test different value propositions. See what gets clicks. One founder I worked with spent just £300 on 3 headlines and got clear data on what not to say in his pitch deck. That insight saved him 6 months of wrong messaging.
Email Outreach
Send 50–100 emails to a well-curated target audience (cold or warm). Measure open rates, click-throughs, and replies. If your subject line doesn’t land, your product pitch probably won’t either.
Lesson: Market interest is earned, not assumed. Treat it like a test, not a formality.
Layer 2: “Minimal Products”—Build Only What You Need to Learn
Once you see signs of interest, it’s time to test deeper—can people see the value in the product experience itself?
This is where “Minimal Products” come in. Think of these as experiments with just enough product experience to simulate the journey.
🛠 Techniques to Use:
Interactive Demos
Tools like Webflow, Framer, or Bubble can create realistic, clickable demos without real functionality. One founder simulated a financial dashboard that “updated” with pre-loaded data. Users thought it was live. Feedback was glowing. He hadn’t written a line of backend code.
Manual Concierge MVPs
Do the work yourself behind the scenes. Validate the workflow manually before automating it. I had a founder simulate an AI-generated contract system by personally writing each “generated” document. It proved the need and let him observe patterns in user preferences.
Wizard of Oz Tests
Users think the system is automated. In reality, it’s you. This is a brilliant way to test product/UX before building infrastructure. For example, a scheduling assistant product validated its value by having interns book meetings manually behind the interface.
Lesson: Don’t confuse “building a product” with “building confidence.” You want user feedback, not code glory.
Layer 3: “Feasibility Prototypes”—Can We Actually Build This?
You’ve now shown interest and early UX value. Time to test feasibility.
A “Feasibility Prototype” answers one core question:
“Can we actually build this at scale?”
This is particularly vital in deep tech, AI, fintech, or data-heavy products where assumptions about performance, security, or latency can kill you later.
🔬 What to Test:
API Mockups
Simulate a backend with dummy responses. Show what the system would do if it worked.
Performance Benchmarks
Test core processes like queries, ML models, or automation under simulated loads.
Data Availability Tests
Can you get the data you need legally, affordably, and reliably? One founder we backed discovered—before building—that their source of property data was prohibitively expensive. That saved them a year.
Lesson: Proving feasibility upfront saves time, credibility, and money. Especially when pitching to VCs who’ll ask these questions anyway.
Layer 4: “User Prototypes”—Observe Real Behavior
Now you’re getting serious. You’ve proved people care, shown a simulation, and tested feasibility.
“User Prototypes” take things a step further: you observe real people interacting with your solution.
This is where magic happens—if you’re willing to watch, not just ask.
🎯 Pro Tips:
Live Usability Sessions
Sit with (or Zoom with) users as they try your tool. Watch where they pause, click, backtrack. Tools like Lookback, Maze, or even Zoom screen shares work wonders.
Sandbox Environments
Create test environments where users can explore. Track paths, drop-off points, and “aha” moments.
Qualitative Interviews
After they try the product, ask questions like:
What did you expect?
What confused you?
Would you pay for this?
Founder's tip: People say one thing but do another. Always prioritise behaviour over opinion.
One founder I coached created a beautiful onboarding sequence. But 80% of users dropped off halfway through. Why? The value proposition wasn’t clear enough upfront. A 3-minute Loom video fixed it—and doubled conversion.
Lesson: User insight is your most reliable product compass. Use it early. Use it often.
Layer 5: “Experiments in Production”—Learn While You Grow
If you’re lucky, you’ve now got live users. But your learning isn’t done. In fact, it’s just beginning.
“Experiments in Production” are how the best SaaS companies keep learning while scaling.
This includes:
A/B Tests
Beta Features
Pricing Tests
Feature Flags
⚙️ Smart Experiments to Run:
Pricing Sensitivity Tests
Offer different pricing models to different user segments. Measure uptake and churn.
Onboarding Flow A/Bs
Try version A (guided wizard) vs. version B (tutorial video). Measure activation and retention.
Feature Gating
Release features to 10% of users via LaunchDarkly or Optimizely. Watch impact on usage.
One B2B startup I worked with tested a “pay later” CTA in their checkout flow. Conversion jumped 21%. That test earned them £20k in extra MRR over the next 3 months.
Lesson: Validation doesn’t stop at launch. The best teams embed experiments into the product culture.
Layer 6: Tools That Make Validation Fast and Simple
Don’t do this alone. The right tools speed everything up.
Here’s a quick cheat sheet:
No tool will replace good thinking. But they will make it 10x faster.
Founder Case Study: The Validation-First SaaS That Raised $2M
Let me leave you with one of my favourite examples.
A founder came to me with a B2B platform that automated supplier risk management. Instead of building the full system, she started with:
1 landing page
3 customer interviews per week
1 clickable prototype in Figma
1 Wizard of Oz flow (where she did the analysis manually)
Within 8 weeks, she had:
5 design partners
2 LOIs (letters of intent)
A waitlist of 120+
Feedback that shaped her roadmap
An investor-ready narrative
She launched 3 months later—and raised $2M in seed funding.
Why did it work? Because she proved demand, de-risked development, and spoke in the customer’s language. All before writing the first backend function.
Final Thoughts: Make Validation Part of Your Culture
Validation isn’t a phase. It’s a mindset.
The best founders treat validation as a core competency—a muscle they train. Not just something they do once to check a box.
Here’s what that looks like in practice:
Every roadmap item is tied to a hypothesis.
Every launch includes a learning goal.
Every feature is measured against impact.
VCs love this. Teams love this. Customers love this.
And most importantly—it works.
If you’re an early-stage founder, I’ll leave you with this challenge:
Run 3 validation experiments in the next 14 days.
Not to be “done,” but to learn. Pick one idea, one hypothesis, and one way to test it. Then do it again. And again. That’s how real products—and real companies—are built.
Validation isn’t optional. It’s your startup’s first superpower. Use it well.
—Chris Tottman
Jam-packed with lots of good stuff! Thank you, Chris Tootman.
Liked how you broke down validation into actionable layers, especially the real-world founder examples. Essential reading for anyone trying to raise without burning time or capital too early. Thanks for sharing this!