Pretotyping: kill bad product ideas in days, not after months of building

You’ve probably seen this play out before: a team spends months building a product, only to discover that nobody actually wants it. The features work perfectly. The code is clean. But users shrug and move on. This is what Alberto Savoia, former Google engineering director, calls the “Law of Market Failure” — most new products fail, even when they’re well-executed. Pretotyping is his answer to this problem: a set of techniques for testing whether you’re building the right thing before you invest in building it right.

The core insight behind pretotyping is simple but uncomfortable: execution risk isn’t your biggest threat. Market risk is. You can build something flawlessly and still fail because you solved a problem nobody cared enough to pay for.

What pretotyping actually means

Savoia coined the term “pretotype” as a deliberate play on “prototype.” While a prototype answers “Can we build it?”, a pretotype answers “Should we build it?” It’s the difference between technical validation and market validation.

The pretotyping philosophy centers on what Savoia calls testing “The Right It” — determining whether your idea has genuine market demand before you commit real resources. His research found that most failed products weren’t poorly built; they were solutions to problems that weren’t painful enough, or products that people said they wanted but wouldn’t actually use.

A pretotype is designed to collect real behavioral data with minimal investment. We’re talking hours or days of work, not weeks or months. The goal is to create something that simulates the core experience of your product just enough to measure whether people will actually engage with it — ideally with real transactions, real sign-ups, or real usage data.

Pretotyping vs. prototyping vs. MVPs

These three concepts overlap but serve different purposes. Understanding the distinctions helps you pick the right tool for your current stage.

Prototypes test feasibility

A prototype demonstrates that something can be built. It might be a clickable Figma mockup, a proof-of-concept algorithm, or a hardware model. Prototypes are excellent for exploring technical constraints and getting stakeholder alignment on direction. But they don’t tell you whether anyone will pay for the finished product. Users evaluating a prototype know they’re looking at something unfinished, which changes how they respond.

MVPs test viability

A minimum viable product [INTERNAL_LINK: minimum viable product] is a functional product with just enough features to deliver core value and learn from real customers. The MVP approach, popularized by Eric Ries in The Lean Startup, assumes you’ve already validated that the idea is worth pursuing. You’re now learning how to build it well. MVPs typically require weeks to months of development work.

Pretotypes test desirability

A pretotype comes before both. It’s not functional in the traditional sense — it might be entirely fake. The point is to simulate the experience of having the product in market and measure real behavior. Did people click? Did they sign up? Did they enter their credit card? Pretotypes typically take hours to days, not weeks.

Think of it as a progression: pretotype to validate the idea is worth pursuing, then prototype to validate you can build it, then MVP to validate you can build it in a way customers love.

The main pretotype types

Savoia outlines several pretotyping techniques in his book “The Right It.” Each works best for different situations.

The Fake Door (or Fake Front Door)

Create a realistic entry point for a product that doesn’t exist yet, then measure how many people try to use it. This might be a landing page with a sign-up button, a feature button in an existing app, or an ad campaign driving to a “coming soon” page.

Example: Buffer famously validated their social media scheduling tool by creating a landing page describing the product and a pricing page. When visitors clicked “Plans and Pricing,” they saw three tiers. Only after clicking a plan did they see “You caught us before we’re ready” and an email sign-up. The conversion rate at each step told Buffer exactly how much interest existed.

Best for: Testing demand for new products or features before any development work.

The Mechanical Turk

Replace complex technology with humans doing the work manually behind the scenes. Users experience what feels like an automated product, but a person is actually fulfilling requests. Named after the famous 18th-century chess “automaton” that was actually controlled by a human hidden inside.

Example: Zappos founder Nick Swinmurn validated online shoe sales by photographing shoes at local stores. When someone ordered, he’d buy the shoes at retail and ship them. No inventory, no warehouse operations — just a guy testing whether people would buy shoes online. Only after proving demand did Zappos build actual e-commerce infrastructure.

Best for: Testing products that would require complex automation or AI. You learn whether the value proposition works before investing in the technology.

The Pinocchio

Create a non-functional version of your product that looks real enough to gauge interest. Like Pinocchio, it looks like the real thing but isn’t alive yet.

Example: Palm Pilot creator Jeff Hawkins famously carried a wooden block in his pocket for months, pretending it was a handheld computer. He’d pull it out in meetings to “check his calendar” or “take notes.” This helped him understand whether the form factor worked and what features he actually reached for.

Best for: Physical products or testing form factors and usage patterns before manufacturing.

The One-Night Stand

Set up a temporary, low-investment version of your product in a real environment for a limited time. Like a pop-up restaurant testing a concept.

Example: Before launching their grocery delivery service, Instacart’s founders literally went to a Whole Foods, took pictures of products, put them on a simple website, and delivered groceries themselves. One day of testing told them more than months of market research.

Best for: Service businesses or any product where you can manually deliver the experience temporarily.

The Infiltrator

Place your pretotype product inside an existing ecosystem to test interest. This might mean putting your product in someone else’s store or platform.

Example: The founders of Rent the Runway initially tested designer dress rentals by posting on college bulletin boards and offering to rent out their own designer dresses. They infiltrated the existing “campus marketplace” to test whether women would pay to rent high-end fashion.

Best for: Products that need to exist within a marketplace or retail environment.

The Relabeled

Put your branding on an existing product to test whether people want what you’re offering. You’re testing the concept and positioning, not the specific implementation.

Example: If you wanted to test demand for a new energy drink, you could buy existing drinks, relabel them with your branding, and sell them at local events. Customer response tells you whether your positioning resonates, independent of the actual formula.

Best for: CPG products or testing brand and positioning concepts.

How to design a pretotype experiment

Picking a technique is just the start. The quality of your experiment determines whether you get useful data.

1. Define your hypothesis clearly

A good pretotype hypothesis follows this format: “We believe [specific customer segment] will [take specific action] because [reason].” Vague hypotheses like “people will like this” can’t be validated or invalidated. You need something measurable.

Strong example: “We believe that first-time managers will pay $29/month for a tool that provides weekly 1-on-1 conversation prompts because they’re anxious about holding effective conversations with direct reports.”

2. Set success criteria in advance

Before you run your experiment, define what success looks like. What conversion rate would convince you to move forward? What number would convince you to kill the idea? This prevents post-hoc rationalization where any result becomes “good enough.”

Savoia recommends committing to your criteria in writing and sharing them with others before seeing results. If 3% of visitors sign up, is that validation? That depends on your market and business model — decide upfront.

3. Collect behavioral data, not just opinions

The whole point of pretotyping is measuring what people do, not what they say. Surveys and interviews are valuable for understanding context, but they’re famously unreliable for predicting behavior. People will tell you they’d definitely use a product, then never open it. Design your pretotype to capture real actions.

The hierarchy of signal strength, from weakest to strongest:

• They said they’d use it (weak signal)
• They gave you their email (moderate signal)
• They gave you their credit card or made a purchase (strong signal)
• They came back and used it again (strongest signal)

4. Find your XYZ hypothesis

Savoia emphasizes being specific about numbers using what he calls the XYZ hypothesis: “At least X% of Y will do Z.” For example: “At least 10% of product managers who see our landing page will sign up for the waitlist.” This forces precision and makes success or failure clear.

5. Run the experiment with real skin in the game

The more realistic the context, the more valid your data. If possible, have participants make real commitments — even small ones. Asking for a credit card (even if you don’t charge it) creates a completely different signal than just asking for an email. Airbnb’s founders didn’t just ask people if they’d rent spare rooms; they actually listed their apartment and had strangers pay to stay there.

Common pretotyping mistakes to avoid

Even teams who understand the concept often trip up in execution.

Testing with friends and family: Your network will give you biased feedback. They want to support you. Find strangers who have no relationship with you and no reason to be polite.

Overselling or deceiving: There’s a difference between creating a realistic simulation and actually defrauding customers. Fake door tests should reveal the truth quickly. If someone enters their credit card, don’t charge them for something you can’t deliver. The goal is learning, not extracting money under false pretenses.

Ignoring negative results: This is the big one. The whole point of pretotyping is to fail cheaply when your idea is wrong. If your experiment shows weak demand, that’s valuable information. Don’t run three more experiments hoping for a different answer.

Testing too many variables: A pretotype should test one core hypothesis. If you’re testing the concept, the pricing, and the messaging all at once, you won’t know which variable drove the results.

Making pretotyping part of your process

The teams that get the most value from pretotyping make it a default step, not an occasional technique. Before any significant product investment, ask: “What’s the fastest way we could test whether this idea is worth building?”

Sometimes the answer is a two-hour fake door test. Sometimes it’s a weekend Mechanical Turk experiment. Sometimes you already have enough evidence from existing user behavior. But making the question automatic prevents the expensive mistake of building first and validating later.

Alberto Savoia’s core argument is worth remembering: most new products fail, and most of those failures were predictable. Pretotyping is how you surface those failures before they become expensive — and how you find the ideas that are actually worth your team’s time to build well.

Frequently asked questions