Three Questions I Ask Before Scoping Any Project

Most scope creep doesn't happen mid-project. It happens before a single line of code is written, baked into a spec that sounded reasonable but was never actually tested against a few simple questions.

The three questions

Before I'll scope any project, I want clear answers, in plain English, to three things: What's the one thing a user needs to do for this product to be worth building? What's the fastest way to test whether they'll actually do it? And what can we remove without breaking the answer to the first question?

Why plain English matters here

If a founder or a client can't answer these in a sentence or two each, that's not a sign they need to think harder alone and come back later, it's a sign the spec isn't actually ready, and that building from it anyway is how projects go three times over budget while still missing what users needed. A spec that sounds thorough can still be hiding an unclear answer to "what's this actually for," and that gap is far more expensive to discover halfway through a build than at the very start.

What asking these questions actually does

The third question, what can be removed, is usually the one that does the most work. It's easy to list features that would be nice to have. It's much harder, and much more valuable, to identify which of those features the core answer to question one doesn't actually depend on. That's where most of the safe scope-cutting lives, not in painful tradeoffs, but in things that felt necessary only because nobody had asked whether they were.

Why I treat this as engineering, not overhead

Clients sometimes experience this kind of questioning as a delay before the "real work" starts. I'd push back on that framing. Discovery, done this way, is the cheapest engineering work either of us will do on the whole project, because every hour spent here is an hour that doesn't get spent rebuilding something that was scoped on an answer nobody actually checked.