Your team already ran the pilot

Look at how people sign up for a new work tool and a pattern turns up quickly. A lot of them arrive with a personal account rather than a corporate one, and they don’t go through procurement first. They use a Gmail address, from home, late on a weeknight.

The easy reading is curiosity, and sometimes that’s all it is. The more useful reading is caution.

The arithmetic of asking

Getting your company to adopt something costs you more than it costs the company. You have to make the case to a manager, or to IT, or to whoever owns the security questionnaire. Somebody has to spend a week on review. And afterwards you are the person who brought it in. Being that person is great when the tool becomes something the team can’t work without, and it damages your reputation when it quietly goes unused, more so every time it happens again.

Most people can do that two or three times a year before they become the colleague who chases whatever is new. So they guard that credit, and won’t spend it unless they’re fairly confident the tool will deliver.

That is why the trial happens first, quietly, on a personal account, on personal time, with data that does not require anyone’s approval. Not because they want a personal tool. Because they want to know whether the thing works before they put their name on it.

That is a pilot

It has no budget, no steering committee and no written exit criteria. It also has something most formal pilots never get: a participant with a genuine reason to find out the truth.

Think about who usually runs an evaluation inside a company. Often it is the person who suggested the tool, which means they are now motivated, quietly and honestly, to have been right. Someone testing on their own account has no such stake. Nobody knows they’re kicking the tires, so there’s no decision to defend. They’ll drop it in a week if it doesn’t help and never mention it.

So the question in front of most leaders is not whether their company should try AI. Their company tried it, months ago, in a dozen places at once. The question is whether anyone has asked how it went.

What the solo trial is good for

It is a filter, and a good one. Most software does not survive two weeks of honest personal use. If a tool is slow, or wrong often enough to need checking, or simply does not fit how you work, you find out on your own time at no cost to anyone. That is a real service, and it is the cheapest evaluation available.

What it cannot tell you is whether the thing would change how your team works. On a personal account you can see whether a tool drafts a decent reply, summarizes a thread, or saves you twenty minutes. You cannot see work reaching the person who owns that area, a task landing with the right owner and staying visible until it is done, or something one person figured out being there when a colleague needs it six weeks later.

Those are different questions, and the mistake is expecting one trial to answer both. “Is this any good?” and “would this change anything here?” need different conditions, and only the first one can be answered alone.

The step almost nobody takes

Having answered the first question, some people jump straight to the expensive move: make the case, involve IT, become the champion. But because that step is costly, plenty of them never take it, and the tool quietly dies on a personal account having passed its only test.

There is, however, a cheap step in between, and it costs almost nothing. Run it with two or three colleagues on the work you actually share.

It’s inexpensive, maybe even free. It might need someone to approve it, or IT to unlock access, but not a procurement cycle, a full security review, or your reputation staked on it in front of anyone beyond a couple of people you already talk to daily. And it is the first time the team-shaped parts of a tool become visible at all, because you need more than one person in a system before routing, ownership and shared knowledge mean anything.

Three people for a fortnight will tell you more than one person for a quarter. If it works, you now have a case built on evidence and two colleagues who will back it, which leads to a completely different conversation from arriving alone with an enthusiasm. If it doesn’t, the experiment was inexpensive and you’re certain.

Three questions worth asking

If the pilot already ran, the cheapest thing available to a leader is the debrief. It costs one conversation.

What are you already using, and for what? Ask it as a question rather than an audit. The answers stop coming the moment this feels like enforcement, and the goal is to learn what your team has figured out, not to catch anyone.

What did you try and abandon? More informative than what stuck. People abandon things for specific reasons, and those reasons are a free evaluation of half the market.

What did you not try, because it would have meant asking permission? This is the one that matters, and almost nobody asks it. The answer is a list of tools that might have changed how the work happens, screened out by the cost of asking rather than by anything about the tools.

this+that’s role in the evaluation

We build a team-oriented product, so we have a stake in the argument and you should weigh it accordingly.

Used alone, this+that does real work: it reads the messages coming into the channels you already use, pulls out the tasks and commitments buried in them, and keeps them somewhere you can see. That part holds up fine on a personal account.

But the reason to adopt it is the part a single account cannot demonstrate. Work reaching the person who owns it. A shared task list that survives someone being on holiday. Knowledge one person wrote down being there for everyone else. If you tried us alone and concluded we were a slightly better inbox, that is a fair reading of the evidence you had. It is also the wrong evidence for a team decision.

So our ask is the small one, not the big one. Try it yourself first. If it holds up, make the case for a short pilot with two or three colleagues, sharing real work for a fortnight. That may still mean asking someone, and it may mean IT unlocking access, but it is a far smaller thing to ask for than company-wide adoption.

That is the general point rather than a special plea. The tools most likely to be underrated by a personal-account trial are the ones whose value shows up between people, and the fix is not a better solo trial. It is a second, slightly less solo one.

Key takeaways

• People evaluate new work tools on personal accounts because asking a company to adopt something spends personal credibility, and most people can only spend it two or three times a year.
• That informal trial is a genuine pilot, and in one respect a better one than most formal evaluations. The person running it wants the tool to work, but has no reputation riding on the verdict.
• Most companies have therefore already run an AI pilot, months ago, across a dozen people at once. Many aren’t even aware of it, and very few have asked what it produced.
• A solo trial answers “is this any good?” cheaply and well. It cannot answer “would this change how we work?”, because routing, shared ownership and shared knowledge need more than one person before they mean anything.
• The step between the two costs almost nothing and almost nobody takes it: run the tool with two or three colleagues on work you actually share. It may need an approval or IT unlocking access, but it is a far smaller ask than company-wide adoption.
• Three people for a fortnight beats one person for a quarter, and it turns an enthusiasm into evidence plus two colleagues who will back you.
• For leaders, the debrief costs one conversation. Ask what people are already using, which is how you find out the pilot happened at all, and then ask what they didn’t try because it would have meant asking permission.