Pretotyping: Build the Right It Before You Build It Right (Complete Guide)

Bottom line: Pretotyping is a methodology for testing whether you should build a product at all before you build a prototype. Coined by Alberto Savoia at Google around 2009, the term combines "pretend" and "prototyping" — and it answers a fundamentally different question than prototyping does. A prototype asks "can we build it?" A pretotype asks "should we build it? Will anyone actually use it?" The methodology exists because most new product ideas fail — Savoia cites failure rates of 70-90% across product categories — and the failure usually has nothing to do with execution. The product was built well, but customers didn't want it. Pretotyping catches that mismatch before the team spends a dollar on engineering. In 2026, AI-moderated interviews radically accelerate the post-pretotype validation cycle, giving teams qualitative depth alongside the behavioral signal a pretotype produces.

What Is Pretotyping?

Pretotyping is the practice of simulating the core experience of a product with the smallest possible investment of time and money, in order to test whether the idea has real appeal and usage before committing to building it. The term was introduced by Alberto Savoia, a former Google engineering director who became the company's first "Innovation Agitator" in the late 2000s.

Savoia's formal definition: "Testing the initial appeal and actual usage of a potential new product by simulating its core experience with the smallest possible investment of time and money."

The defining insight behind pretotyping is what Savoia calls the Innovator's Nightmare: building something well that nobody wants. The Innovator's Nightmare is far more common than the Innovator's Dream (building something well that everyone wants). Savoia argues that most product failure is not "we executed badly" but "we executed well on the wrong thing."

As he writes in Pretotype It: "Most new ideas fail — even when competently executed. So we need a way to make sure that the new product idea that we have is The Right It before we invest time and money into building It right."

Pretotyping vs. Prototyping: A Critical Distinction

Pretotypes and prototypes are often confused because the words sound similar. They are not the same:

A prototype answers engineering questions. A pretotype answers product-management questions. You do pretotyping first, prototyping second. Teams that skip pretotyping and go straight to prototyping often build technically excellent products that nobody adopts.

The Famous Palm Pilot Story

The canonical pretotyping example is Jeff Hawkins's development of the Palm Pilot in the early 1990s. Hawkins wanted to know whether anyone would actually carry around a small personal digital assistant. Before building a single circuit, he carved a block of wood the size and shape of his envisioned device. He carried this wooden brick in his shirt pocket for weeks. When he "received" a call, he held the wood block up to his ear. When he wanted to write a note, he pulled the block out and tapped on it with a chopstick.

What Hawkins learned from this absurd-looking experiment shaped one of the most successful products of the 1990s:

• He actually did carry the device every day — confirming demand for portable form factor
• He used it primarily for four functions: address book, calendar, memo, and to-do lists — informing the feature set
• The size and shape worked in real pocket geometry — informing the physical design

Hawkins later said the wood-block pretotype was the single most important experiment in Palm Computing's history. It told him to build the Pilot — and what not to build into it.

The Palm Pilot launched in 1996 and became the first commercially successful PDA, paving the way for the smartphone form factor we use today.

The Core Pretotyping Techniques

Savoia identifies seven main pretotype techniques. Each tests a different kind of assumption:

1. The Mechanical Turk

Replace the complex machine with a human, pretending to be the machine. Tests whether the experience is valued before building the technology.

Example: Before building a sophisticated AI translation app, run it with human translators in the background. Users send a request, a human translator handles it, the app returns the translation. The experience is identical to a working AI; the build is zero.

2. The Pinocchio

Build a non-functional version of the product that looks real but does nothing. Carry it, use it, see if you actually integrate it into your life.

Example: The Palm Pilot wood block. Or a "smart" plant pot made of cardboard that you place on your desk for two weeks.

3. The Fake Door (also "Door-to-Nowhere")

Create an entry point — a button, a menu item, a landing page — for a product or feature that doesn't exist yet. Measure how many people click it. The click rate is your demand signal.

Example: Add a "Schedule Meeting with AI" button to your SaaS dashboard. When clicked, show "Coming soon — leave your email to be notified." Email signups quantify demand.

4. The Pretend-to-Own

Before investing in expensive equipment for a business, rent or borrow it for a short period and try the business model. If the business doesn't work with rented equipment, it won't work with owned equipment.

Example: Before buying a $50K espresso machine for a cafe, rent one for two weekends and run a pop-up. See if customers come.

5. The Minimum Viable Product (MVP) as Pretotype

A single-feature, hand-assembled MVP that you can throw away. Differs from the engineering MVP: the goal is learning, not scaling.

Example: Buffer launched as a two-page landing site that explained the product and showed pricing. The "Sign up" button led to an email capture, not a product. The conversion rate was the validation.

6. The Provincial

Launch in one tiny market or one tiny segment. If it works there, scale. If it doesn't, kill it cheap.

Example: Airbnb's early "two-borough launch" before global rollout. Or testing a new SaaS feature with a single B2B customer before announcing it.

7. The YouTube Pretotype

Make a video that demonstrates the product working, without actually building it. Share the video and measure the response (signups, comments, shares). Dropbox used this technique in 2007 — the explainer video drove 75,000 beta signups before a working sync engine existed.

When to Use Pretotyping

Pretotyping is most valuable when:

• The cost of being wrong is high — significant engineering investment, brand risk, or capital commitment
• The product is genuinely new — there is no existing comparable to learn from
• You are uncertain whether anyone wants it — internal opinions are split, no external evidence yet
• You have a hypothesis to test — pretotyping is the cheapest class of hypothesis-driven development experiment

Pretotyping is less valuable when:

• The market is well-known and you're iterating an existing product
• The problem is feasibility, not desirability — go to prototyping instead
• You already have strong qualitative evidence from research that the demand exists

Pretotyping vs. MVP

The Lean Startup MVP is a related but distinct concept. An MVP is the smallest functional product that delivers value — it is real, it works, and customers pay for it. A pretotype is the smallest simulation of a product, used to test demand before any real product exists.

In practice, the boundary blurs. Buffer's landing page was both a pretotype (testing demand) and arguably the company's first MVP (when Joel Gascoigne started manually queuing tweets for paying customers). The distinction matters less than the discipline: simulate cheaply before building expensively.

The Modern Pretotyping Workflow

A 2026 pretotyping cycle for a typical SaaS team looks like this:

1. Identify the riskiest assumption in a product idea. (Usually: "customers want this enough to pay/switch.")
2. Choose the pretotype technique that tests it cheapest. (For a SaaS feature: a fake-door button + landing page; for a hardware idea: a Pinocchio.)
3. Build the pretotype in days, not weeks. Real engineering investment should be near zero.
4. Expose it to a real audience. Existing users, ads, communities — whoever the target is.
5. Measure behavioral signal. Clicks, signups, payments, returns to the page. Behavior beats stated intent.
6. Run follow-up qualitative interviews. This is where AI-moderated platforms transform the workflow. Within 48 hours of running the fake-door test, the team can have 20-50 customer conversations explaining why people did or didn't click, and what they expected to find.
7. Decide: pursue, pivot, or kill.

Step 6 is where pretotyping has historically broken down. A fake-door test produces a number — say, a 4% click rate — but the team can't tell whether that means "great demand" or "people clicked out of curiosity." The qualitative depth that makes the number actionable used to require expensive moderated research.

How Koji Powers Modern Pretotyping

The critical complement to a pretotype is qualitative depth on the behavioral signal it produces. A fake-door test that gets 4% clicks tells you something, but it doesn't tell you what people expected, why they hesitated, or what they'd pay. That second layer is where AI-moderated interviews change the economics.

Koji is built to extend pretotyping cycles with rapid qualitative depth:

• AI-moderated interviews can run on the same fake-door landing page. After a click, route a portion of users to a 5-minute conversational interview that probes what they expected, why they're interested, and what would make them pay.
• Structured questions mix open-ended depth (open_ended) with the quantitative measurement teams need (scale, single_choice, multiple_choice, ranking, yes_no) — all in the same interview.
• Voice or text lets participants choose, increasing response rates on what would otherwise be cold post-click surveys.
• Automatic thematic analysis turns 30+ post-click interviews into a ranked theme summary — "expected to see X, didn't find Y" — within hours instead of weeks.
• 24/7 always-on collection means the qualitative signal accumulates alongside the behavioral signal, in real time, while the pretotype is still running.

A pretotype-first team that pairs Savoia's techniques with Koji's AI-moderated research can validate or kill a product hypothesis in 5-10 days for under $500 — compared to traditional research vendor cycles that cost $15-50K and take 4-8 weeks. This is what makes pretotyping viable as a continuous habit rather than a one-time exercise.

Famous Pretotyping Case Studies

IBM Speech-to-Text

In the 1980s, IBM was considering investing heavily in speech-to-text software. Before building anything, they ran a Mechanical Turk pretotype: users spoke into a microphone, and a hidden human typist in another room transcribed in real time. Participants believed they were using a working speech-to-text system. The result: users found it physically tiring, awkward for confidential information, and slower than typing for most use cases. IBM avoided a massive failed investment.

Zappos

Nick Swinmurn's pretotype for Zappos was a website with photos of shoes from local stores. When someone bought a pair, Swinmurn would go to the store, buy the shoes, and ship them. No inventory. No supply chain. The pretotype validated the assumption that people would buy shoes online without trying them on first — at the time, an unproven hypothesis.

Dropbox

Drew Houston's 2007 explainer video showed Dropbox working flawlessly across devices. The video was a YouTube Pretotype — the sync engine behind it was not fully functional. The video drove 75,000 beta signups overnight, validating demand before the team finished building the product.

Pretotyping Anti-Patterns

Anti-pattern 1: Pretotyping after you've already decided

If the team has already committed to building the feature, the pretotype becomes theater — designed to confirm rather than test. Pretotype before the build decision is made.

Anti-pattern 2: Treating clicks as truth

A fake-door click rate is signal, not proof. Pair it with qualitative follow-up to understand what the click meant.

Anti-pattern 3: Pretotyping too long

The whole point is speed. If your pretotype takes a month to build, it's a prototype. Pretotypes are measured in hours and days.

Anti-pattern 4: No falsification criteria

Like all hypothesis-driven experiments, pretotypes need a pre-committed threshold. "If fewer than 3% of users click the fake door, we kill this idea."

Bottom Line

Pretotyping is the cheapest form of product validation that exists. It rejects the assumption that you need to build something real to learn whether anyone wants it — and instead tests the only thing that ultimately matters: does the target customer actually use the thing, with their real time and real money, when they think it's real?

The technique is over a decade old, but the operational economics have transformed in the last few years. Pairing classical Savoia pretotype techniques with modern AI-moderated qualitative research collapses the full validate-or-kill cycle from months to days. There is no longer a defensible reason to build a major product feature without pretotyping it first.

Related Resources

• Hypothesis-Driven Product Development
• Assumption Testing Guide
• Smoke Test Product Validation
• Wizard of Oz Testing Guide
• Startup Idea Validation Guide
• Structured Questions Guide: 6 Question Types for AI Interviews
• Product Trio Framework