Categories
Refer Now
Most products fail — not because teams can't build, but because they build the wrong thing. Pretotyping and prototyping are two powerful tools that can fix this. Here's how to tell them apart and use them wisely.
What Is Pretotyping?
Pretotyping is a method designed to answer one ruthless question before you write a single line of code: Will people actually use this? The term was coined by Alberto Savoia, a former Engineering Director at Google, and later popularized through his book The Right It.
Think of it as the cheapest possible experiment you can run to validate real-world demand. You're not building the product - you're simulating it. You fake just enough to see if real people respond to the idea in a real context.
The core philosophy is simple: most new products fail, not because they were built poorly, but because nobody wanted them in the first place. Pretotyping saves you from building the wrong thing with great precision.
"Make sure you are building the right it before you build it right."
What Is Prototyping?
Prototyping is the process of building an early, working model of your product to test how it functions. It's been a cornerstone of product design and engineering for decades - used by everyone from car manufacturers to software companies.
A prototype can range from a rough clickable wireframe to a near-functional version of the product. The goal here shifts from should we build this? to how should we build this? - you're exploring design, usability, and technical feasibility.
Prototyping happens after you've made the decision to move forward. It's about shaping the product experience, gathering usability feedback, and refining before full-scale development begins.
Key Differences at a Glance
Here's where most people get confused - both terms involve "testing," but they test entirely different things. The table below makes the distinction crystal clear.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When to Use Which?
The simplest way to decide: if you haven't confirmed that people want your idea, pretotype first. If you've validated demand and need to figure out the best way to deliver it, prototype.
-
Start with a Pretotype when…
You have a brand-new idea and you're not sure if there's genuine demand. You want real behavioral data — not just opinions or survey responses - before committing budget or engineering time.
- Move to Prototyping when…
Pretotyping gave you a green light. People responded. Now you need to figure out the UX, the flow, the interface - how the product actually works and feels in users' hands.
- Use Both Together (Ideal Workflow)
The smartest teams use pretotyping to validate, then prototyping to design, then development to build. It's a sequential filter that keeps resources focused on ideas that actually have a chance.
Real-World Examples
These techniques aren't just theory - some of the most iconic products in history were validated using these exact approaches. Let's look at a few.
1. Airbnb — Classic Pretotype
Before building anything, the founders rented out their own apartment to strangers to see if people would actually pay to sleep in someone else's home. No platform needed. Just a mattress, a camera, and a hunch.
2. Dropbox — Video Pretotype
Dropbox launched a simple demo video explaining the product before the product existed. 75,000 sign-ups overnight told them everything they needed to know about demand. The product came after.
3. Zappos — Fake Store Pretotype
The founder photographed shoes from local stores, listed them online, and only purchased them after customers ordered. He validated e-commerce demand for shoes without holding any inventory.
Now compare those to prototyping in action: Apple famously created hundreds of physical and digital prototypes of the iPhone before settling on the final design. That's prototyping - refining the how after the what was already decided.
Conclusion
Pretotyping and prototyping aren't competing methodologies - they're sequential partners in a smarter build process. Each has a distinct role, a distinct timing, and a distinct set of questions it's designed to answer.
Pretotyping comes first. It's fast, cheap, and brutally honest. It tells you whether you're solving a problem people actually have, before you invest in solving it.
Prototyping comes next. It's creative, iterative, and functional. It helps you figure out the best way to deliver the solution you've already validated.
