Projects don't derail on technology. They derail because nobody wrote down what wasn't in v1. How to scope in four weeks.
Development projects rarely fail for technical reasons. They fail because nobody wrote down what wasn't in v1.
The mechanism is always the same. Scope is agreed verbally at kickoff. Every week adds one reasonable idea — one, never two. Nobody says no, because each idea in isolation costs two days. By sprint 8 the date has slipped two months and nobody can say which decision caused it. None of them did. Their accumulation did.
The cost of a fix, by when you find it.
An error found on a mockup costs 1. On a tested prototype, 3. In shipped code, 15. After launch, on real data, 50 to 100. The exact factor is debated across studies; the order of magnitude isn't — and it alone justifies spending a month scoping a six-month project.
What scoping actually produces.
Not mockups. Written decisions. The problem, phrased as a testable sentence: “organisers lose two hours per event reconciling guest lists” can be checked. “Improve the event experience” can't be checked, so can't be challenged, so scopes nothing.
One user, not three. A product serving organisers, attendees and partners from v1 serves none of them properly. Pick the one whose pain is sharpest and accept disappointing the other two for six months.
The out-of-scope list is the most important document, and the one almost nobody writes.●
It's what lets you answer “yes, in v2” instead of “we'll see”. Without it, every good idea becomes a negotiation.
The regulatory constraint, identified now, alongside the problem and the market: it shapes the data model. Discovered in sprint 10, it forces a migration. And a prototype five people have actually handled — not been shown: handled, in silence, while you watch them hunt for a button that seemed obvious to you.
Why five users.
Because the return collapses after that. Five people reveal the great majority of usability problems on a given journey; the sixth mostly confirms what the first five already showed. Five interviews fit in three days and need no research budget — which removes the last excuse for not doing them.
It's those five people who will tell you the feature you're proudest of interests nobody. Better to learn it in week 4 than in month 7.
The four-week rule.
Week 1, the problem and the constraint. Week 2, journeys and trade-offs. Week 3, mockups and the design system. Week 4, testing, corrections and an estimated backlog. Four weeks, because beyond that scoping becomes a way of postponing the build. Below it, you skip user testing — and scoping loses what makes it worth doing.
The sign that scoping worked.
A developer who has never spoken to your client can pick up the file and start on Monday without asking you three blocking questions. That's the only criterion that counts. If the file only stands up with you in the room, it isn't finished.
What we don't do.
We don't start a scoping phase without access to five target users. It's a condition, not a preference — without them we produce a document of opinion, and you don't need us for that.