View source for Pretotype your objectives

<span id="pretotyping-validate-ideas-quickly-before-you-build"></span>
= Pretotyping: validate ideas quickly before you build =

'''Pretotyping''' is a lightweight approach coined by Google’s Alberto Savoia to test whether a product '''should''' be built before asking if it ''can'' be built. Instead of diving into full development (or even an MVP), pretotyping uses the smallest possible experiments to gauge real user interest and behavior. Think of it as &quot;fake it before you make it.&quot; Pretotypes range from simple ads and mockups to role-playing demos; they let you collect your own data (YODA: ''Your Own Data'') about customer appeal with minimal cost and time. Pretotyping differs from prototyping, MVPs and pilots.

<span id="pretotyping-vs.-prototyping-vs.-mvp-vs.-pilot"></span>
== Pretotyping vs. Prototyping vs. MVP vs. Pilot ==

It helps to contrast pretotypes with other early tests:

* '''Pretotype (Should we build it?)''' – A quick, cheap experiment to test interest or appeal, often ''before'' any real product exists. For example, a landing page or ad that looks like your product but doesn’t actually work (a ''Fake Door'' test) gauges if people will &quot;buy&quot; or sign up. Pretotypes answer &quot;''if''&quot; there’s demand (market appeal) without building the product.
* '''Prototype (Can we build it?)''' – A preliminary ''working model'' of the product. It answers &quot;''how''&quot; to build the solution by testing design, functionality, and technical feasibility. Prototypes (or mock-ups) are useful after validation to refine the product and catch design flaws. They tend to be more expensive and time-consuming than pretotypes.
* '''MVP (Minimal Viable Product)''' – A minimal feature set of the actual product, launched to early users. An MVP is a ''usable'' version that lets people actually try the product, unlike a pretotype. It still aims to learn (from real usage) but comes ''after'' pretotyping has confirmed demand.
* '''Pilot''' – A small-scale trial release (often limited by geography or customer group) of a working product or service. Pilots test viability in a real environment and are typically done when you already have a built solution to evaluate its performance before full launch. Pilots differ from pretotypes in that they involve the actual solution (or at least a working model), rather than a simplified stand-in.

These steps often occur in order: first '''pretotype''' to see if it’s worth pursuing, then build a '''prototype''' or MVP to refine and test, and finally run '''pilots''' to roll it out in limited scope. As one guide notes, pretotyping comes first to &quot;validate the product concept before placing resources into developing an actual prototype&quot;. This sequence helps avoid wasted effort.

{| class="wikitable" table-width="760" layout="default" ac:local-id="50057b5e-e491-464f-8c24-99df28073856"
|-
! Experiment Type

! Key Question

! Example/Use

|-
| '''Pretotype'''

| ''Should we build it?'' (tests market interest)

| Fake Door ads or landing pages, wizard-of-oz demos[https://noelito.medium.com/from-prototyping-back-to-pretotyping-27ba1959fa06#:~:text=1,curtain%20to%20simulate%20complex%20technology noelito.medium.com]

|-
| '''Prototype'''

| ''Can we build it?'' (tests feasibility)

| Working mockup or beta version with core features

|-
| '''MVP'''

| ''Can customers use this?'' (tests core offering)

| First release product to early adopters (minimal feature set)

|-
| '''Pilot'''

| ''Will it work at scale?'' (tests implementation)

| Controlled rollout to a small audience or region

|}

<span id="when-building-new-products"></span>
== When building new products ==

For '''new products''', pretotyping is especially valuable because it focuses on ''demand-side'' validation before any real code or hardware is built. Early on, list your core assumptions (e.g. &quot;Customers will find this useful&quot; or &quot;They’ll pay $X for it&quot;) and ask how to test them cheaply. For example, you might create a simple ad or explainer page for your idea and measure click-throughs or email signups. If interest is low, that’s a red flag to pivot or scrap the idea early, saving time and money. As Horizon’s guide explains, real behaviour data (&quot;if you buy it, we will build it&quot;) is far more reliable than asking hypothetical questions (&quot;would you buy it?&quot;).

Pretotyping is also ideal for exploring '''adjacent new ideas''' or market segments. Use methods like customer journey mapping to identify where the biggest uncertainties lie (see next section). Then run quick tests on those points: a one-page flyer, a crowdfunding pitch, or even a video demo can serve as a pretotype for concept validation. As one study notes, pretotyping &quot;uncovers purchase intent from real consumers&quot; using behavioural data, so you can &quot;gather the most unbiased data possible&quot;. In short, for new products, '''go broad early''': test interest and value proposition cheaply, and only build if the signals are strong.

<span id="when-innovating-existing-products"></span>
== When innovating existing products ==

Even if you have an existing product or service, pretotyping can test '''new features, extensions, or business models''' before development. For example, to test a new feature, you might use a ''Fake Door'' by adding it to your marketing or UI and seeing if users ask for it. To try a price change, you could run an A/B test landing page or crowdfunding campaign to gauge willingness to pay. The same pop-up demonstrations or concierge MVPs used in new products can apply: e.g. offer a manual/handmade version of your feature to current users and see if they adopt it.

Pretotyping lets you &quot;test multiple aspects of the product&quot; (such as branding, target group, price, or features) independently. This is vital when improving products: don’t invest in coding a new version until you know users actually want that specific change. For instance, one team tested a bottled water rebrand as a ''Relabel'' pretotype – buying generic bottles, adding a new label, and seeing if sales improved. If your test shows negligible interest, you saved the cost of development. In short, when innovating an existing product, use pretotyping to validate '''features and changes''' with real users before committing engineering resources.

<span id="pretotyping-method-journey-experiments-analysis"></span>
== Pretotyping method: journey, experiments, analysis ==

A systematic pretotyping process involves three phases: '''1) Customer Journey Analysis, 2) Experimentation, and 3) Analysis/Decision'''.

<ul>
<li><p>'''Phase 1 – customer journey (ideation &amp; hypotheses):''' Map out the steps a customer takes (Discovery, Evaluation, Interaction, Retention, Referral) and list all your key hypotheses at each stage. Use critical thinking to question assumptions – for example, assume the worst-case (&quot;maybe no one will buy&quot;), and plan to test that. Formulate hypotheses (cause - effect), alternative questions (e.g. what price points users prefer), and creative explorations (options you can’t yet dismiss). Prioritize the ''critical'' hypotheses that would kill the product if false (customers won’t pay, find it useless, etc.).</p></li>
<li><p>'''Phase 2 – experimentation (running pretotypes):''' Design simple tests (&quot;pretotypes&quot;) to validate your top hypotheses. Choose from known techniques (see next section) or invent new ones. Identify a small, relevant sample of users or venues (early adopters, target segments) to try your pretotypes. Run the experiments ''as objectively as possible'': e.g. show your pretotype to users without influencing them. Record ''all'' results in a diary – clicks, signups, comments, etc. – focusing on actual behavior, not just opinions. (Pretotyping is about real data: &quot;Your Own Data&quot; from experiments, not just surveys).</p></li>
<li><p>'''Phase 3 – analysis and decision:''' Review the data impartially. Highlight any '''surprising or critical findings''' (positive or negative) and check if they confirm or disprove your hypotheses. You may repeat experiments or try new ones if needed. Use decision frameworks to decide next steps. For example, one approach is a &quot;truth table&quot;: if a key assumption fails, pivot or kill the project; if it holds, continue testing the next assumption. Also analyze critical &quot;factors&quot; that emerged:</p>
<ul>
<li><p>''Critical factors'' = dealbreakers (if absent or flawed, no one will use the product; value = 0).</p></li>
<li><p>''Efficient factors'' = must-haves that users expect (necessary but not differentiating; value = 1).</p></li>
<li><p>''Different factors'' = unique value-adds (features that make users ''want'' your product; value = 2).</p></li></ul>

<p>A simple scoring (multiplying the values) estimates the solution’s ''potential''. For example, if your pretotype data shows critical factors are missing or interest is near zero, it’s a strong sign to stop. If demand is high and key differentiators work, you can proceed to prototyping. Avoid &quot;analysis paralysis&quot; by making decisions quickly: if fundamental assumptions fail, it’s often better to pivot or shelve the idea.</p></li></ul>

Below is a summary table of the three-phase method:

{| class="wikitable" table-width="760" layout="default" ac:local-id="83bab9f1-dbe5-4787-b310-682375320c8e"
|-
! Phase

! Focus

! Key Activities

|-
| # '''Journey'''

| Hypotheses &amp; assumptions

| Map customer journey; list &amp; prioritize hypotheses/questions

|-
| <ol start="2">
<li><p>'''Experimentation'''</p></li></ol>

| Testing ideas cheaply

| Run pretotype experiments (ads, mockups, demos) on real users; gather behavioral data

|-
| <ol start="3">
<li><p>'''Analysis'''</p></li></ol>

| Insights &amp; decisions

| Interpret results objectively; focus on surprising info; decide pivot vs. proceed

|}

<span id="pretotype-techniques"></span>
== Pretotype techniques ==

There are many pretotyping methods. Below are common types, with real-world examples and illustrative images:

* '''Mechanical turk (Wizard of Oz)''' – Simulate the product with human labor behind the scenes. For example, show a &quot;smart&quot; gadget or app interface but secretly have people perform its functions. This tests whether users find the idea appealing before any tech is built. (The name comes from the 18th-century fake chess automaton box &quot;The Turk&quot; that hid a human inside)

* '''Pinocchio''' – Build a simple, non-working model and use it &quot;as if&quot; it were real to test form or UI. For example, Jeff Hawkins of Palm Computing pretotype-tested the Palm Pilot by carving a wooden mock-up and carrying it around, pretending it worked. Although the model didn’t function, it let him observe usage patterns and interest.

* '''Fake door (advertising test)''' – Offer a product or feature that doesn’t exist yet, to measure interest without building it. For example, McDonald’s once tested &quot;McSpaghetti&quot; by putting it on the menu and advertising it – when customers ordered it, staff said it was sold out. The sign-ups and orders revealed demand. Other examples: clickable &quot;Buy&quot; buttons on a brochure or website that return a &quot;not yet available&quot; message. Fake Door pretotypes test initial demand or pricing ''before'' any development.
* '''Pop-Up stand or demo''' – Showcase your idea in a real-world setting. For instance, set up a physical stand or kiosk to pitch your service to actual customers. If you can’t find where ''early adopters'' gather, it questions your value proposition. Use a pop-up to present the concept and co-create with interested users.

* '''Relabel (impersonator)''' – Take an existing similar product and put your new branding or changes on it. For example, one team simply bought bottled water and slapped on a new label to test whether consumers would pay for the &quot;new&quot; brand. This quickly gives an operational version of the product. If sales improve under the new label, that signals genuine demand. Relabeling bypasses development by leveraging what’s already made.

* '''Protogame''' – Replace interviews with activities. Instead of asking users questions, have them perform tasks or play a game that simulates the product experience. For example, to test a workflow, give users cards or tools that mimic different stages of using your service. Observe ''what they do, how they do it, and why''. This uncovers user needs and pain points in context.
* '''Infiltrator (Impostor)''' – Objectively test your value by embedding yourself in the environment. This could mean secretly using or purchasing a competitor’s product to measure reaction, or setting up a dummy sales account to see how customers respond, all without anything illegal or unethical. It’s a &quot;radically objective&quot; way to gauge interest or attractiveness of your proposition.
* '''Lazarus''' – Sometimes ideas that were shelved deserve a second look. The Lazarus pretotype revives an older concept without reinventing the wheel. For example, if a similar solution failed in the past, you might adopt and tweak it to test it anew. The key is to leverage proven ideas rather than starting from scratch.

Each pretotype type has its place. Often you’ll use several in sequence: for instance, run a Fake-Door landing page to gauge interest, then a Mechanical Turk demo to simulate functionality, and finally a Prototype or MVP. Always match the method to what you need to test (see table below). Real-world examples abound: the Palm Pilot (Pinocchio), Coca-Cola’s New Coke survey (Fake Door by putting it on shelves), or Dropbox’s explainer video (video-based pretotype).

<span id="decision-frameworks-and-analysis"></span>
== Decision frameworks and analysis ==

To decide whether to move forward with an idea, use simple decision tools. One is a '''&quot;Truth Table&quot;''' that records key assumptions as true/false (e.g. &quot;Customers are willing to pay $X?&quot;). Each experiment helps fill in this table. If any ''critical'' row becomes false, you have to pivot or drop the idea.

Another is the '''impact/efficiency analysis''' of factors. Categorize findings into ''Critical'', ''Efficient'', or ''Different'' (as defined above) and score them (0, 1, 2). The product of these scores is a rough measure of potential success. High scores across the journey mean strong potential. If scores are low (especially on critical factors), it indicates a likely failure.

Also consider '''customer segments''' and '''context''' in your analysis. An idea might only appeal in certain settings or demographics. Check for biases: for example, an interested friend group might not represent broader users. Rely on ''behavioral data'' (actual clicks, sign-ups, pre-orders) over just verbal feedback[https://www.gethorizon.net/guides/pretotyping-the-complete-guide#:~:text=Research%20that%20relies%20on%20opinions,influence%20the%20research%20cannot%20anticipate gethorizon.net]. And be wary of overfitting one good result; always test key assumptions independently.

<span id="common-pitfalls-and-best-practices"></span>
== Common pitfalls and best practices ==

* '''Don’t trust opinions alone.''' User surveys and interviews are full of bias (politeness bias, hypothetical bias, etc.). Pretotyping focuses on real actions. As one pretotyping guide notes, comparing &quot;''If we build it, would you buy it?''&quot; versus &quot;''If you buy it, we will build it''&quot; highlights this difference. Aim to collect real usage or signup data, not just positive feedback.
* '''Beware confirmation bias.''' Play devil’s advocate: design experiments to ''disprove'' your assumptions as well as prove them. &quot;If it survives my worst-case test, it’s stronger.&quot; Don’t discard negative results – treat them as valuable learning.
* '''Start with the riskiest assumptions.''' Test the &quot;vision killers&quot; first (e.g. target customers wouldn’t pay). For instance, never build a detailed price-sensitive feature until you have evidence people will pay anything at all for your product.
* '''Keep tests discrete and measurable.''' Each pretotype should isolate one aspect/hypothesis. Have clear success metrics (e.g. click-through rate, email opt-in rate, pre-orders).
* '''Choose the right participants.''' Focus on true target users or early adopters, not random people. Quality beats quantity: a few real prospects interacting with your pretotype give better insight than lots of irrelevant opinions.
* '''Iterate quickly.''' Run multiple small experiments rather than one big one. Learn and pivot fast. Track results meticulously and make decisions based on ''your own data''.
* '''Document and review.''' Keep a prototyping log of what was tested and the outcomes. Review surprising data carefully. If something works unexpectedly, double-check it; if it fails, analyze why and adjust.

<span id="tables-experiment-types-and-factor-analysis"></span>
== Tables: experiment types and factor analysis ==

Below are two summary tables to clarify when and how to use different approaches:

'''Experiment comparison:''' Pretotypes focus on desirability (should we build?), prototypes on feasibility (can we build?). MVPs and pilots follow later.

{| class="wikitable" table-width="760" layout="default" ac:local-id="ed599348-da47-4ce3-aa78-041191f292e9"
|-
! Method

! Main Question

! Resources Needed

! Data/Outcome

|-
| '''Pretotype'''

| &quot;''Will customers want this?''&quot;

| Low (ads, mockups, manual demo)

| Customer interest (sign-ups, clicks)

|-
| '''Prototype'''

| &quot;''Can we build this?''&quot;

| Medium (time to code or fabricate)

| Usability and function feedback

|-
| '''MVP'''

| &quot;''Will they use this feature?''&quot;

| High (working product)

| Real usage metrics (active users, conversions)

|-
| '''Pilot'''

| &quot;''Will it work in production?''&quot;

| High (full-scale launch)

| Performance in real market (adoption rate, ROI)

|}

'''Factor impact analysis:''' When analyzing results, classify findings by how they affect viability:

{| class="wikitable" table-width="760" layout="default" ac:local-id="9e41add1-2246-4c41-a376-0d173033bfa6"
|-
! Factor Type

! Impact on Customer

! Example

|-
| '''Critical (0)'''

| Dealbreaker – if missing or wrong, users reject product entirely

| A paid app with users ''expecting'' it free (value = 0)

|-
| '''Efficient (1)'''

| Expected must-have – necessary but not compelling

| A digital app that is usable/intuitive (basic requirement)

|-
| '''Different (2)'''

| Differentiator – adds distinct value and attracts users

| Travel insurance returning money if unsatisfied (unique feature)

|}

Multiply the scores of observed factors to gauge overall potential. A product whose pretotyping reveals many &quot;0&quot; scores is at high risk (drop it), while &quot;2&quot;s indicate strong differentiators worth pursuing.
[[Category:manage objectives]]