Pretotype It: Make Sure You Are Building The Right It Before You Build It Right

Why this book exists

Alberto Savoia spent twenty years building products at companies like Sun Microsystems and Google. He watched, repeatedly, as teams of brilliant engineers built products of high technical quality that no one used. He coined the phrase "thoughtland" to describe the dangerous zone where teams convince themselves a product is needed because the idea is interesting and the technology is feasible, without any external evidence that real users actually want it. He estimated that 70-90% of new products fail, and that most of those failures were not failures of execution but failures of demand validation. The product worked; nobody wanted it.

The diagnosis that consumed Savoia's later career was that teams confused two questions. The first question, "can we build it right" (technical feasibility), is the one engineers love and PMs default to. The second question, "are we building the right it" (demand validation), is the one teams systematically underinvest in. Both questions matter; only one was getting attention. The book is the operationalization of the second question into a vocabulary and a toolkit.

Savoia introduced pretotyping at Google internally before publishing the book externally. The Google internal version, called Pretotyping@Work, was taught to thousands of Google engineers and PMs and was the basis for several successful product launches and several deliberately cancelled projects. The external book, first released as a free PDF in 2011, spread rapidly through the Lean Startup community and became a touchstone for any team that wanted to validate demand before significant build.

The core distinction: prototype vs pretotype

The book's central contribution is the vocabulary distinction. A prototype is a working version of the product, however rough, designed to test technical feasibility and refine the design. A pretotype is something even cheaper and faster than a prototype, designed to test whether anyone wants the product at all.

The distinction matters because the resource cost is dramatically different. A typical mobile app prototype might cost two weeks of designer-engineer time. A typical pretotype might cost two days of PM time — or two hours, in some cases. When teams build prototypes to test demand, they spend ten times the resources they need to, and they generate worse data because the prototype's polish creates demand signal that does not correspond to real demand.

A pretotype is intentionally lo-fi. It might be a slide deck shown to users with a paper clip glued on. It might be a landing page that advertises a product that does not exist. It might be a human in a back room manually fulfilling what the product would automate. The point is that the pretotype is built fast, cheap, and just well enough to generate demand data that the team can act on. Polish wastes resources and obscures signal.

The Mechanical Turk pretotype

Named after the 18th-century chess-playing automaton that turned out to have a human chess master hidden inside, the Mechanical Turk pretotype hides a human inside what looks like an automated product. The user interacts with the product as if it were real; the team manually fulfills the request behind the scenes.

Savoia's canonical example: in the early days of IBM's voice-to-text research, a Mechanical Turk pretotype put users in front of a keyboard-less terminal and told them to speak their requests. Behind a curtain, a typist transcribed the speech in real time. The product appeared to be working voice-to-text. The real question being tested was not "can we build voice-to-text" (a multi-year R&D investment) but "do users actually prefer voice input to typing for office work?" The pretotype answered that question in days. The answer was no — users found voice input awkward in shared office spaces, and the supposed productivity gains evaporated when users had to dictate carefully enough for accurate transcription. IBM redirected resources accordingly.

The Mechanical Turk pattern recurs across the book. Zappos famously started with founder Nick Swinmurn taking photos of shoes at local stores, posting them online, and when an order came in, going to the store, buying the shoes, and shipping them. The "automated shoe retailer" was a human running back and forth. The pretotype tested whether anyone would buy shoes online before Swinmurn built the inventory and logistics. The answer was yes; Zappos became a billion-dollar business.

For PMs, the Mechanical Turk pretotype is invaluable for testing any product that promises automation. Before building the AI feature, the workflow automation, the smart recommendation engine — manually fulfill the request and see if users use it.

The Pinocchio pretotype

A Pinocchio is a non-functional mockup the user can interact with, even though nothing actually works under the hood. The classic Savoia example: he wanted to know if he would actually use a PalmPilot before he bought one. He carved a piece of wood to the dimensions of a PalmPilot, glued a printed image of the screen on top, and carried it in his pocket for a week. He pulled it out whenever he thought he would use a real PalmPilot, mimed the interaction, and tracked the frequency.

The result: he discovered that he reached for the wooden Pinocchio far less often than he expected, and that the use cases he imagined did not materialize in his actual daily life. He decided not to buy the PalmPilot. The pretotype cost him an hour of carving and saved him several hundred dollars and weeks of unused-device frustration.

The Pinocchio pretotype is useful for any product that lives in a physical context — wearables, IoT devices, in-home or in-car experiences. The cost of fabricating a non-functional shell is trivial relative to building the real device, and the data on whether the user actually wants to interact with it in context is dramatically better than survey data about hypothetical interest.

The Fake Door pretotype

The Fake Door is a public advertisement for a product that does not yet exist. The user sees the ad, clicks through, and lands on a "coming soon" page or a signup form. The team measures click-through rate, signup rate, and other engagement metrics, treating the result as a signal of latent demand.

Fake Doors are now standard practice in growth and PM work, but Savoia popularized the technique in his book. The canonical example: a team considering a new feature for an existing app adds the feature to the app's menu, but tapping the menu item leads to a "this feature is coming soon — want us to email you when it's ready?" screen. The team measures how many users tap, how many submit emails, and uses that data to inform whether to build the feature.

The Fake Door has obvious ethical concerns — users are being shown something that does not work. Savoia argues that as long as the "coming soon" treatment is honest and the user is given the choice to sign up rather than being left frustrated, the technique is acceptable. Modern PM practice generally agrees, with the caveat that overuse of Fake Doors erodes user trust and should be reserved for genuinely uncertain decisions.

The Provincial pretotype

Test demand in a single small market before launching globally. Savoia's example: a team considering a global product launch tests in a single city first, measuring adoption and feedback before scaling. The Provincial pretotype reduces risk by limiting the cost of a wrong bet; if demand fails in the test market, the team cancels before committing to global infrastructure.

The Provincial pretotype is essentially the geographic version of an A/B test. It works particularly well for services with operational components (food delivery, ride-sharing, marketplace products) where geographic scaling is expensive and slow. Test in one city; expand if it works; cancel if it does not.

The One-Night-Stand pretotype

A live but temporary version of the product. Run it for a day, a weekend, a week. Measure usage. Then shut it down. The temporary nature means the team does not invest in production-quality infrastructure, ongoing support, or marketing — they just put up a working version, see who uses it, and tear it down.

The One-Night-Stand is useful for testing services that need to actually run to generate demand data, but where the team is not ready to commit to long-term operation. Pop-up shops in retail are physical-world One-Night-Stands. Limited-time online services (a temporary booking platform, a one-weekend tool) are digital equivalents.

The Re-Label pretotype

Take an existing product, slap a new label on it, and see if customers respond differently. Savoia's example: a team considering a new luxury version of a product takes the existing standard version, re-labels it with the luxury packaging and price, and sells it at the luxury price in a test market. If customers buy at the luxury price, demand for the luxury positioning is validated; if not, no luxury build is needed.

Re-Labels work surprisingly well in consumer products where positioning matters as much as the underlying product. The same beer in fancy packaging at twice the price either sells or does not; the data is fast and cheap.

YODA vs OPO: Your Own Data vs Other People's Opinions

Savoia coins one of the book's most useful acronyms: YODA, Your Own Data, beats OPO, Other People's Opinions. The argument is that survey data, expert predictions, analogical reasoning from other products, and management intuition are all unreliable signals of real demand. The only signal that consistently predicts demand is data from your own pretotype.

The reason OPO is unreliable: users do not know what they want until they see it, experts predict by analogy to past successes (which are often non-comparable), and management intuition is biased toward ideas the management has already invested in believing. YODA cuts through all of these biases by generating real behavior data — what people actually clicked, signed up for, paid for — under conditions that approximate the product launch.

The implication is that teams should refuse to make build decisions based on OPO. If the only evidence for a product is "users tell us in surveys they would love it" or "the CEO is excited about it," the team should require a pretotype before committing significant build resources. If the team cannot design a pretotype that produces a yes/no answer, the team probably does not understand the demand question well enough to build the product.

Pretotyping metrics: TRI and active investment

Savoia introduces several metrics for evaluating pretotype results. The most useful is the Thoughtland-Reality Ratio (TRI), which compares the assumed demand from thoughtland (what management thinks users will do) to the actual demand from the pretotype (what users actually do). A TRI close to 1.0 means the team's intuitions are calibrated; a TRI of 0.1 means the team is dramatically overestimating demand, and the project should probably be cancelled.

He also emphasizes the difference between passive interest ("yes, I would use that") and active investment ("here is my email", "here is my credit card", "I clicked the buy button"). Passive interest is cheap and unreliable; active investment is expensive and reliable. Pretotype design should always extract active investment, not passive interest.

How pretotyping connects to Lean Startup and Continuous Discovery

Pretotyping predates and overlaps with the Lean Startup methodology and modern continuous discovery practice. Eric Ries's The Lean Startup, published the same year as Pretotype It, covers a similar build-measure-learn loop with a similar emphasis on minimum viable products and validated learning. Marty Cagan's product discovery work, especially in Empowered and Continuous Discovery Habits by Teresa Torres, formalizes pretotype-style testing as part of weekly discovery rhythms.

Savoia's contribution is distinctive in two ways. First, the vocabulary — pretotype, Mechanical Turk, Fake Door, YODA — is sharper and more memorable than the parallel Lean Startup vocabulary. Second, the focus on the upstream "should we build this at all" question is more relentless than the Lean Startup's "what is the minimum viable product" framing. Lean Startup teams sometimes interpret MVP as "the smallest version of the planned product" rather than "the cheapest test of whether the product is needed at all." Pretotype is unambiguous: test demand first, then build.

The three texts together — The Lean Startup, Continuous Discovery Habits, and Pretotype It — form a tight cluster of discovery-oriented PM thinking. Read together, they cover the philosophy (Lean Startup), the rhythm (Continuous Discovery), and the techniques (Pretotype). Any team that internalizes all three is unlikely to build major products no one wants.

Worked examples from the book

The book includes dozens of worked examples, both from Savoia's own work at Google and from outside companies. A few of the most instructive:

Google's deliberate cancellations. Savoia describes several Google projects that were cancelled after pretotype data revealed weak demand. The projects were technically interesting but failed the YODA test. Cancelling them freed engineering capacity for projects with stronger demand signal. Savoia argues that the deliberate cancellations were as valuable as the launches, because they avoided the much larger costs of building and shipping products no one wanted.

The IBM voice-to-text Mechanical Turk. Already described above. The pretotype saved IBM from a multi-year R&D commitment to a product whose demand had not been validated.

The Zappos shoe pretotype. Already described above. The Mechanical Turk validated online shoe demand before inventory investment.

The Palm Pilot Pinocchio. Already described above. The non-functional mockup let Savoia decide against a personal purchase based on real usage data rather than imagined demand.

The Pretty Picture pretotype. A team trying to assess interest in a new feature shows users a polished mock screenshot and asks for signups. The signup rate is a demand signal even though no product yet exists.

The Provincial pretotype for restaurant chains. A national chain tests a new menu item in three pilot cities before national rollout. If the cities show poor uptake, the rollout is cancelled.

Critiques and limitations

Pretotyping has been criticized on several grounds:

Fake Doors can erode trust. Users who click through to find a "coming soon" page may feel deceived, especially if the technique is overused. Modern PM practice limits Fake Doors to genuinely uncertain decisions and avoids them for established features.

Pretotype signal can be misleading. A pretotype tests interest in the pretotype, not necessarily interest in the eventual product. A polished Pinocchio may generate enthusiasm that a rough first version does not. Teams should be cautious about over-interpreting pretotype signal as production signal.

Pretotyping ignores the supply side. The book focuses on demand validation but says little about whether the team can actually build, support, and operate the product at scale. Demand validation is necessary but not sufficient; supply-side capability is the other half.

The vocabulary is sometimes evangelical. Savoia's writing is energetic and sometimes feels like marketing copy. The substance is solid, but the rhetorical style can feel oversold to readers who prefer drier prose.

These critiques are real but do not undermine the core argument. Pretotyping remains one of the most efficient ways to test demand before significant build.

How to apply pretotyping in modern PM work

For PMs in 2026, the practical application is:

1. Default to pretotyping for any major build. Before committing engineering resources to a feature or product, design a pretotype that tests demand. If the pretotype cannot be designed, the demand question is probably not crisp enough.
2. Choose the pretotype pattern that fits the question. Mechanical Turk for automation features, Fake Door for new features in existing products, Pinocchio for physical or in-context products, Provincial for geographic services, Re-Label for positioning experiments.
3. Set explicit YODA criteria in advance. Decide what conversion rate, signup rate, or usage rate would be enough to validate building. Do not move the goalposts after the data arrives.
4. Time-box the pretotype. Two days or two weeks, not two months. Pretotypes should be cheap; if a pretotype is taking a quarter, it has turned into a prototype and the discipline has been lost.
5. Be willing to cancel based on YODA. The whole point of pretotyping is to enable confident cancellation when demand is weak. If the team is unwilling to cancel, the pretotype is just theater.

Common failure modes

Pretotype is too polished. The team builds something that looks 80% like a real product, takes weeks to construct, and produces data that is hard to interpret because the polish itself generated some of the demand signal.

Pretotype is too rough. The team builds something so crude that no one interacts with it long enough to generate signal. The pretotype reads as broken rather than as a placeholder.

No success criteria in advance. The team runs the pretotype, gets data, and then debates whether the data is good enough. Without predefined success criteria, the team will rationalize whatever result fits the bet they wanted to make.

Survey-based pretotype. The team designs a "pretotype" that is actually a survey. Surveys are OPO, not YODA. They generate hypothetical preference, not real behavior, and they do not satisfy the active investment requirement.

Pretotype against the wrong audience. The team tests the pretotype with internal colleagues, friends, or other product enthusiasts. Demand signal from these populations is unreliable; the pretotype needs to reach the target user, not the team's social network.

How the book has aged

The book is now fifteen years old and shows its age in a few ways. The examples are pre-mobile-app-era for the most part; modern PMs need to update the technique catalog for app-native testing. The Fake Door technique has become standard practice in growth teams, sometimes overused. The Mechanical Turk technique is now sometimes called "Wizard of Oz" in modern UX literature, with the same meaning.

But the core argument has aged exceptionally well. The discipline of testing demand before building, the YODA-over-OPO principle, and the specific pretotype patterns are all directly applicable to 2026 PM work. The book is shorter than most PM books, can be read in a single sitting, and produces a vocabulary shift that lasts a career.

Companion reads

• The Lean Startup by Eric Ries — the broader discovery philosophy in which pretotyping sits.
• Continuous Discovery Habits by Teresa Torres — the weekly rhythm that makes pretotyping a habit rather than a one-off practice.
• The Mom Test by Rob Fitzpatrick — how to do customer conversations without generating false positive signal.
• Testing Business Ideas by David Bland and Alex Osterwalder — a structured catalog of validation experiments, complementary to pretotype patterns.

Closing thought

The greatest waste in tech is not bad execution. It is brilliant execution of products no one wanted. The cost of a failed launch is not just the engineering time — it is the opportunity cost of not having built the right thing, the morale cost of building something that died, and the reputational cost of asking users to care about a product that did not earn it.

Pretotyping is the discipline that prevents this waste. It is cheap, fast, and uncomfortable — uncomfortable because it forces teams to confront the possibility that their idea is not as good as they thought, before they have invested too much to be objective. The discomfort is the value. Teams that cannot tolerate the YODA-told-us-no result will build products no one wants. Teams that embrace it will spend their engineering resources on the smaller set of ideas that actually deserve to exist.

Read this book once. Then design a pretotype before your next big build. The technique is more important than the specific examples in the book; the discipline of demand validation before build is the lasting contribution.

A practical 30-day pretotyping experiment

For a team that has never run a formal pretotype, the entry pattern is:

Week 1: Pick a feature on the roadmap that you have moderate confidence in. Design a Fake Door pretotype for it — a menu item, a card on the home screen, or a promotional placement that leads to a "coming soon — want to be notified?" page. Set a target click-through and signup rate that would justify building.

Week 2: Ship the Fake Door to 5-10% of users. Let it run for at least a full week to control for day-of-week effects.

Week 3: Analyze the data. Does it meet your prespecified criteria? If yes, proceed to building (and use the email list of signups as your beta cohort). If no, document the result, cancel the feature, and reallocate engineering capacity to the next priority.

Week 4: Run a retrospective. Was the pretotype data better than the team's prior intuition? Did anyone push back on the cancellation (or on the proceed)? What would you do differently next time?

Teams that complete this 30-day experiment usually become permanent converts to pretotyping. The combination of low cost, fast data, and confident decision-making is addictive once experienced. The team that ran one Fake Door this quarter usually runs four next quarter, and pretotyping becomes the team's default approach to roadmap uncertainty.

How pretotyping applies to AI products specifically

In 2026, the most exciting and most uncertain product category is AI — chat assistants, copilots, agents, vertical AI applications. Pretotyping fits this category exceptionally well, because the underlying technology is expensive to build (model training, inference infrastructure, evaluation systems) and the demand is genuinely uncertain (users may or may not want AI in any specific workflow).

The Mechanical Turk pretotype is particularly powerful for AI. Before training a model or wiring a complex agent, have a human do the AI's job manually. A user submits a request through a chat interface; a team member responds in real time. The user does not know whether the responder is an AI or a person. The team learns whether the workflow actually delivers value before investing in the technical build. Many of the most successful "AI" startups began as Mechanical Turks — humans manually doing what would later be automated — and only built the AI after demand was clear.

The Fake Door pretotype is also powerful for AI features in existing products. Add the AI feature to the menu, route taps to a "coming soon" screen, measure interest. The data is dramatically more reliable than survey questions about hypothetical AI feature demand, which are universally inflated by the hype cycle.

The Pinocchio pretotype works for AI assistants and copilots. Build a clickable mockup of the AI's interface, populate it with hand-crafted responses to a few canonical queries, and have users explore. Their reactions to the imagined experience reveal whether the AI premise is compelling before any model is trained.

For AI PMs, pretotyping is the antidote to the hype-driven over-building that characterizes much of the current AI product wave. Teams that pretotype carefully ship the small number of AI features that genuinely help users; teams that skip pretotyping ship many AI features that look impressive but go unused.

A note on team culture

Pretotyping is not just a technique; it is a culture. Teams that successfully adopt it share a few traits: they treat ideas as hypotheses rather than truths, they are willing to cancel based on data even when leaders are emotionally invested, they reward people who kill bad ideas as well as people who ship good ones, and they treat the cost of a failed launch as a real cost rather than a sunk cost to be discounted.

Teams that lack this culture will adopt the vocabulary of pretotyping without the discipline. They will run "pretotypes" that confirm what management already wanted, they will move the success criteria after the data arrives, and they will build the product regardless of YODA. The technique fails them because the culture cannot absorb the cancellation signal. Cultural change is a prerequisite for technique change; books like Savoia's are necessary but not sufficient.

For PMs trying to introduce pretotyping into a team or company that does not have the culture, the strongest move is to do it once well — run a high-quality pretotype, generate clear data, make a clear cancel decision, and quantify the resources saved. One concrete success is more persuasive than any amount of philosophical argument. The vocabulary follows the demonstration, not the other way around.

A small dictionary of pretotype patterns from the book

The book introduces or names several patterns; the most useful for a working PM to memorize: Mechanical Turk, Pinocchio, Fake Door, Provincial, One-Night-Stand, Re-Label, Pretty Picture, YouTube (record a demo video that pretends the product exists and measure interest from views and signups), Skywriting (broadcast the offering loudly in a single market and measure response), and Infiltrator (introduce the offering inside an existing channel that already has the audience). Each pattern has a different cost profile, different signal quality, and different appropriate use case. Strong pretotyping teams have all the patterns in their vocabulary and choose the right one for each demand question.

A typology of bad pretotypes

It is worth naming the recurring patterns of bad pretotypes so that teams can recognize them in advance. The Confirmation Pretotype is designed to confirm the team's existing bet rather than test it — success criteria are vague, the population is selected to be favorable, and the team ignores any signal that contradicts the prior. The Theater Pretotype is performed for management approval rather than for learning — the team goes through the motions because the process requires it, but the build decision was made long before. The Friend Pretotype is shown only to colleagues, friends, and other product enthusiasts whose feedback does not represent real users. The Sunk Cost Pretotype is run after significant build has already happened, so the team cannot accept a cancel result without admitting wasted resources, and predictably rationalizes the data to justify the build.

Recognizing these patterns is the first step to avoiding them. A team that has fallen into one of these patterns has not really been pretotyping; they have been generating evidence to support a foregone conclusion. The cure is to set the success criteria publicly before the test, to test with real users from the target population, to stop the build entirely until the pretotype completes, and to be willing to cancel if the data demands it.

The pretotype as a forcing function for crisp hypotheses

Designing a pretotype forces the team to articulate the demand hypothesis in concrete, testable terms. "Users will want this feature" is too vague to pretotype. "10% of weekly active users will click on the feature within their first three sessions of seeing it" is testable. The act of converting vague enthusiasm into specific numbers is one of the most valuable side effects of pretotyping, because it surfaces disagreement on the team that would otherwise stay hidden.

Often the team discovers that members had very different mental models of demand. The engineer was assuming a 50% adoption rate; the PM was assuming 20%; the designer was assuming 5%. None of them had stated their assumptions explicitly until the pretotype design forced the conversation. The pretotype data resolves the disagreement and, more importantly, calibrates the team's intuitions for future bets. Teams that pretotype repeatedly develop progressively better intuitions about what users will actually do, because they have repeatedly tested intuitions against data.

This intuition-calibration effect is one of the longest-term benefits of a pretotyping culture. After a year of running pretotypes, the team's roadmap debates become sharper because everyone has updated priors based on real data rather than thoughtland speculation.

The link between pretotyping and the falsifiability principle

A deeper way to understand pretotyping is through Karl Popper's principle of falsifiability. A scientific hypothesis is only meaningful if there is some observation that could prove it false. A product hypothesis, similarly, is only operationally meaningful if there is some experiment whose result would cause the team to cancel the build.

Pretotypes are falsifiability experiments. They are designed to produce data that, if it comes back negative, will cause the team to cancel. A team that designs a pretotype but is not willing to cancel based on the result has constructed an unfalsifiable hypothesis — they were going to build either way, and the pretotype was theater. Real pretotyping requires that the team genuinely could go either way before the data arrives.

This connection to falsifiability is rarely made explicit in PM literature, but it sharpens the discipline. Before running any pretotype, the team should ask: what specific result would cause us to cancel? If the team cannot answer the question, the pretotype is not designed correctly. The success criteria should be specific and prespecified — a click-through rate of less than X, a signup rate of less than Y, an engagement lift of less than Z. With prespecified criteria, the data has the power to decide. Without them, the team will rationalize whatever result fits the bet they wanted to make.

The discipline of prespecified success criteria is what separates good pretotyping from bad pretotyping. Good pretotyping is a falsifiability experiment with the team's full commitment to acting on the result. Bad pretotyping is data-collection theater that ratifies the team's prior bet.

How pretotyping interacts with stakeholder politics

A pretotype is not just a technique; it is a political tool. Inside companies, ideas are often championed by individual leaders who have invested reputational capital in them. When the pretotype data comes back weak, the political question is whether the leader will accept the data and cancel, or whether they will rationalize the data away and push the build through anyway. Pretotyping works only when leaders are willing to be wrong publicly.

The PM's role in introducing pretotyping is partly technical (designing the right test) and partly political (creating the conditions in which the leader can accept a cancel decision without losing face). The most effective PMs do this by setting up the test as a learning exercise rather than a verdict — "we want to see what users actually do with this before we commit the engineering" — and by celebrating the cancel decision when it comes, framing it as a win for the team's discipline rather than as a defeat for the leader's idea.

Companies where leaders cannot accept cancel decisions tend to produce many launches and few learnings. Companies where leaders embrace cancel decisions tend to produce fewer launches but a much higher hit rate among the ones that do ship. The cultural difference is enormous, and pretotyping is one of the most visible markers of which culture a company has.

On the simplicity of the book

One striking feature of Pretotype It is how short it is. Most PM books are 300-400 pages; this one is barely over 100. The brevity is intentional. Savoia argued that the core idea — test demand before building — does not need 400 pages of explanation, and that long books on simple ideas often obscure the idea behind unnecessary apparatus. The book is closer to a manifesto than a textbook. It can be read in a single sitting and re-read in less than an hour.

The brevity is also pedagogically useful. Because the book is short, teams can ask everyone to read it and reasonably expect them to. Compare this to long PM books which only the most committed team members fully consume. Shared reading drives shared vocabulary, which drives shared practice. A team in which everyone has read Pretotype It can have meaningful conversations about pretotype design within weeks; a team in which only the PM has read it usually fails to move the practice forward.

A worked story: pretotyping a recommendation engine

Suppose a SaaS team is debating whether to build an AI-powered recommendation engine that suggests next-best-actions to users in the product. The engineering estimate is six months and three engineers. The product hypothesis is that users will take more actions and retain longer if they receive personalized suggestions.

The pretotype pattern: a hybrid Mechanical Turk plus Fake Door. The team builds a simple sidebar in the product called "Suggestions for You" with a few hardcoded recommendations seeded by an internal analyst. The analyst manually reviews users' recent activity each morning and adds personalized suggestions to the sidebar for the top 100 power users by overnight cron. The product appears to have a recommendation engine; behind the scenes, an analyst is doing the work.

The team runs the pretotype for three weeks. They measure: how often users open the sidebar, how often they click a recommendation, how often they complete the recommended action, and whether retention or engagement metrics differ between the pretotype cohort and a control cohort that does not see the sidebar.

Three outcomes are possible. Outcome A: the sidebar is opened rarely, clicks are minimal, and no engagement lift is observed. The team cancels the recommendation engine build and saves six months of engineering. Outcome B: the sidebar is opened frequently, recommendations are clicked, and engagement lifts meaningfully. The team commits to the build with high confidence and uses the analyst's manual workflow as the gold-standard training data for the eventual model. Outcome C: mixed signal — opens are decent, clicks are low. The team digs in: is the issue the recommendations themselves (analyst-driven), the placement, or the framing? They iterate the pretotype for another two weeks before deciding.

In all three outcomes the team learns something concrete that no amount of management argument would have produced. The three weeks of pretotype cost roughly one analyst week of effort plus a half-day of engineering for the sidebar shell — perhaps 2% of the cost of the full build. The information value is enormous relative to the cost.

This pattern — hybrid Mechanical Turk plus Fake Door for AI-shaped features — is one of the most useful pretotype designs in modern PM work. Teams that internalize it stop arguing about whether AI features are worth building and start running cheap experiments that produce decisive answers.