Problem framing & scope
Job-To-Be-Done, user needs, and scope-creep kills.
Job-To-Be-Done, not "use AI for X"
If you have a product management background, most of this lesson will feel familiar. We are deliberately borrowing the Jobs-To-Be-Done framing rather than inventing something new for agents — the same discovery muscles that keep a feature launch from shipping the wrong thing are what keep an agent project from shipping a capable-but-pointless one.
The bigger claim: discovery work is where an agent project is won or lost. The model, the tools, the orchestration — all of it can be rebuilt. A mis-framed job cannot be salvaged by engineering. Spend proportionate time here, the way you would for a greenfield product feature: user interviews, outcome statements, timeline-of-struggle analysis, watching someone do the current workaround. The agent gets built against the evidence you gather, not against the stakeholder pitch that kicked it off.
Agents get deployed against real user jobs, not against technologies. Write the Purpose cell of the Agent Canvas as a JTBD statement:
As a [user role], I need to [outcome], so that [higher-level outcome].
Two worked examples.
As a senior leader, I need to arrive at Monday morning knowing what needs my attention, which meetings need prep, and what's urgent — so that I start the week in control, not catching up.
As a customer-support lead, I need to triage Tier-1 tickets against our help centre and draft a reply for human approval — so that agents focus on Tier-2+ and first-response times drop.
Notice that both include the so that — the outcome beyond the task. This is what you optimise for, not the task itself.
The "NOT for" list
Equally important: write down what the agent is explicitly NOT for.
- NOT for: making decisions, sending emails without my approval, accessing HR data, acting on my behalf.
The NOT list prevents scope creep. Every time a stakeholder suggests a new capability, you check it against the list. If it conflicts, you either refuse or update the canvas and redo the governance review.
User needs vs capability
A common failure mode: teams start from the model's capability ("it can do X") rather than the user's need ("they need Y done"). The result is a technology demo, not a product. JTBD orientation flips this.
Scope creep kills agent projects
Three common ways scope creeps in, and how to catch them:
- "While we're at it" — someone adds a new trigger or tool during planning. Update the canvas and re-rate the risk. Never add silently.
- Exemption-by-default — the agent handles "everything that isn't X". This inverts the canvas. Scope should be affirmative: the agent handles these X cases; everything else is handed off.
- Skill inflation — the agent is asked to do a thing adjacent to its purpose. Usually this means you should build a second agent, not expand the first.
What this gets you
If your Purpose cell is good, the next four canvas cells (Triggers, Tools, Knowledge, Authority) almost write themselves. If you cannot write them, you cannot fill the Purpose cell yet.