Agree what finished looks like before you build
Clear acceptance criteria help everyone catch missing decisions before they become expensive changes.
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.