GLIDRGLIDR·Help Center
Archived article. This page is preserved for old links but is no longer linked from the navigation or search. The content may be outdated.

Analog/Digital

Updated May 1, 20192 min read

Overview

Method category: Generative product research

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

Was this article helpful?