← Back to Playbooks

First Useful Version

Purpose: Build the smallest working version that proves whether the core workflow can improve.

Typical duration: Days, not months. Scope determines the exact timebox.

When to use: After an evidence review confirms the capability is worth trying with more fidelity.

Inputs Required

  • Capability brief
  • Evidence review notes
  • Clear understanding of what "working" means

Principles

Focus: Does it help the work?

Use the safest useful data. Synthetic, anonymized, sampled, or real data may be appropriate depending on risk and access. Do not wait for perfect data if a safer substitute can answer the question.

Prioritize: The core workflow. Can a person use this to make one recurring piece of work better?

Use fast defaults:

  • Simple infrastructure that respects the data and risk profile
  • Minimal interface around the main loop
  • Enough logging and notes to understand what happened

Defer to hardening:

  • Full platform architecture
  • All edge cases
  • Broad rollout
  • Polish that does not affect the learning goal

Ask yourself: "If this helps, what would the next version need to prove?" That is your output.

Process

Step 1: Core Loop

Build the main thing. The one workflow that proves the concept. Get it working end-to-end, even if ugly.

Step 2: Supporting Features

Add what's needed to actually use the core loop. Data input, basic output, minimal UI to navigate.

Step 3: Evidence-Ready

Clean up enough to test with real examples. Document the obvious limitations. Prepare the "here is what a pilot would need" list.

Outputs

  • Working first useful version
  • List of architectural limitations and risk assumptions
  • List of functionality gaps (what users will ask for)
  • Input for pilot requirements

Tips

  • The architecture serves the question being answered. Do not over-engineer for requirements you do not have yet.
  • If you are stuck on infrastructure decisions, go back to risk, data, and who needs to use it.
  • The artifact is not the finish line. It is how you learn what deserves the next round of attention.
  • Previous version = requirements for next version. The limitations define the pilot scope.

Next: Learning Transition -> Pilot Feedback Loop