Product & engineering ·
Write the acceptance test before the build
A clear sentence at the start is cheaper than a disputed assumption at delivery.
Ambiguity looks harmless at kickoff because everybody can imagine the version they want. During a build, those private pictures turn into different product decisions.
Before implementation begins, we write down the important conditions a feature must satisfy. "A user can reset a password" describes an intention. The useful version covers who can request it, what they receive, how long it remains valid, and what happens when it is used twice.
This makes a fixed scope more honest. A milestone can be reviewed against conditions both sides already understood, and a missing decision appears while it is still cheap to make.
The habit is simple: keep asking "How would we know?" until the answer can be observed.