Product scoping
Agree the acceptance checks before the build
Describe completion in observable terms instead of a list of screens.
Describe an action and a result
For every essential flow, name the starting conditions, user action, and expected result. “The dashboard works” leaves room for disagreement. “After an authorized user records a pickup, the repair disappears from the ready list” gives you a check you can run.
Agree who reviews the result and what evidence they need. Keep design approval, functional acceptance, deployment, and customer adoption separate.
Check failures and access boundaries
Include invalid input, unavailable dependencies, and users who should not have access. An error should tell the user what they can do next without exposing another customer’s information.
Decide what happens to an action whose result is uncertain. Retrying a payment or submission must not silently create a second purchase or record.
Define the handoff
List the agreed hosting destination, account ownership, operating costs, documentation, and support period. Delivery and ongoing operation have different responsibilities.
When a new feature changes the scope, revise the price, schedule, and acceptance checks together before treating it as part of the build.