
Most AI initiatives I see start with a tool. A vendor demo impresses someone, a competitor announces an agent, or a board member asks why the company isn't using the latest model. Within weeks there's a licence, a pilot and a Slack channel.
What there usually isn't is a clear picture of the work the tool is supposed to improve.
That ordering is backwards. AI creates value when it improves how work happens, not when another tool joins the stack. If you haven't designed the work first, you're asking the tool to fix a problem nobody has defined.
Why tool-first fails
When you start with the tool, the question becomes "where can we use this?" That sounds reasonable, but it leads teams to hunt for tasks that fit the tool's strengths rather than the business's needs. You get impressive demos in low-value corners of the organization. The workflows that matter stay untouched.
It also hides the real constraint. Many processes are slow not because a step takes too long, but because of handoffs, approvals, missing information or unclear decisions. Automating one step in a broken flow just moves the queue somewhere else. Teams that generate work faster often discover their actual bottleneck was always review.
And it locks you in early. Once a tool is bought and announced, the pressure is to prove it was the right choice. The work gets bent to fit the tool, not the other way around.
What designing the work actually means
Designing the work isn't a six-month consulting exercise. It's answering a few questions honestly before anyone signs a contract.
What outcome are we trying to change? Name it in business terms, such as faster onboarding, fewer errors or shorter sales cycles. "Use more AI" is not an outcome.
How does the work happen today? Map it end to end, including the informal parts: the spreadsheet someone maintains, the exception everyone knows about, and the person who always gets called when something breaks. If nobody can explain the process from start to finish, that's your first finding.
Where is the real constraint? Look for where work waits, not just where it's done. Waiting time is usually where the value hides.
What does good look like? Agree on quality criteria and real examples before you automate anything. Without them you can't test the tool, and you can't tell whether it's working.
Who decides, and who owns it? Clarify which decisions stay with people, which can be delegated, and who is accountable for the result once the new way of working is live.
Only then does the tool question make sense. Often the answer is a simpler tool than the one in the demo. Sometimes it's no new tool at all, just a redesigned process that removes steps.
Intent comes first
Underneath all of this is a principle I keep returning to in my work with founders and product teams: tools execute intent, they don't create it. A person can sometimes compensate for vague direction. An AI system can't. It will do exactly what the design allows, at speed and at scale.
So the quality of your AI outcomes is capped by the clarity of your work design. Get the outcome, the flow, the definitions and the ownership right, and almost any capable tool will perform. Get them wrong, and the best tool on the market will simply help you do the wrong thing faster.
The practical test
Before your next AI purchase, try writing one page. Describe the workflow you want to change, the outcome you expect, where the constraint is, and who owns the result. If you can write that page, you're ready to choose a tool. If you can't, the page is the work.
