Analog/Digital

Overview

Analog/Digital involves selling a physical version of a product before building a digital version, particularly when creating the physical form first is more practical.

How to Use This in GLIDR

Within GLIDR's framework, the process involves:

1. Plan phase: Outline why and how you'll create a physical product
2. Research phase: Describe this plan and connect ideas about your product and expected learnings
3. Run phase: Create and distribute the product to test users, gathering feedback
4. Analyze phase: Determine how learnings from the analog version inform digital development

In Brief

This technique decouples risks around physical product delivery from digital components. It works best for software and information-based products that historically had physical forms, or when the final product should remain independent from computers or smartphones.

Questions It Helps Answer

• What is the most usable way to gather or deliver an information-based service/product?
• How does the current analog process work?
• What are the biggest risks around the physical form?

Key Applications

• Internet of Things: Design physical objects before adding distributed software
• Enterprise software: Map existing processes using analog formats before digitizing
• Non-digital users: Create paper-based or event-based versions before digital launch

Benefits

• Greater flexibility before committing to large digital development projects
• User feedback based on tactile responses and actual interaction patterns
• Understanding design criteria and economics of physical forms first

How To

1. Confirm the riskiest assumption involves Value Proposition, Key Resources, or Costs
2. Formulate a hypothesis requiring a physical product version for testing
3. Recruit users/customers
4. Validate your hypothesis

Interpreting Results

"Digital is not good for its own sake." Ensure added features provide useful benefits while managing increased product complexity.

Potential Biases

• Over-engineering: Physical solutions sometimes outperform complex software
• Over-focusing on technology: Test business models first if technology is proven low-risk

Field Tips

"A minimum viable product is not always a smaller/cheaper version of your final product." — Steve Blank

Adapted from The Real Startup Book, edited by Tristan Kromer and published by Kromatic, under a Creative Commons Attribution-ShareAlike 4.0 International License.