The Tool Is the Easy Part.

This is the third in a series. The first, [*Problem First. Tools Second.*](/insights/problem-first-tools-second), was about starting with the problem and finding the one bottleneck worth attacking. The second, [*Should We Build It?*](/insights/should-we-build-it), was about deciding whether to build, commission, or buy the thing that solves it. Say you've done both. You've named the problem, chosen the tool, and it's sitting there ready. It feels like the finish line. It's the start line. A tool delivers nothing on its own. A person using it well delivers the value. The licence, the login, the clever bit of software — none of that moves your bottleneck by itself. It moves when someone picks the tool up, uses it for the right thing, and trusts the output enough to act on it. Which means the hardest part of the whole project isn't choosing the tool. It's the bit almost everyone underestimates: getting people to actually use it, and use it well. ## Where projects quietly die You can see the pattern from a distance. Licences bought. Logins issued. A launch email with an exclamation mark in it. And then, slowly, nothing. A fortnight later three people are using the tool, two of them badly, and within a quarter it's the thing nobody quite wants to admit was a waste of money. The instinct is to blame the tool. Usually the tool was fine. What was missing was everything that turns a tool into a habit — and that part isn't automatic, and it isn't free. Adoption is work. If you didn't plan for it, you didn't buy a solution. You bought a subscription and a vague sense of having done something about AI. ## A demo is not training The default plan, when there is one, is a one-hour walkthrough. Usually from the vendor. Everyone watches someone click through the features, nods, and goes back to their inbox. A demo shows people the buttons. It doesn't give them judgement, and judgement is what they're actually short of. People don't fail to adopt a tool because they can't find the menu. They fail because they don't know *when* to reach for it instead of doing the task the old way, they can't tell good output from confident nonsense, and nobody's shown them how it fits the work they actually do on a Tuesday. Teach the thinking, not the buttons. The buttons they'll find on their own. ## What upskilling actually means here Done properly, upskilling your team on a new tool covers a few different things, and the features are the smallest of them. - **A working mental model.** What the tool is genuinely good at, and where it falls over. With AI especially, people need to understand they're working with something closer to a very confident draft-writer than an oracle — fluent, fast, and capable of being completely wrong with total conviction. Get that straight and everything else makes sense. - **The practical skill of using it well.** For AI tools that mostly means how to ask: being clear, giving context, saying what good looks like. A vague request gets a vague answer, and most people's first instinct is a vague request. A simple, repeatable framework for this does more for adoption than any feature tour. - **Judgement and verification.** How to check output, spot where it's wrong, and treat what comes back as a draft to be edited rather than an answer to be pasted. This is also where the boundaries live — what's safe to put into the tool, what isn't, and where the confidentiality and data lines are. - **Fit with the real work.** Where in their actual day this helps, and where it doesn't. This loops straight back to the first article: you knew the problem, so you can show people exactly which task this is for, rather than leaving them to guess. ## Make it about their work, not a generic demo There's a moment in any decent session where people stop being polite and start leaning in. It's almost never during the abstract example. It's when they watch the tool do *their* job — their kind of document, their sort of query, in their language. That's when "this is interesting" becomes "I could use this on Thursday." So build the training around real tasks from real roles, not a tidy demonstration that works because it was chosen to work. Relevance is what drives adoption. People adopt things that visibly make their own week easier, and they quietly ignore everything else, no matter how impressive it looked in the launch email. ## Adoption is social, not solo People copy people. The fastest route to a tool being used across a team is rarely a mandate from the top; it's one or two enthusiastic colleagues who use it openly, share what worked, and make it normal. Give them room. Create somewhere to swap examples and ask daft questions without feeling daft. A shared sense that "this is just how we do this now" beats a policy document every time. What you're building here is a habit, not just a skill. Skill is whether someone *can* use the tool. Habit is whether they *do*, on the right tasks, without being reminded. The training starts the first; the social side finishes the second. ## Keep the capability in-house There's a longer game in all this. The aim isn't a team that depends on a consultant or a vendor every time something changes. It's a team that genuinely understands the tool and its limits and can carry it forward on its own. When the capability lives in your own people — when they can judge a new tool, train the next hire, and spot when something's drifted — that's the part that lasts long after the launch enthusiasm has worn off. A flashy system you depend on someone else to run is fragile. An ordinary team that actually knows what it's doing is not. ## Measure adoption, not activity Finally, watch the right number. Logins are not usage. Usage is not value. It's perfectly possible to have a team that all signed in once and changed nothing about how they work. Go back to the thing from the first article: you defined what "fixed" looked like before you bought anything. So measure that. Is the bottleneck moving? Are people using the tool for the job you got it for, and is that job demonstrably better, faster, or less painful than before? If yes, the upskilling worked. If everyone's logged in and nothing's changed, it didn't, and more features won't fix it. ## The thread, one more time Problem first. Then the right tool. Then the people who use it. At each step the bottleneck moves, and by now it has landed in the most human place of all — your team's confidence, judgement, and habits. That's not a problem to be solved with another purchase. It's a capability to be built, deliberately, in the people who'll still be there long after this particular tool has been replaced by the next one. ## Frequently asked questions **Why does AI adoption fail?** AI projects usually fail at adoption, not procurement. The tool is bought and a launch email goes out, but staff aren't upskilled, so usage fades within weeks. A vendor demo shows people the buttons; it doesn't give them the judgement to know when to use the tool and how to trust its output. **How do you upskill staff on AI?** Teach four things, not the features: a working mental model of what the tool is and isn't good at; the practical skill of asking well and giving context; judgement to verify output and respect data boundaries; and how it fits each person's real work. Build the training around their actual tasks, not a generic demo. **What should you measure to know if AI adoption worked?** Measure adoption and value, not activity. Logins are not usage and usage is not value. Go back to what you defined as "fixed" before buying the tool and check whether the original bottleneck has actually moved and the target task is genuinely better, faster or less painful. *At Smart AI Studio we spend most of our time on this part — not the tools, the people. Our workshops and training are built around your team's actual work, aimed at real adoption rather than a tour of features, and designed to leave the capability with you. If you'd like to talk through what upskilling your team would actually involve, Peter Lowe runs sessions built around exactly that. A working session, not a sales pitch.*