⏳ Stop Wasting Time: 5 Brutal Steps to Find Out If Anyone Actually Wants Your Product
Before you write a single line of code, do this—or risk building a startup no one wants.
👋 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
Founders Don’t Fail Because They Can’t Build—They Fail Because They Build the Wrong Thing
Wait… What’s Pretotyping?
Pretotyping vs. Prototyping—Know the Difference
Why Pretotyping Matters (More Than Ever)
The Palm Pilot Story: Pretotyping’s Famous Origin
5 Steps to Running a Pretotyping Test
Examples of Pretotyping in the Wild
But What About Prototyping?
The Smart Sequence: Pretotype → Prototype → Build
How I Learned This the Hard Way
How to Embed Pretotyping Into Your Culture
Final Word: Test Before You Burn
Founders Don’t Fail Because They Can’t Build—They Fail Because They Build the Wrong Thing
I’ve been around startups long enough to see the same story on repeat:
A founder has a brilliant idea.
They spend 6–12 months building it.
They launch.
...And then, silence.
No one signs up.
Or worse, people sign up but never use it again.
When I ask them what went wrong, they usually say some version of:
“We thought the market wanted this.”
And that’s the core issue: they guessed.
They skipped the step that could have saved them time, money, and months of frustration. They built before testing.
That’s why I’m obsessed with a framework that too few founders know about—and even fewer use well:
Pretotyping.
Wait… What’s Pretotyping?
You’ve probably heard of prototyping:
Building a quick, working version of a product to test how it works.
Pretotyping comes before that.
It tests whether people actually want the product—before you write a single line of code.
To borrow from Alberto Savoia, the guy who coined the term:
“Pretotyping is about building the right ‘it’ before you build ‘it’ right.”
It’s rough, fast, and brutally useful.
I first came across it when I was advising a startup that wanted to launch a complex scheduling engine for enterprise teams. We’d built mockups, scoped the architecture, and were ready to allocate engineers.
But something didn’t sit right.
So we launched a single landing page with a “Request a Demo” button. No product. Just the problem, the promise, and a call to action.
Guess how many requests we got?
Two.
From 5000 visits.
That landing page saved us six months of development and helped us pivot toward a feature set users actually wanted.
That’s pretotyping in action.
Pretotyping vs. Prototyping—Know the Difference
Let’s get really clear:
Too many founders skip the first column and go straight to the second.
The result? They build something people politely praise—but never pay for.
Why Pretotyping Matters (More Than Ever)
Let me tell you about a founder I backed who got this absolutely right.
They were working on a B2B SaaS platform to simplify compliance for small financial firms. Exciting market. Complex space.
But instead of hiring a dev team straight away, they ran Facebook and LinkedIn ads driving to a “coming soon” page. The signup form asked:
“What’s your biggest compliance pain right now?”
They got 300 responses in two weeks. The insights changed the roadmap.
They scrapped 3 of their planned features. Doubled down on one.
That one became their wedge—and within six months of launch, they’d hit £20k MRR.
That founder didn’t guess. They tested demand first.
The Palm Pilot Story: Pretotyping’s Famous Origin
In the 1990s, Jeff Hawkins had an idea for a personal digital assistant (PDA).
But instead of building it, he took a block of wood, carved it to the size he imagined, and carried it around for weeks.
He pretended to check his calendar. Took “notes.” Showed it to friends. Simulated what real usage would feel like.
The wooden block had no screen. No tech. No battery.
But it gave him insight.
That insight? People would use something like this. And more importantly, how they would use it.
The Palm Pilot went on to sell millions. All starting with a piece of wood.
5 Steps to Running a Pretotyping Test
Here’s how to do it, whether you’re at idea stage or building a new feature.
1. Isolate Your Key Assumption
Every product idea has a bet baked in.
“Busy founders will pay for AI-generated investor updates.”
“Marketing leads want drag-and-drop dashboards.”
Whatever it is—write it down. This is what you’re testing.
2. Create a Pretotype
No need for code. Think:
Landing page with a CTA
Google Form
Figma mockup
“Buy now” button with no cart
Explainer video
Email pitch as if the product exists
Paper prototype
The goal is to simulate the promise of the product.
3. Make a Hypothesis
Quantify success. For example:
“25% of visitors will click the demo button.”
“100 people will sign up within a week.”
“3 out of 10 pitches will convert to a meeting.”
Be specific. No squishy success metrics.
4. Run the Test
Push it live. Send traffic. Get reactions. Run interviews. Record everything.
At this stage, your goal is signal, not scale.
5. Measure + Decide
If the results are strong: proceed.
If they’re unclear: iterate.
If they flop: pivot or kill the idea.
You’ve either saved yourself a tonne of money—or found something worth building.
Examples of Pretotyping in the Wild
These are real pretotype tests I’ve seen work inside startups:
The Button Test:
Add a feature button to your app that doesn’t do anything—yet. Track clicks.The Concierge Test:
Manually deliver a service that will later be automated.The Landing Page Test:
Describe a feature or product as if it exists, and see if people sign up.The “Coming Soon” Email Test:
Email your user list announcing a new feature. Track opens, replies, click-throughs.The Interview Script Test:
Pretend you're already live. Pitch to 10 ICPs. Track interest and objections.
But What About Prototyping?
Prototyping comes after pretotyping—and it’s still essential.
This is where you answer: how will this product work?
You build UI flows. Figma mocks. Clickable demos. Maybe even a stripped-back MVP.
Prototyping helps you test:
Usability
Performance
UX
Technical feasibility
It’s where you catch friction before you invest heavily in full dev cycles.
One of our portfolio teams used prototyping to test two onboarding flows. One took users through a wizard. The other dropped them into the product with contextual hints.
Wizard converted at 48%.
Hints? Only 12%.
The time investment? One week in Figma.
The result? Thousands of users activated faster.
The Smart Sequence: Pretotype → Prototype → Build
When I meet early-stage founders, here’s how I advise them to sequence:
Start with a pretotype
Validate if anyone actually wants what you’re proposing.
Then prototype
Make it usable. Sharpen UX. Test usability.
Only then, build
Commit time, talent, and capital to execution.
This mindset saves companies. It’s that simple.
How I Learned This the Hard Way
Let me share a personal story.
In one of my early businesses, we built an analytics platform for media companies. Spent months on it. Fancy dashboards. Granular filters. Real-time performance data.
But once we launched, adoption was slow.
So we called five of our most engaged users and asked:
“When do you check your stats?”
All five said the same thing:
“When I get an alert that something’s going wrong.”
We’d built a self-serve platform when what they really needed was an alerting system.
Had we pretotyped that use case—maybe just by sending fake alerts and tracking usage—we would’ve figured it out faster.
That one insight set us back four months.
How to Embed Pretotyping Into Your Culture
Here’s how to make pretotyping part of your product DNA:
1. Make It a Mandatory Step
No new feature gets resourced until it passes a simple demand test.
No roadmap item goes beyond “idea” unless it’s been pretotyped.
2. Assign a Pretotyping Champion
Every team needs someone who owns early-stage testing. Not just product managers. Marketing. Support. Founders.
3. Track Test Learnings
Log every assumption you’ve tested. Share results. Build a “what we’ve learned” library.
4. Celebrate Kills
Every time a pretotype disproves a bad idea—celebrate. That’s a win.
Final Word: Test Before You Burn
You will have limited time. Limited capital. Limited attention.
Your job as a founder is not to just build. It’s to learn, decide, and build the right thing.
Pretotyping is how you do that.
It’s fast.
It’s frugal.
And it’s honest.
So before you open Figma.
Before you spin up the dev sprint.
Before you pitch investors on a v1…
Ask:
“Have I tested whether people actually want this?”
If the answer is no—start smaller. Start smarter. Pretotype.
—Chris Tottman
Palm pretotype wasn't even an equivalent of a landing page with a "sign up" button or another call for action. Jeff Hawkins didn't even check the thing with potential customers. Yet he found a clever way to validate some key assumptions behind the idea.
After all, if he (the person hyped for the idea) wouldn't stick to it, no one else would.
Having said that, I think that the lines between a pretotype and a prototype (and a prototype and an MVP, too) should be blurry.
I like this frame:
- What's your total budget for an MVP?
- Now, what can you do for 10% of that?
This typically gets people to such low budgets that it completely rewires their thinking. 10x smaller doesn't leave a space for cutting a few features, but sticking with the approach ("let's build it"). It necessarily requires a different approach altogether.
Then we start talking about how to validate the assumptions behind the product idea *without* building anything, or by generating some expendable stuff with AI.
In my experience, at least 50% of such early experiments disprove the original business hypothesis. That is a huge win. We invalidated the idea for dirt cheap.
I have learnt about pre-validating ideas and putting together quick landing pages to test them. This is a great guide breaking down the concept—I really like the ring to the word "Pretotyping." Indeed, this is even more relevant in the build-an-app-overnight AI age.
Would you recommend going by industry standard CTR/lead conversion metrics for judging the success of a pretotyping test? I know you say "Make a Hypothesis," but optimistic founders would definitely go overboard with this! Any thoughts on realistic benchmarks?