discovery — two paths
Two paths — one question separates them
Discovery produces a brief. Which brief depends on one question: who is the witness? Not what kind of work — who the witness is. That distinction changes the structure, who agrees on it, and what the prediction must contain.
Feature path — end user doing observable work
The witness is a real person doing real work in real conditions — actual work, with actual pressure, with the friction that has been accommodated into the routine. Gal grading 28 exams on a Wednesday afternoon. Uri reconciling Cardcom settlements against subscription records at 7am because he cannot trust the billing numbers.
Output: Feature Brief. Trio: Project Lead + Designer + Tech Lead when architecture is involved. Prediction: specific observable change in a specific person's situation.
Technical path — system observed by engineer or operator
The witness is the system itself, observed by someone who can read what it is telling them. Production metrics over real time — not modelled. Seven months of Cardcom settlement data showing 993 subscription charges dropped silently with no error, no retry, no log a non-engineer could find.
Output: Technical Design Brief. Trio: Tech Lead + DevOps + Project Lead. Prediction: requires both a technical metric and a human signal. Cannot name the person? The scope is probably wrong.
"It's just technical" is not a reason to skip the brief — it is a reason to use the Technical Design Brief. Infrastructure without a named human consequence is infrastructure without a clear purpose.
How to apply this
- ✓ For both paths: can you name the person who will feel the change after delivery? Feature path: the person observed. Technical path: the person whose workaround disappears. If you cannot name them, revisit the scope.
- ✗ Do not choose the path based on which team does the work. A feature requiring only backend implementation still uses the Feature path if the witness was an end user.