AI strategy02
An AI pilot needs an exit, not just a launch.
How to design a small AI trial with an owner, a comparison, review criteria and a clear decision at the end.
The journal / AI strategy / Note 01
AI strategy · Field note 01Before you buy another AI tool, map one day of work.
A tool can look impressive in a demonstration and still have no obvious place in your business. A better starting point is an ordinary working day.
Start with something that actually happened
Ask someone to walk you through a task they completed yesterday. An enquiry became a draft response. A meeting became a list of actions. A set of notes became a proposal. Choose something concrete enough that you can see where it began and where it ended.
Write down each handoff. Who supplied the information? Where did it live? Which parts required interpretation? Where did someone wait? This is a modest exercise, but it gives the conversation a shape that a list of software features cannot.
Separate the work from the friction
Imagine a small team preparing a weekly project update. The visible task is writing. The real friction may be finding the latest decisions, reconciling conflicting notes, or waiting for someone to confirm a date. This is an illustrative example, not a client case.
An AI writing assistant might make the final paragraph faster to produce. It will not automatically resolve missing ownership or an unreliable source document. Label each problem as missing information, unclear decision, repetitive transformation, or avoidable waiting. You may discover that the first improvement is a simpler process.
Choose a bounded experiment
A useful first trial has a clear input, a specific output, and a person who can judge the result. “Help us communicate better” is too loose. “Turn these approved, non-sensitive project notes into a draft update for a project manager to review” is something you can test.
Define the boundary before choosing a product. Which information is allowed? Which claims need checking? Who approves the draft? What should happen when a note is ambiguous? These questions are part of the design, rather than details to resolve after a rollout.
Measure the whole task
Record how long the current task takes, including preparation and checking. In the trial, count the time spent preparing inputs, generating output, correcting it, and getting approval. A fast first draft can still create a slow finished result.
Compare output quality as well as time. Keep a short record of omitted actions, incorrect details, and revisions. If the trial makes one stage quicker but pushes extra work downstream, that is useful evidence. The aim is to improve the task, not merely to demonstrate that a tool can produce something.
Leave with a decision
At the end of the trial, choose one of three outcomes: continue, change the scope, or stop. Give each a reason that someone outside the experiment can understand. A small trial is valuable when it makes the next decision easier, including the decision to leave a process alone.
One ordinary task, carefully observed, can tell you more than an afternoon spent comparing feature lists. Start close to the work. The tool choice will have a better foundation.
One thing to take away
Pick one recurring task. Map its inputs, handoffs and review. Set a baseline before testing a tool.
Pasqualino Mazza
Entrepreneur, global AI consultant, and content creator. Writing about AI, business, and leadership from a Toronto perspective.