Every failed product build we've inherited from another team had the same root cause: scope agreed on before anyone understood the problem. We use a fixed three-step framework before a single sprint gets planned.
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 — Price the outcome, not the feature list
Feature lists grow indefinitely. Outcomes don't. We scope against "reduce onboarding time by half" rather than "build an onboarding wizard" — it keeps every sprint anchored to a number the client actually cares about.
"A scoped outcome survives scope creep. A feature list invites it."
Step 3 — Build the riskiest part first
Whatever part of the build has the most technical uncertainty gets built and tested in week one, not week eight. It's the difference between discovering a blocker with time to fix it and discovering it the week before launch.
