{"site":{"name":"Koji","description":"AI-native customer research platform that helps teams conduct, analyze, and synthesize customer interviews at scale.","url":"https://www.koji.so","contentTypes":["blog","documentation"],"lastUpdated":"2026-05-18T13:32:44.142Z"},"content":[{"type":"documentation","id":"f13a7ca5-fa2f-44ff-8ead-bb7989c9817b","slug":"pretotyping","title":"Pretotyping: Build the Right It Before You Build It Right (Complete Guide)","url":"https://www.koji.so/docs/pretotyping","summary":"Pretotyping is a pre-MVP validation methodology coined by Alberto Savoia (formerly Google) around 2009. A pretotype simulates the core experience of a product with the smallest possible investment of time and money to test whether anyone will actually use it. Unlike a prototype (which asks 'can we build it?'), a pretotype asks 'should we build it?' The seven core techniques are: Mechanical Turk (replace machine with human), Pinocchio (non-functional lookalike like the Palm Pilot wood block), Fake Door (button or page for a product that doesn't exist), Pretend-to-Own (rent before buy), MVP-as-Pretotype, Provincial (one tiny market), and YouTube Pretotype (demo video, like Dropbox's 75,000-signup launch). Most new products fail at 70-90% rates and Savoia argues the failure usually isn't execution but 'building It well when It's the Wrong It.' Modern pretotyping cycles pair classical techniques with AI-moderated interviews (Koji) for rapid qualitative depth on behavioral signal — validate or kill in 5-10 days for under $500 vs. $15-50K and 4-8 weeks with traditional research vendors.","content":"# Pretotyping: Build the Right It Before You Build It Right (Complete Guide)\n\n**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.\n\n## What Is Pretotyping?\n\nPretotyping 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.\n\nSavoia'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.\"*\n\nThe 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.\"\n\nAs 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.\"*\n\n## Pretotyping vs. Prototyping: A Critical Distinction\n\nPretotypes and prototypes are often confused because the words sound similar. They are not the same:\n\n| Dimension | Prototype | Pretotype |\n|---|---|---|\n| **Core question** | Can we build it? | Should we build it? |\n| **Risk addressed** | Technical feasibility | Market desirability |\n| **Stage** | Solution validation | Problem and demand validation |\n| **Investment** | Days to weeks of build | Hours to days of fake |\n| **Looks real?** | Yes — functions partially | No — simulates without working |\n| **Output** | Working approximation | Behavioral signal |\n\nA 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.\n\n## The Famous Palm Pilot Story\n\nThe 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.\n\nWhat Hawkins learned from this absurd-looking experiment shaped one of the most successful products of the 1990s:\n\n- He actually *did* carry the device every day — confirming demand for portable form factor\n- He used it primarily for four functions: address book, calendar, memo, and to-do lists — informing the feature set\n- The size and shape worked in real pocket geometry — informing the physical design\n\nHawkins 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.\n\nThe Palm Pilot launched in 1996 and became the first commercially successful PDA, paving the way for the smartphone form factor we use today.\n\n## The Core Pretotyping Techniques\n\nSavoia identifies seven main pretotype techniques. Each tests a different kind of assumption:\n\n### 1. The Mechanical Turk\n\nReplace the complex machine with a human, pretending to be the machine. Tests whether the *experience* is valued before building the technology.\n\n**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.\n\n### 2. The Pinocchio\n\nBuild 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.\n\n**Example**: The Palm Pilot wood block. Or a \"smart\" plant pot made of cardboard that you place on your desk for two weeks.\n\n### 3. The Fake Door (also \"Door-to-Nowhere\")\n\nCreate 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.\n\n**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.\n\n### 4. The Pretend-to-Own\n\nBefore 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.\n\n**Example**: Before buying a $50K espresso machine for a cafe, rent one for two weekends and run a pop-up. See if customers come.\n\n### 5. The Minimum Viable Product (MVP) as Pretotype\n\nA single-feature, hand-assembled MVP that you can throw away. Differs from the engineering MVP: the goal is **learning**, not scaling.\n\n**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.\n\n### 6. The Provincial\n\nLaunch in one tiny market or one tiny segment. If it works there, scale. If it doesn't, kill it cheap.\n\n**Example**: Airbnb's early \"two-borough launch\" before global rollout. Or testing a new SaaS feature with a single B2B customer before announcing it.\n\n### 7. The YouTube Pretotype\n\nMake 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.\n\n## When to Use Pretotyping\n\nPretotyping is most valuable when:\n\n- **The cost of being wrong is high** — significant engineering investment, brand risk, or capital commitment\n- **The product is genuinely new** — there is no existing comparable to learn from\n- **You are uncertain whether anyone wants it** — internal opinions are split, no external evidence yet\n- **You have a hypothesis to test** — pretotyping is the cheapest class of [hypothesis-driven development](/docs/hypothesis-driven-product-development) experiment\n\nPretotyping is less valuable when:\n\n- The market is well-known and you're iterating an existing product\n- The problem is feasibility, not desirability — go to prototyping instead\n- You already have strong qualitative evidence from research that the demand exists\n\n## Pretotyping vs. MVP\n\nThe 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.\n\nIn 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**.\n\n## The Modern Pretotyping Workflow\n\nA 2026 pretotyping cycle for a typical SaaS team looks like this:\n\n1. **Identify the riskiest assumption** in a product idea. (Usually: \"customers want this enough to pay/switch.\")\n2. **Choose the pretotype technique** that tests it cheapest. (For a SaaS feature: a fake-door button + landing page; for a hardware idea: a Pinocchio.)\n3. **Build the pretotype in days, not weeks.** Real engineering investment should be near zero.\n4. **Expose it to a real audience.** Existing users, ads, communities — whoever the target is.\n5. **Measure behavioral signal.** Clicks, signups, payments, returns to the page. Behavior beats stated intent.\n6. **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.\n7. **Decide: pursue, pivot, or kill.**\n\nStep 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.\n\n## How Koji Powers Modern Pretotyping\n\nThe 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.\n\nKoji is built to extend pretotyping cycles with rapid qualitative depth:\n\n- **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.\n- **[Structured questions](/docs/structured-questions-guide)** 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.\n- **Voice or text** lets participants choose, increasing response rates on what would otherwise be cold post-click surveys.\n- **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.\n- **24/7 always-on collection** means the qualitative signal accumulates alongside the behavioral signal, in real time, while the pretotype is still running.\n\nA 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.\n\n## Famous Pretotyping Case Studies\n\n### IBM Speech-to-Text\n\nIn 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.\n\n### Zappos\n\nNick 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.\n\n### Dropbox\n\nDrew 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.\n\n## Pretotyping Anti-Patterns\n\n### Anti-pattern 1: Pretotyping after you've already decided\n\nIf 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.\n\n### Anti-pattern 2: Treating clicks as truth\n\nA fake-door click rate is signal, not proof. Pair it with qualitative follow-up to understand *what* the click meant.\n\n### Anti-pattern 3: Pretotyping too long\n\nThe whole point is speed. If your pretotype takes a month to build, it's a prototype. Pretotypes are measured in hours and days.\n\n### Anti-pattern 4: No falsification criteria\n\nLike all [hypothesis-driven](/docs/hypothesis-driven-product-development) experiments, pretotypes need a pre-committed threshold. \"If fewer than 3% of users click the fake door, we kill this idea.\"\n\n## Bottom Line\n\nPretotyping 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?\n\nThe 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.\n\n## Related Resources\n\n- [Hypothesis-Driven Product Development](/docs/hypothesis-driven-product-development)\n- [Assumption Testing Guide](/docs/assumption-testing-guide)\n- [Smoke Test Product Validation](/docs/smoke-test-product-validation)\n- [Wizard of Oz Testing Guide](/docs/wizard-of-oz-testing-guide)\n- [Startup Idea Validation Guide](/docs/startup-idea-validation-guide)\n- [Structured Questions Guide: 6 Question Types for AI Interviews](/docs/structured-questions-guide)\n- [Product Trio Framework](/docs/product-trio-framework)","category":"Research Methods","lastModified":"2026-05-18T03:22:31.740073+00:00","metaTitle":"Pretotyping: Build the Right It Before You Build It Right (2026 Guide)","metaDescription":"The complete guide to pretotyping — Alberto Savoia's pre-MVP validation methodology. Learn the 7 pretotype techniques (Mechanical Turk, Pinocchio, Fake Door, Pretend-to-Own, MVP, Provincial, YouTube), see Palm Pilot and Dropbox case studies, and use AI-moderated interviews to validate signal in days.","keywords":["pretotyping","pretotype","alberto savoia","pretotype it","product validation","fake door test","pinocchio pretotype","mechanical turk pretotype","palm pilot pretotype","build the right it"],"aiSummary":"Pretotyping is a pre-MVP validation methodology coined by Alberto Savoia (formerly Google) around 2009. A pretotype simulates the core experience of a product with the smallest possible investment of time and money to test whether anyone will actually use it. Unlike a prototype (which asks 'can we build it?'), a pretotype asks 'should we build it?' The seven core techniques are: Mechanical Turk (replace machine with human), Pinocchio (non-functional lookalike like the Palm Pilot wood block), Fake Door (button or page for a product that doesn't exist), Pretend-to-Own (rent before buy), MVP-as-Pretotype, Provincial (one tiny market), and YouTube Pretotype (demo video, like Dropbox's 75,000-signup launch). Most new products fail at 70-90% rates and Savoia argues the failure usually isn't execution but 'building It well when It's the Wrong It.' Modern pretotyping cycles pair classical techniques with AI-moderated interviews (Koji) for rapid qualitative depth on behavioral signal — validate or kill in 5-10 days for under $500 vs. $15-50K and 4-8 weeks with traditional research vendors.","aiPrerequisites":["Basic understanding of product validation","Familiarity with lean startup concepts"],"aiLearningOutcomes":["Define pretotyping and explain how it differs from prototyping and MVP","Apply the seven core pretotype techniques to real product ideas","Choose the right pretotype technique for a given assumption","Pair behavioral signal from pretotypes with qualitative depth from AI-moderated interviews","Avoid the four most common pretotyping anti-patterns","Run a complete pretotype validation cycle in under two weeks"],"aiDifficulty":"intermediate","aiEstimatedTime":"15 minutes"}],"pagination":{"total":1,"returned":1,"offset":0}}