Every strategist hits this wall eventually. A client comes in excited, budget approved, timeline sketched on a napkin — and when you ask what success looks like, you get a shrug and a vague gesture toward "growth." I've been there more times than I can count, and I've learned that undefined scope isn't a project killer. It's a design challenge.
Here's how I've navigated it, what frameworks I lean on, and why some of my most satisfying client outcomes started from almost nothing defined.
Why Scope Ambiguity Happens (And Why It's Not Always the Client's Fault)
Before blaming the client for vague briefs, I had to accept something uncomfortable: ambiguity often lives on both sides of the table. Clients frequently don't know what they need because they haven't been asked the right questions yet. Early in my career, I'd rush to proposals and timelines before doing the diagnostic work. That was my mistake.
The truth is, undefined scope usually signals one of three things:
- The client is solving a symptom, not a root problem
- Internal stakeholders haven't aligned on priorities
- The project is genuinely exploratory — and that's legitimate
Recognizing which situation you're in changes everything about how you respond.
Step One: Run a Structured Discovery Before You Quote Anything
My first rule is non-negotiable: never write a scope document off a single briefing call. I always run a structured discovery phase, even if it's just two or three focused sessions. I call it a "clarity sprint," and at Helion 360 it's often a paid engagement in itself.
In these sessions I'm not just gathering information — I'm watching how the client talks about their business. What language do they use? What problems do they mention twice? Where do they hesitate? These behavioral cues tell me more than any intake form.
The questions I come back to most:
- What does this project need to make true that isn't true today?
- Who inside your organization will be disappointed if this succeeds in the wrong way?
- What have you already tried, and what made it fall short?
- If we delivered everything perfectly, how would your customers experience that differently?
That last question especially tends to unlock real business goals hiding behind feature requests.
Step Two: Build a Hypothesis-Driven Scope
Once I have enough signal, I don't wait for perfect clarity to write a scope. I write a hypothesis-driven scope — a document that frames deliverables as bets rather than promises.
This looks something like: "Based on what we've heard, we believe the highest-value work here is X. We'll validate that assumption in Phase 1 and adjust before committing resources to Phase 2."
This approach does three things. It shows the client I've listened. It gives both parties an honest framework for decision-making. And it protects the project from scope creep disguised as "just one more thing" — because everything gets evaluated against the stated hypothesis.
I also use this document to surface stakeholder disagreement early. If two executives read the same hypothesis scope and react differently, that tension needs to be resolved before work begins, not discovered mid-sprint.
Step Three: Anchor Every Decision to a Defined Output, Not an Activity
One of the biggest traps in vague projects is scoping by activity instead of output. "We'll run workshops, conduct interviews, and develop recommendations" sounds thorough, but it tells the client nothing about what they'll have in their hands at the end.
I shifted my language to outputs years ago. Instead of "stakeholder interviews," I deliver "a prioritized problem map with three validated user needs." Instead of "brand exploration," I deliver "two strategic directions with rationale and a recommended path forward."
This shift matters because it gives clients something concrete to approve or redirect — and it gives me a natural checkpoint to reassess scope if the outputs reveal something unexpected. In undefined projects, they often do.
Step Four: Use Phased Commitments to Reduce Risk on Both Sides
I rarely propose a full engagement upfront when scope is unclear. Instead, I structure projects in phases with explicit go/no-go decisions built in. Phase 1 is always about learning and validation. Phase 2 is execution based on what Phase 1 surfaces.
Clients sometimes push back on this — they want a single quote and a finish line. I address this directly: "I can give you a number, but without validation it's likely to be wrong in ways that cost us both. A phased approach means you're never funding work based on assumptions we haven't tested."
Framed that way, most clients come around. And the ones who don't are often telling me something important about how they'll behave as the project evolves.
What Delivering "Clear Results" Actually Means
Here's what I've learned about results in ambiguous projects: clarity is something you create, not something you find. By the time a project closes, I want the client to be able to answer three questions without hesitation:
- What did we set out to solve?
- What did we actually do, and why?
- What is measurably different now?
That last point is where a lot of practitioners drop the ball. They deliver the work and move on without helping the client connect output to outcome. I build a "results narrative" into every project close — a short document that maps deliverables to business impact and identifies the next logical question to ask. It's not a vanity report. It's a strategic handoff.
The Mindset Shift That Made Everything Easier
The real unlock for me wasn't a framework or a template. It was accepting that my job in an undefined project is to be the person who creates structure, not the person who waits for it. Clients aren't hiring me to execute a plan they've already figured out. They're hiring me because they haven't figured it out yet.
That reframe changed how I walked into ambiguous rooms. Instead of anxiety, I bring process. Instead of frustration, I bring curiosity. And almost without exception, the projects that started most vague ended with the clients most clear about where they're going next.
If you're a consultant, strategist, or agency lead reading this — embrace the undefined brief. It's where the most interesting work lives.