Most product teams do not fail because they built the wrong feature. They fail because they built the wrong product, and only found out after months of engineering time were already spent. There is a cheaper way to find out, and it does not involve a single sprint.
It is called pretotyping, a term coined by Alberto Savoia, a former engineering director at Google. He blended "pretend" and "prototype" into one word, and one discipline: fake the product convincingly enough to learn whether anyone actually wants it, before you build anything real.
Why most products fail before a line of code is written
CB Insights studied 431 venture-backed startups that shut down since 2023 and could identify a clear cause of death for 385 of them. Poor product-market fit was the single biggest killer, responsible for 43 percent of those failures, with two-thirds of those companies never finding a market at all, according to the firm's analysis.
That number should worry every product manager. The default outcome of building something is failure, and it usually has nothing to do with execution quality. A beautifully engineered product that nobody wants is still a failed product.
Savoia calls this the Law of Market Failure: most new products fail because almost nobody wanted them in the first place. Building it right cannot save the wrong it.
Where the idea came from
Savoia spent years at Google as what the company called an "innovation agitator," pushing teams to test their riskiest assumption first instead of last. He wrote up the method in his self-published 2011 book Pretotype It, then expanded it into The Right It, published by HarperBusiness in 2019.
His argument is simple. Teams are good at answering engineering questions and bad at answering demand questions, so they quietly skip the demand question and start building. Pretotyping forces the demand question back to the front of the line.
Make sure you are building the right it, before you build it right.
That single sentence is the entire philosophy. Everything else in pretotyping is just tactics for testing "the right it" as cheaply and quickly as possible.
Prototype answers can. Pretotype answers should
A prototype answers an engineering question: can we build it, and will it work. A pretotype answers a scarier, more commercially important question: if we build it, will anyone actually use it or buy it.
Prototypes test feasibility. Pretotypes test demand. A prototype might take a team months and a real budget. A pretotype is designed to take days and cost close to nothing, because its entire job is to fail fast and cheaply if the idea is wrong.
For a PM, this reframes discovery. Before asking an engineering team to derisk feasibility, derisk desirability first. It is a far cheaper mistake to learn that nobody wants a fake door than to learn it after six months of building the real one.
Exhibit A: a block of wood in a shirt pocket
Before the Palm Pilot became one of the first genuinely successful handheld computers, its creator Jeff Hawkins cut a block of wood to the size he imagined the device would be. He sketched a screen and buttons on paper, glued them to the wood, and carried it in his shirt pocket for weeks.
When he wanted to check his calendar, he pulled out the wood and tapped the paper screen with a pen, the same motion a real user would make. He was not testing whether the technology could be built. He was testing something more basic: would he, a realistic user, actually reach for a device like this often enough to want one.
Savoia has cited this as one of his favorite pretotype stories, and it later became known informally as a "Pinocchio" test, a non-functional stand-in used purely to check form, fit, and daily habit before committing to real engineering.
Exhibit B: the typist behind the curtain
In the mid-1980s, IBM was considering a serious bet on speech-to-text technology, a machine you could dictate to and watch your words appear on screen. Building a working version would have meant a massive, expensive engineering effort with an uncertain payoff.
Instead, IBM faked it. A participant spoke into a microphone, and in the next room, a fast human typist transcribed the words in real time, so text appeared on screen as if the machine understood speech. People loved the demo in the room.
Then researchers watched what happened when the novelty wore off. Users' throats got sore from sustained dictation, and many were uncomfortable with a machine, or in this case a hidden person, capturing everything they said aloud. The fake experience revealed a real adoption problem that a working prototype would have taken years and a fortune to uncover. This technique is now known as the Mechanical Turk, named after the famous 18th century chess-playing hoax that concealed a human operator inside a machine.
A third example, closer to a modern PM's desk
Not every pretotype needs a costume. In 2010, Joel Gascoigne wanted to build Buffer, a social media scheduling tool, but he did not start with code. He built a two-page website: the first page described the idea and collected email addresses from anyone interested, nothing more.
He tweeted the link and watched what happened. Once he saw real interest, he added a second page, a fake pricing page, that sat between the pitch and the email signup. Visitors had to click through pricing options before they could leave their email, which meant only genuinely interested people converted.
That small extra click was the whole experiment. It let Gascoigne measure willingness to pay before writing a single line of the actual scheduling product. He built Buffer over roughly seven weeks of evenings and weekends, launched on November 30, and had his first paying customer within four days, with around 4 percent of early users eventually upgrading to a paid plan. The fake pricing page had already told him the number would not be zero.
The playbook: fake doors, facades, and borrowed identities
Savoia catalogued a handful of repeatable pretotyping techniques, and a PM does not need all of them, just the right one for the assumption being tested.
- Mechanical Turk: hide a human where a machine will eventually go, like IBM's typist.
- Pinocchio: build a lifeless dummy to test form and fit, like Hawkins's wooden block.
- Fake Door: put up a button, ad, or landing page for something that does not exist yet, and count who clicks, like Buffer's pricing page.
- Facade: stage a storefront or interface with nothing functional behind it, then see who walks up.
- Provincial: launch to one small market before going wide, to keep the cost of being wrong small.
The common thread is Savoia's YODA principle: Your Own DAta beats everyone's opinions, including your own. Stakeholder confidence is not evidence. A click, a signup, or a walked-up customer is.
One common mistake is worth naming directly. Fake door tests can quietly damage trust, especially in B2B relationships where a customer clicks expecting a real product and instead gets a "coming soon" message. Use the technique sparingly, disclose quickly if someone follows through, and reserve it for early, low-stakes moments rather than pitches to enterprise accounts you actually need to keep.
Keep that mantra visible during planning meetings. Every PRD and every sprint planning session is a chance to ask the demand question before the engineering question.
How to apply this
- Before writing a PRD, write down the single riskiest assumption about demand, not feasibility.
- Pick the cheapest fake that still produces real behavioral data: a button, a landing page, a dummy object, or a hidden human.
- Set a numeric bar in advance, such as a click rate or signup count, so you cannot rationalize a weak result afterward.
- Run the test in days, not sprints. If it costs more than a coffee and a weekend, it has stopped being a pretotype.
- Treat a failed pretotype as a win. It is the cheapest version of the failure you just avoided shipping.
Pretotyping will not replace your discovery process, but it will make the expensive parts of it optional until the data earns them.
Ready to put this thinking into practice before your next interview loop? allthingspm.app lets you practice more than 4,000 mock PM interviews, run mock interviews built from a real job description, and get your resume reviewed against that same JD.
References
- Alberto Savoia, "One of My Favorite Pretotype Stories" (Palm Pilot)
- Alberto Savoia, "The Palm Pilot Story"
- The Right It summary, market failure and techniques
- Exponentially, "How Pretotyping Works With the Lean Startup Approach"
- CB Insights, "Top Reasons Startups Fail"
- SK Murphy, "Pretotyping Techniques for Building the Right Product"
- Buffer, "Idea to Paying Customers in 7 Weeks: How We Did It"
