Most project failures don't happen in execution. They happen weeks earlier, in a scoping conversation that either never really took place, or took place too fast. Someone describes a "simple redesign," everyone nods, a timeline gets estimated off the top of the head, and three weeks in, it turns out "simple" meant a full re-architecture of the checkout flow.
We've been on both sides of that mistake — as the agency who under-scoped, and as the client who assumed a feature was included when it wasn't. So the discovery process we run now isn't a formality before the "real work" starts. It is the real work, and it happens before we quote a single hour.
The three questions we won't skip
Every discovery call, regardless of whether it's a five-day converter tool or a twelve-week platform rebuild, comes back to the same three questions:
- What's the actual problem? Not the feature request — the problem underneath it. "We need a mobile app" is a solution someone has already decided on. Sometimes it's right. Sometimes what they actually need is a faster mobile website, which costs a fraction of the price.
- Who is this for, specifically? "Our customers" is not an answer. A booking app for time-pressed commuters and a booking app for leisurely weekend planners are different products, even if the feature list looks identical on a whiteboard.
- What does success look like in 90 days? Not "it looks good" — a number, a behavior, a metric. If nobody can name one, we're not ready to scope yet, and pretending otherwise just moves the disagreement to week six of the build.
"Simple" is almost never a scope. It's a feeling someone has before they've looked closely at the problem.
Why we push back on vague briefs
It would be easier, short-term, to take a vague brief, pad the estimate to cover the uncertainty, and start building. We don't do that, mostly because padded estimates don't actually protect anyone — they just delay the moment the real scope becomes visible, usually at the worst possible time in the project.
Instead, if a brief is vague, we spend an extra discovery session narrowing it before quoting anything. That session is unpaid on our side. It's a deliberate trade: we'd rather lose a little time upfront than build the wrong thing efficiently.
What the proposal actually contains
Once scope is clear, the proposal that follows has three parts that matter more than the price line: what's explicitly included, what's explicitly excluded, and what happens if either side wants to change scope mid-project. Most disputes we've seen — on either side of the table — come from an excluded item nobody wrote down, not from bad-faith behavior.
KEY TAKEAWAYS
- A vague brief isn't a small problem you scope around — it's the actual first problem to solve.
- "What does success look like in 90 days" is the single most useful scoping question we ask.
- A proposal without an explicit exclusions list is an invitation to a dispute later.
This space is available for a relevant sponsor or partner. Get in touch to enquire about placement.
Have a project that needs proper scoping?
Tell me what you're trying to build or fix — I'll tell you honestly whether it's a good fit, and what it would take.
Start the conversation →