5.1 Analog/Digital
At a Glance
Other names Analog Prototype · Manual MVP
In Brief
Deliver a physical or analog version of your product — a paper form, a spreadsheet, a printed guide, or a simple physical model — in place of the software you plan to build. You provide the analog form to real participants, observe how they work with it, and collect feedback on what works and what does not. The output is hands-on learning about which parts of the workflow deliver value, which can be simplified, and whether a digital version is worth building at all.
Common Use Case
You plan to build software that automates something your customers currently do manually. Before investing in development, you deliver the service by hand to a few customers so you can learn exactly which steps matter, which can be simplified, and which can be removed entirely from the eventual digital version.
Helps Answer
- What is the best way to deliver an information-based service when customers may not want or need an app?
- How does the current manual process actually work in practice?
- What are the biggest risks in the physical form of our product?
- Which parts of the analog workflow add real value versus unnecessary complexity?
Description
Analog/Digital is a method for testing a digital product’s value by delivering it first in a manual or physical (“analog”) form, before building the digital version. Many products combine a physical form with a digital component, where software adds value to an underlying product — but not every step of an analog process gains value from being digitized, and the point of going digital is the value it creates, not the technology itself. Running the analog version first de-risks assumptions about the form a product or service should take before you commit to building software.
The defining move is that a non-digital artifact stands in for the software; it need not be run by hand. When a person performs the service end-to-end by hand instead of an artifact standing in for it, that is a Concierge Test.
AI development tools now build digital versions quickly and cheaply, so the temptation to skip straight to a digital product is strong. The analog phase exists to learn what to build. Working with a physical artifact surfaces design problems that planning alone misses.
An analog prototype is the right fidelity for testing whether the workflow itself delivers value, before you invest in pixel-perfect software. Simple materials — paper, foam board, or an outsourced 3D print — are usually all the analog approach requires.
Suppose you want to build software that schedules a home-cleaning service — matching customers to cleaners, planning routes, and handling reschedules. Before writing any code, you run it by hand for a dozen real customers: a shared spreadsheet, a few text messages, and a printed schedule handed to each cleaner in the morning. Doing the job manually shows you which decisions genuinely need automating, which ones a person would rather keep judgment over, and whether customers value the service enough to pay — all before you have built anything. Only the steps that earn their keep in the manual version make it into the eventual software.
The same pattern fits other forms. For a connected hardware product, sell and refine the physical object before adding the companion app. For an enterprise workflow, map and streamline the process on paper before automating it. For an audience that does not want an app at all, deliver an information product as a printed guide or a live event first. In each case you stay flexible before committing to a large build, you watch how people actually handle the product rather than what they say in an interview, and you learn the economics of the manual form before paying to make it digital.
How to
Prep
-
Identify your riskiest assumption. Confirm that what you need to test is about the value proposition, workflow, or cost structure, not just a technical question. Analog-digital testing works when you need to learn whether the process itself delivers value, before investing in software.
-
Define the learning goal. Write down the one decision the analog run should inform. Common framings: “Does this workflow deliver enough value to justify automating it?” “Which steps add value and which are friction we should remove?” “What does the user actually do with the output?” Without a goal, you will collect impressions instead of evidence.
-
Pick the analog format. Match the format to the workflow you are testing. Paper forms and spreadsheets fit document-based workflows. Email, phone, and in-person handoffs fit marketplaces and matching. Printed guides, workshops, or live events fit information products. Physical mockups (foam board, 3D print, off-the-shelf hardware) fit connected and internet-of-things (IoT) devices.
-
Recruit 5–10 participants. Pick participants who would plausibly buy or use the digital version once it exists. Confirm they have a real task to complete using the analog version, not a hypothetical one.
Execution
-
Run the analog version with participants. Have them use the physical version to complete a real task. Observe where they struggle, what they skip, what they ask for, and what they find valuable. Record their reactions.
-
Capture what happens, not just what they say. Note the steps participants improvise, the steps they skip, and the moments they ask “is this all I need to do?” These are the signals that tell you which parts of the workflow matter.
-
Decide what to digitize (and what not to). Based on what you observed, identify which steps benefit from being digital (speed, scale, automation) and which work fine in analog form. Not everything needs to be software. Build only what the analog test proved was valuable.
Analysis
Digital is not good for its own sake. Make sure that you are adding useful features and benefits as you add to the product’s complexity.
-
Score each step on value delivered vs. friction caused. Which steps did participants complete eagerly? Which did they skip or complain about? High-value, high-friction steps are the strongest digitization candidates.
-
Separate workflow value from interface value. Sometimes the workflow is right and only the interface needs work. Sometimes the workflow itself is wrong and a polished interface would just hide the problem. Decide which one you are looking at before you scope the digital build.
-
Compare the analog economics to the digital economics. What does it cost to deliver the analog version per participant? What would the digital version cost? If the analog form already meets the participant’s need at a workable cost, a digital version may not be worth building yet.
- Premature digitization bias You default to adding software because it feels like progress. If the analog run meets the user need at a workable cost, shipping a digital version adds complexity without adding value, and the analog form is the product.
- Confirmation bias It is tempting to read the analog run as proof the digital product will work, noting only the moments that support building it. Decide your value-versus-friction scoring criteria before the run, and record the steps users skipped or improvised as carefully as the ones they completed.
- MVP misread A minimum viable product is not always a smaller or cheaper version of your final product. It is the smallest thing that produces the learning you need, which is sometimes a different product entirely.
Learn more
Case Studies
GE Healthcare: Hands-on infant monitoring trial
GE Healthcare validated a new infant monitoring concept in emerging markets by deploying trained nurses with portable tools to deliver the workflow by hand, learning what to build into the eventual device before committing to manufacturing.
Artivest: Paper-to-platform FinTech
Founder James Waldinger digitized a private-investment process the source describes as “still back in the stone age,” replacing paper-based documentation flows with a unified digital platform that let individuals and advisors access private equity and hedge funds.
Agricultural drones: MVP that learns, not a cheap product
Steve Blank uses precision-farming drones as the canonical example of an MVP that is a different product from the eventual one, designed to produce learning rather than to be a smaller version of the final offering.
Further reading
- Mark Bonchek — How to Create an Exponential Mindset (Harvard Business Review, 2016)
- Steve Blank — An MVP Is Not a Cheaper Product, It’s About Smart Learning (steveblank.com, 2013)
- Tim Brown — Change by Design (Harper Business, 2009)
- Bill Buxton — Sketching User Experiences (Morgan Kaufmann, 2007)
- John Mullins & Randy Komisar — Getting to Plan B (Harvard Business Press, 2009)
Got something to add? Share with the community.
