FDE Foundations · Module 2: Customer Discovery
Working with Ambiguity
Ambiguity is a list of unknowns, not a mood. Write the unknowns down, rank them by cost of being wrong, and test the top one cheaply before committing scope.
9 min reading
Objectives
- Separate unknowns into testable questions
- Convert assumptions into hypotheses with cheap tests
- Decide when ambiguity blocks scope and when it does not
Name the unknowns
After discovery, write every unknown as a question: "Do invoices arrive in one format or nine?" "Is the nightly window two hours or thirty minutes?" Questions are actionable; a vague sense of fog is not.
Rank by cost of being wrong
Not all unknowns deserve the same attention. A wrong guess about invoice formats costs a parsing bug. A wrong guess about the batch window costs the architecture. Rank by what it costs to be wrong, then test the top item first.
Cheap tests before commitments
Most discovery unknowns can be tested in hours: pull ten sample records, read the integration docs, run a timed dry run. A test that takes an afternoon prevents a two-week misbuild. If a hypothesis cannot be tested cheaply, make the scope conditional on it and say so in the brief.
When ambiguity blocks scope
If a load-bearing unknown remains unresolved at framing time, shrink the scope to a phase that does not depend on it, or make the first deliverable the test itself.
Ambiguity is not resolved by confidence. It is resolved by a small experiment with a timestamp.
Quick check
An optional 2-3 question self-check. Answers never leave your device, are not stored, and never count toward any assessment.
Exercise
Take a task in your current work with three unknowns. Write each as a question, rank by cost of being wrong, and design a test under two hours for the top one.
Pass criteria
Three questions written, ranking justified with one sentence each, and the top test has a concrete method and a time box.