If you buy a new toy first, you'll look for ways to play with it. If you look at your day first, you'll find the toy you actually need.
Most AI projects start with a tool and look for uses. I start with what a team actually does and the choices they make, because that's where the time, cost and risk sit. The tool comes later, chosen for a specific decision.
Work-first sequencing (work, decisions, capabilities, risk, cost, roadmap) keeps investment tied to measurable decisions. Tool-first adoption optimises for feature coverage and usage metrics, which correlate weakly with value. The decision inventory is the bridge between the two.
The order of this site
The sections on this site follow an order on purpose. Work comes first: what people actually do. Then Decisions: the choices inside that work. Then Capabilities: what the tools can do. Then Risk and Cost. Then the Roadmap.
I learn by explaining things, and this order is the one that makes the explanation hold together. Each section depends on the one before. You can't judge a risk without knowing which decision it affects, and you can't judge a decision without knowing the work it sits in.
What happens the other way round
The common path runs in reverse. An organisation buys licences for a new tool, runs a launch, and then measures how many people use it. Usage goes up, then levels off. Someone asks what the organisation got for the money, and nobody can say, because nobody decided at the start what the tool was supposed to change.
The tools aren't at fault here. The question "what's this for?" simply got answered after the purchase.
What starting with the work gives you
Three things, in my view.
A short list of places that matter. When you map the work, then the decisions, you'll often find that a handful of decisions account for most of the time or risk. Those are the places worth changing.
A baseline. If you know a team spends 30 hours a month on a decision before anything changes, you can say whether a tool saved time afterwards. Without the baseline, you're left with surveys about how people feel.
A shared language. Once there's a decision inventory, conversations about tools, risk and budget can point at the same rows. The risk owner, the budget holder and the person who wants the tool can see they're talking about the same thing.
A worked example
This example is illustrative. Two teams in the same organisation get 20 Copilot licences each.
| Team A: tool first | Team B: work first | |
|---|---|---|
| First step | Training on Copilot features | Two days listing tasks and decisions |
| What they pick | Whatever people try | Three decisions that take 40 hours a month between them |
| What they measure | Weekly active users | Hours on those three decisions, before and after |
| After three months | 15 of 20 people active; value unclear | 12 of 20 active; hours on the three decisions down by a quarter |
Team A's usage is higher. Team B can say what changed and argue for the next step. The numbers are made up, but the shape is the point: active users and value are different measures.
When tool first is fine
I don't think every tool needs this treatment. If something is cheap, reversible and low-risk, trying it first and learning is a perfectly good approach. Copilot Chat, which is included with many Microsoft 365 plans, is a reasonable thing to let people explore. The work-first approach matters most when money, risk or people's jobs are involved.
Where I got stuck
The work-first approach takes time before anything visible happens, and that's hard to defend when there's pressure to show progress. My best answer so far is to keep the first round small: one role, two days, ten decisions. That's enough to choose well without stalling.
Sources
This article explains the structure of this site and my own approach. It uses no external facts or figures beyond the note that Copilot Chat is included with eligible Microsoft 365 plans, from Microsoft Learn, Overview of Microsoft Copilot Chat, accessed 11 October 2026. The team comparison is illustrative.