There’s a conversation I’ve had more times than I can count, and it usually goes something like this: An organisation wants to adopt a new tool. Someone has already done the research, maybe started a trial or two. There’s palpable enthusiasm - possibly a dedicated Slack channel. And somewhere in the middle of all that momentum, they ask me what I think.
My first question is always the same: what problem are you trying to solve?
Sadly, the conversation usually gets a lot quieter after that.
This isn’t a new dynamic. I’ve been working with product organisations on their tooling for years, and in that time I’ve watched the same pattern play out at companies of every size, maturity, and vertical. Most organisations treat tool adoption as a decision - do we buy this or don’t we? Completely ignoring that what should be a structured and nuanced evaluation has been reduced to a binary, thus bypassing all the questions that would tell you whether this is actually the right fit, for this team, for this org, at this moment.
Do this often enough and the result is an operating system that grows faster than anyone can manage, is maintained by nobody in particular, and was evaluated by nothing more rigorous than how enthusiastically it was onboarded.
A Hammer Without A Nail
Most tooling adoptions usually start with a legitimate problem. Teams are struggling to communicate priorities, or discovery is getting lost before it reaches development, or stakeholders keep asking questions that nobody can answer quickly. Something is genuinely broken. But instead of staying with that problem long enough to understand it properly, the conversation jumps almost immediately to solutions. We need a roadmapping tool. We need a research repository. We need a better way to manage our backlog.
From there, the evaluation rapidly becomes a feature comparison. Someone pulls together the top ten options. Demos get scheduled. A spreadsheet appears, mapping capabilities across vendors. And somewhere in the process of weighing integrations and pricing tiers and UI preferences, the original problem drifts to the back of the room. Nobody asked whether the real issue was cross-departmental visibility, or delivery credibility, or that sales didn’t have anything that would help them close deals. The problem was never communicated with enough specificity to be evaluated against - so the evaluation becomes about the tools themselves, as if you were buying a toaster.
And thus success, by the end of it, becomes about finding a tool, not solving the problem that prompted the search. And because success was never defined in any more concrete terms than that, there’s no basis on which to run a real trial, no exit criteria if things go wrong, nobody accountable for whether this actually changes anything. The tool then gets dropped into an existing operating system without anyone asking what happens before and after it - where information comes from, where it flows to, whether it creates new decision points or removes old ones. Instead, the final questions are always the same: what’s the price, how many licenses do we need, and how many features do we get?
Applying The Discipline You Already Have
The frustrating thing is that product people know how to do this correctly. They do it every day.
Before a feature gets built, there’s a problem statement. Before a solution gets committed to, there’s a hypothesis. Before it scales, there’s validation. Ownership is assigned, success is defined, and at some point someone asks whether it has been achieved. This is the discipline that separates good product organisations from reactive ones, and most product teams know what good looks like.
Then it’s time to buy a tool and none of it gets applied.
There’s no discovery phase for the problem the tool is supposed to solve. There’s no hypothesis, no trial with defined success criteria, no accountability for whether it changed anything. The same Product Leader who would push back hard on a feature request that lacks a clear problem statement will approve a tool purchase on the basis of a compelling demo and a favourable price per seat. The same organisation that treats “we’ll know it when we see it” as a red flag in a product brief will accept it as a perfectly reasonable measure of tooling success.
The result is an accountability vacuum. When nobody owns the evaluation, nobody owns the outcome either. And when nobody owns the outcome, there’s no mechanism to recognise failure - which means no mechanism to course-correct, retire what isn’t working, or learn anything ahead of next time.
Tools accumulate. Costs compound. The operating system becomes the thing that slows everyone down.
The Tool Adoption Canvas
I created this canvas because I was tired of seeing companies make the same mistakes over and over again - especially as AI tool adoption has added a whole new layer of urgency and volume to the problem. The canvas is a single-page document that brings that discipline you already have to tool adoption decisions. It’s the same questions good product teams already ask, just applied to a place they’ve been ignoring.
It’s available below in two versions - one fancy, one black and white - each with three templates: one with guiding questions to help you work through each section, one completed example so you can see what good looks like in practice, and a blank version for you to use as you see fit.
If the canvas slows down your tooling procurement process, good - it means it’s doing its job.
