Every failed product build we have inherited from another team had the same root cause: scope agreed before anyone understood the problem. We use a fixed framework of three steps before we plan a single sprint.
Step 1: Map the real workflow, not the ideal one
We shadow how the process actually happens today, spreadsheets and workarounds included. The gap between what a client thinks their workflow is and what it actually is almost always contains the real product requirements.
Step 2: Scope the outcome, not the feature list
Feature lists grow indefinitely. Outcomes do not. We scope against "reduce onboarding time by half" rather than "build an onboarding wizard". That keeps every sprint anchored to a number the client cares about.
"A scoped outcome survives scope creep. A feature list invites it."
Step 3: Build the riskiest part first
We build and test whatever part has the most technical uncertainty in week one, not week eight. It is the difference between discovering a blocker with time to fix it and discovering it the week before launch.
