Mission
By the end of this chapter, you can convert an ambiguous zero-to-one idea into evidence milestones, a thin end-to-end slice, and bounded product or platform launch decisions.
- Measurable outcome: Turn an ambiguous zero-to-one idea into a sequence of learning, integration, and launch decisions, each with a falsifiable question and evidence threshold; score at least 3 of 4.
- Prerequisites: Chapters 9, 10, 13–16, 20, and 25.
- Work product: An Experiment-to-Launch Map for a new product or internal platform.
- Time: 70–90 minutes.
Before you read: Predict → Commit → Connect
Helios Support has an impressive prototype: it answers a curated set of billing questions. Leadership announces a launch in eight weeks. No one has confirmed whether support agents will use it, whether source systems can meet latency needs, or who handles an unsafe answer.
Predict the next decision, not the next task. Commit to one question that must be answered before the program becomes a production launch. Connect to Chapter 9: requirements begin as hypotheses and constraints, not as polished certainty.
Zero-to-one is a sequence of uncertainty retirements
A zero-to-one program does not start with a reliable plan for building a known thing. It starts with several coupled uncertainties:
- Desirability: Is the outcome valuable to a real user in a real workflow?
- Feasibility: Can the technical system produce it within quality, security, cost, and operational constraints?
- Viability: Can the organization sustain the economics, support, ownership, and governance?
- Usability and adoption: Will intended users understand, trust, and incorporate it?
- Operability: Can teams observe, contain, recover, and learn in production?
Treating all five as engineering execution produces feature-complete surprises. The TPM creates a program in which the cheapest credible evidence attacks the most consequential uncertainty first.
These labels are evidence states, not environments. A prototype can run on production infrastructure and still provide only prototype evidence. A pilot is not “production for friendly users”; it needs a bounded population, explicit learning goals, support and incident paths, consent or notice where required, success/stop criteria, and an end date.
Product and platform topologies differ
A product launch connects a capability to an external or internal user outcome. A platform launch serves builders who then create outcomes for their users. The platform therefore has at least two customer systems: adopters and downstream users. A platform that is technically available but painful to adopt is not successfully launched.
For a platform, define an adoption journey: discover, evaluate, integrate, test, launch, operate, upgrade, and exit. Each step can be a program dependency. Documentation, sandbox access, quotas, versioning, support response, migration policy, observability, and cost allocation are product surfaces, not administrative extras.
Zero-to-one milestones should express evidence gained, not activity completed. “Prototype built” is weak. “Five support agents complete the top three workflows with no critical policy violation, and we understand every failure” is decision-grade. “API released” is weak. “Two independent teams integrate from documentation within two days and operate against the SLO for four weeks” is stronger.
Build a thin, end-to-end learning slice
The first slice should traverse the important seams with minimal scope: user, interface, data, model or business logic, permissions, observability, human support, and recovery. A wide demonstration that bypasses identity and operations may look advanced while leaving the hardest risks untouched.
For Helios, a useful slice might support one billing-intent class for trained internal agents, retrieve from one authoritative source, cite evidence, require human approval, log decisions without raw sensitive content, and include an emergency disable control. It produces less spectacle and more truth.
Decide in advance what evidence causes continuation, redesign, or stop. Stopping an invalid path is a program success when the decision arrives before full-scale investment.
Decision rights: Who owns what?
- Product owns the user problem, value hypothesis, priority, and product acceptance.
- Engineering/Architecture owns technical design, feasibility evidence, and engineering quality.
- Design/Research owns research integrity and usability evidence within the local model.
- Platform product/engineering leadership owns platform contract, adopter experience, and lifecycle policy.
- Security, Privacy, Legal, SRE, Support, and Operations own specialist constraints and readiness evidence.
- The TPM owns the integrated uncertainty map, evidence sequence, cross-team thin slice, decision calendar, and transition from exploration to governed delivery.
The TPM must not turn discovery into a hidden commitment. Record who can authorize broader exposure, spend, or irreversible architecture.
I do
I replace Helios’s eight-week launch plan with four evidence decisions:
- Problem gate: observed billing workflow and consequence are consistent across representative agents.
- Feasibility gate: the end-to-end slice meets evidence-grounding, latency, privacy, and handoff constraints.
- Pilot gate: a bounded agent group improves resolution while unsafe/unsupported cases reliably hand off.
- Production gate: Chapter 25 readiness evidence exists, with outcome monitoring and a disable path.
I retain an eight-week target only as a scenario. The evidence determines exposure, not the calendar alone.
We do
Leadership wants Helios available to every agent to gather data faster. The pilot team argues that broader traffic will improve learning; Privacy says the current logging design is not approved for all regions.
Together propose the smallest expansion that increases learning without silently broadening the unverified risk.
Show the model answer
Model answer
Expand by a bounded set of intents, trained agents, and approved regions rather than by all users. Minimize and region-scope logs, keep human approval, define a sample and review method, and set stop criteria for privacy, answer quality, and handoff delay. The learning question is whether performance generalizes across representative workflows, not whether maximum traffic can be acquired.
Rubric (0–4)
- 0: Chooses full launch or total stop without a learning design.
- 1: Suggests a pilot but omits population, question, or stop condition.
- 2: Bounds exposure and names metrics but misses a cross-functional constraint.
- 3: Links representative scope, evidence, controls, owner, and next decision.
- 4: Also tests selection bias, reversibility, and the cost of operating the pilot.
You do
Create an Experiment-to-Launch Map:
| Decision | Most consequential uncertainty | Cheapest credible test | Population/scope | Evidence threshold | Stop/revise condition | Owner | Date |
|---|---|---|---|---|---|---|---|
| Pilot billing assist | Can agents use grounded answers safely? | One-intent end-to-end slice | 10 trained agents, one region | Policy pass + workflow evidence | Any cross-tenant disclosure | Product/Eng/Privacy |
Include at least one desirability, feasibility, adoption, and operability decision. Then draw the end-to-end slice and mark every deliberately deferred component. For each deferment, state what evidence is therefore not available.
Pause & Recall
Name the five uncertainty classes without looking. Recall Chapter 15: which interface is most likely to become the critical integration dependency? Recall Chapter 25: what converts a successful pilot into launch readiness? Explain why “working prototype” is not a production claim.
Production lens
Prototype shortcuts have a habit of becoming production dependencies. Label disposable components, data, credentials, and environments; assign removal owners. Measure who is excluded from discovery and pilot populations. For platforms, fund versioning, migration, support, and deprecation before adoption becomes organizational lock-in.
Workplace artifact: zero-to-one decision statement
Copyable decision statement
We are deciding whether to move [concept] from [evidence state] to [next state]. The uncertainty is [question]. We will test it with [bounded slice/population]. Continue requires [threshold]; revise/stop occurs on [condition]. This decision does not establish [claims outside scope]. Owner: [role]; review: [date].
Chapter compression
Zero-to-one work is a sequence of evidence decisions across desirability, feasibility, viability, adoption, and operability. Build thin end-to-end slices that touch hard seams. Platform programs must serve adopters and downstream users. Milestones should state what uncertainty was retired.
Retrieval deck
- Q: What distinguishes a pilot from an informal beta? A: Bounded population, explicit learning question, controls, success/stop criteria, support, and end date.
- Q: Why is “prototype complete” weak? A: It says what was built, not what claim was tested or what decision the evidence supports.
- Q: Who are a platform’s two customer systems? A: Adopting builders and their downstream users.
- Q: What is a thin end-to-end slice? A: Minimal scope that traverses the important user, technical, control, and operational seams.
- Q: When is stopping success? A: When evidence invalidates a path before larger irreversible investment.
Spaced review
- Now: Write the most consequential uncertainty and cheapest credible test.
- +1 day: Reconstruct the five uncertainty classes from memory.
- +3 days: Draw a thin end-to-end slice and label deferred evidence.
- +7 days: Convert three activity milestones into evidence milestones.
- +14 days: Compare a predicted uncertainty with pilot evidence and close, revise, or stop it.