Scoping the First Engagement — Turning a Vague Ask Into a Real Win
Almost every engagement starts as a wish, not a scope. The skill that most determines whether it succeeds is turning that vague ask into one bounded, achievable first win. Here's how I try to do it.
A client rarely arrives with a well-formed problem. They arrive with a feeling: our demo isn’t becoming a product, or we know AI should help here but we can’t make it stick, or simply we need someone who’s done this before. That feeling is real and important, but it is not yet something you can deliver against.
The work of scoping is turning that feeling into a specific, bounded first win. I’ve come to believe this is the single highest-leverage thing a forward-deployed consultant does, because a well-scoped engagement is already half-delivered, and a badly-scoped one cannot be rescued by any amount of skill.
Scope to a first win, not the whole mountain
The instinct — the client’s and often yours — is to scope the entire vision. The full platform. The system that handles every case. Resist it. An engagement scoped to the whole mountain will drown in edge cases, stall on integration, and end in mutual disappointment, no matter how good the work.
Instead, scope to the smallest thing that is genuinely valuable and genuinely real:
- Genuinely valuable means the client would be glad it exists even if nothing else ever got built. Not a toy, not a proof of concept destined for a drawer — something that does real work.
- Genuinely real means it runs on their actual data, in their actual environment, handling the cases that actually occur. The demo-to-production gap is the whole game, so a first win that doesn’t cross it isn’t a win.
The art is finding the overlap: the narrowest slice that is still unmistakably useful. That slice becomes the engagement. The mountain becomes the roadmap you earn the right to tackle later.
Discover before you commit
You usually can’t scope well from the outside. The vague ask hides assumptions — about the data, the workflow, the real decision the system is supposed to support — that only reveal themselves once you look closely. So I try to build a short, explicit discovery step into the front of any engagement: a bounded period, paid, whose entire purpose is to turn the wish into a scope both sides can commit to.
This protects everyone. The client isn’t asked to commit to a fixed price for a problem nobody understands yet. You aren’t asked to quote a number you’ll regret. And the discovery itself is valuable — often the clarity it produces is worth the fee even if the larger engagement never happens. I’ll devote a whole essay later in this series to the discovery phase, because it deserves it.
Write the scope down, in plain language
Once there’s a shape, write it down — not as a legal artifact but as a shared understanding. The scope document I like is short and answers four questions in language the client would use:
- What will exist at the end? The concrete deliverable, described so plainly that anyone could tell whether it’s done.
- What does “good enough” mean? The bar the result has to clear to be trusted — and, just as important, what’s explicitly out of scope.
- What do I need from you? Access, data, a point of contact, decisions. Most stalls trace back to something the consultant needed and didn’t name up front.
- How will we know it worked? The observable outcome, agreed in advance, that tells both sides the engagement succeeded.
Writing this down does something quietly powerful: it converts a hopeful conversation into a mutual promise that both sides can actually keep.
Leave room for what you’ll learn
A scope is a hypothesis, and forward-deployed work always teaches you things that change it. So I try to scope firmly enough to be accountable and loosely enough to stay honest — naming the deliverable and the bar clearly, while being explicit that the path may shift as we learn. Clients, in my experience, deeply respect a consultant who says “here is what I’m committing to, and here is where I’ll come back to you if reality disagrees.” It’s the opposite of the contractor who silently does exactly what the ticket said and delivers something useless but technically complete.
The goal of scoping isn’t to predict the future perfectly. It’s to define a first win specific enough to deliver, valuable enough to matter, and honest enough to adjust — and then to go earn it. In the next essay I’ll take on the question that scoping always raises and that engineers find hardest: how to price work whose value has nothing to do with hours.