A bad problem statement is the most expensive thing in the room. It looks like work, it generates a roadmap, it survives the kickoff — and six weeks later the team has shipped a polished answer to the wrong question.
Naming the problem correctly is not a nicety we do on day one and forget. It is the engagement. Everything downstream — scope, success criteria, what we count as a receipt, when we stop — descends from the sentence we write at intake (Class C).
The default failure mode
Most intakes arrive as a solution wearing a problem's clothes. "We need a chatbot." "We need to add AI to the help desk." "We need an agent that does X." Each is an answer. None of them tells us what is broken, for whom, or what "fixed" would look like on a Tuesday.
When we accept a solution-shaped intake without rewriting it, three things happen:
- The success criterion silently becomes "ship the thing" instead of "the underlying pain measurably drops."
- The scope expands as the team discovers the real problem mid-build, with no budget for it.
- At week six the artifact works exactly as specified and nobody is happier.
We will not start a workshop on a solution-shaped intake. We rewrite first, together.
What a load-bearing problem statement contains
A problem statement is engagement-ready when it names four things in one breath: the person experiencing the pain, the observable behavior of the pain, the cost of the pain in units the business already tracks, and the falsifier — what would have to be true for us to say the problem is solved.
That last piece is the one most intakes are missing. A problem you cannot disconfirm is a problem you cannot finish. If "we need to do better at support" has no number, no comparison, no before/after we agreed to in writing, the engagement has no natural endpoint and the retainer renews forever. We do not work that way.
Three real intake rewrites
These are real, lightly anonymized.
Intake one — before: "We want an AI agent to handle tier-one support tickets." Rewrite: "Our four tier-one agents spend roughly 60% of their week on six recurring ticket shapes; the per-ticket handle time on those six has not moved in eighteen months and is the bottleneck on our SLA. If we can cut median handle time on those six shapes by a third without raising the misroute rate, the bottleneck moves elsewhere and we win back roughly one full-time equivalent."
The rewrite names the people (four agents), the behavior (six recurring shapes, handle time), the cost (one FTE, SLA pressure), and the falsifier (one-third median reduction without raising misroutes). Now we know what to build and, more importantly, when to stop.
Intake two — before: "We need to add AI to our sales process." Rewrite: "Our reps draft follow-up emails by hand after every discovery call; the median lag from call to follow-up is eleven hours, deals where the lag exceeds eight hours close 22% less often, and we have a year of paired call transcripts and outcomes. If we can land a reviewed first-draft in a rep's outbox within ninety minutes of call-end at the same close rate as their hand-drafted version, we have moved the lag."
Same pattern. Person, behavior, cost, falsifier. The workshop now has a target.
Intake three — before: "We want a knowledge base agent for our engineers." Rewrite: "Our twelve engineers ask the same fourteen architecture questions every onboarding; the answers live in three places and disagree in two of them. We are not asking for an agent yet — we are asking for the disagreements to be surfaced and reconciled, so that whatever we build later has a single source of truth to read from."
This one is important because the rewrite changed the engagement type. The honest answer to "we want an agent" turned out to be "you do not yet have the substrate an agent would need." We do not get to that answer without rewriting the intake.
Why focus is the upstream variable
A useful outside read on this point: a Themesis piece splits AI work into three career tiers — tradesperson, engineer, innovator — and treats focus as the load-bearing skill at every tier (Themesis, 2025). Same constraint we hit at intake: a fuzzy problem statement is a focus failure dressed up as a scoping problem (Class E). The person in the room cannot do their best work until they know which question they are answering. Neither can we.
We use the tier idea to calibrate the engagement: a tradesperson-tier problem deserves a tradesperson-tier workshop, and we say so when an intake is asking for innovator-tier work on a tradesperson-tier budget.
What we ask you to bring
Bring the messy version of the problem statement. We will rewrite it with you, in the open, before any scope is signed. If the rewrite shrinks the engagement, the engagement shrinks. If the rewrite reveals the substrate is not ready, we say so. The intake itself is a receipt.
- The Workshop-Readiness Buyer's Guide — what to bring, what to expect, what we refuse.
- Are You Ready For The Workshop? — a short self-check before you book.
- Book the workshop — when the problem statement is sharp enough to commit to.