Pretotyping

---

Origins

Alberto Savoia coined the term pretotyping while at Google in 2009¹. Savoia's framing came from watching Google's repeated pattern of building polished, technically excellent products that customers didn't want. The problem wasn't engineering quality — it was that the team had built the wrong thing very well. He summarized the insight as the "Law of Market Failure": most new products fail in the market — even when competently executed.

His response was to draw a sharp line between two activities most teams conflate:

• Prototyping asks "can we build it, and how?" It tests technical feasibility.
• Pretotyping asks "should we build it at all?" It tests whether anyone will actually use the thing once it exists.

Savoia later expanded the work into a book, The Right It², which formalizes pretotyping techniques and offers a vocabulary for the data you collect when you run them.

The Premise

Pretotyping rests on a few uncomfortable observations.

The first is that opinions are not data. Customers asked whether they would use a product overwhelmingly say yes; the same customers, when actually presented with the product, mostly don't. Surveys, focus groups, and stakeholder interviews produce what Savoia calls thoughtland data — thoughtful, persuasive, and usually wrong.

The second is that real behavioral evidence is cheap to collect if you're willing to fake the product first. The cost of building a credible facade and watching what people do is a tiny fraction of building the real thing.

The third is that confidence in an idea is the worst possible reason to skip validation. The strongest convictions need the lightest tests, because they are the most expensive to be wrong about.

The Pretotyping Techniques

Savoia describes a small catalog of techniques, each suited to a different kind of question.

The Fake Door (Pinocchio)

A product page or feature link that suggests the thing exists. Measure clicks, sign-ups, or expressions of interest. Closely related to fake door testing.

The Mechanical Turk

The product appears automated but a human is doing the work behind the curtain. Customers experience the value; the team learns whether they actually want it; the engineering investment can wait. Examples: an "AI" recommendation that's really a person looking up matches; a "smart" form filler that's really an assistant.

The YouTube

A video of the product (real or staged) circulated to potential users. The video acts as the product for testing purposes. Dropbox famously used this approach with their initial demo — sign-ups jumped from 5,000 to 75,000 overnight from a single video.

The One-Night-Stand

A scrappy single-use version of the product, built quickly, used for one event or campaign, discarded after. Useful when the question is "would people pay for / engage with / share this once?" before investing in the durable version.

The Infiltrator

Embedding the product candidate inside an existing channel (a feature inside an existing app, a section of an existing page) to measure how it performs without committing to a standalone presence.

The Provincial

A locally-bounded version — one neighborhood, one customer segment, one geography. Tests viability in a small slice before scaling.

The TRI Metric

Pretotyping experiments produce data, but data needs interpretation. Savoia introduces the Truth Inversion Ratio (TRI) — or sometimes the Total Investment Ratio — as a way to evaluate how much real-world commitment a pretotype actually elicited.

Examples of behavioral signals, in increasing order of strength:

1. Saying you would use it (weakest).
2. Clicking a fake door.
3. Leaving an email address.
4. Reserving a slot.
5. Paying a deposit.
6. Buying outright (strongest).

The shift from "would you use it?" to "would you pay $20 right now?" filters out an enormous amount of polite interest. Pretotyping aims as far up that ladder as the situation allows.

Famous Examples

Palm Pilot

Jeff Hawkins carried a wooden block in his pocket, taking notes on it as if it were a real device. He used the imaginary product daily for weeks before specifying or building the real Palm Pilot. The pretotype let him discover — in his own behavior, not in his imagination — what features mattered.

IBM Speech-to-Text

In the 1980s, IBM tested demand for a speech-to-text product by sitting users at a keyboard-less terminal and having them dictate. A typist in another room transcribed in real time. Users believed the product worked; their reactions revealed that speech-to-text was less attractive than IBM had assumed once users realized how much it required them to enunciate.

Dropbox

The famous three-minute demo video shown to early-adopter communities showed Dropbox doing exactly what it promised — though the version filmed barely worked. Sign-up rate jumped, validating demand before the product was built.

Where Pretotyping Fits

Pretotyping is most useful at the riskiest moment of a product effort — the moment when the team has an idea, a strong opinion, and is about to commit serious resources. It precedes prototyping, which precedes building. Used together with a discovery practice like dual-track Agile, pretotyping is the cheapest of the experiments the team runs.

It is less useful for:

• Decisions already made or already in market.
• Features whose value depends on long-term retention rather than initial demand.
• Network-effect products where small samples can't reproduce the dynamics.

Common Pitfalls

• Confirmation bias: running the pretotype to confirm what the team already believes, then declaring victory on the first positive signal. Pre-declare what would change the team's mind.
• Treating opinion as data: asking "would you use this?" instead of measuring whether they actually do.
• Misreading early signal: a small spike of interest is not the same as durable demand. Pretotyping reveals interest, not retention.
• Skipping the metric ladder: testing only with weak signals (clicks, sign-ups) when the question really requires stronger commitment (purchase, payment).
• Pretotype becomes the product: the team falls in love with the scrappy version and ships it. Pretotypes are throwaway by design.

Coaching Tips

Pretotype the Riskiest Idea

The temptation is to validate ideas the team already feels good about. The leverage is on the ones the team is most committed to — the ones where being wrong is most expensive.

Skip "Would You?" Questions

Surveys that ask whether people would use a thing produce overwhelmingly positive answers and overwhelmingly poor predictions. Design the test for behavior, not intention.

Climb the Metric Ladder

Push the test up the ladder as far as the situation allows — from "click" to "email" to "deposit." Each step filters out more polite interest.

Declare the Kill Threshold

Before launching, write "if signal is below X, we will not build this." Without it, every result will be rationalized as somehow promising.

Keep It Throwaway

If you find yourself polishing the pretotype, you've slipped into building. The artifact is a tool; the data is the product.

Celebrate Failed Pretotypes

A pretotype that proves an idea wrong saved the team months. Make space for that win publicly — otherwise people only run experiments they expect to validate.

Summary

Pretotyping exists because the most expensive way to learn that a product idea was wrong is to ship it. Savoia's catalog of techniques gives teams cheap, fast ways to collect behavioral evidence about an idea before committing to engineering it — not perfect evidence, but evidence orders of magnitude more reliable than opinions.

The discipline beneath the techniques is the harder change to make. Teams that pretotype well are willing to discover that their cherished idea was wrong, willing to throw away the scrappy version they just built, and willing to invest the experimentation budget where the conviction is strongest. Those willingness conditions are rarer than the techniques themselves, and they are what separates teams that pretotype effectively from teams that pretotype theatrically.

Back to Discovery & Validation