I still believe in moving early on AI. I am less interested in the announcement than in what the team can do differently afterward.
A license, a workshop, or a promising pilot is a beginning. None of those tells me whether a process improved, whether someone uses the result, or whether the organization can maintain it.
My work connects research and development to that less glamorous part: the operating habit.
Start with work that already matters
My starting questions are business questions. Where is time being lost? What slows a customer response? Which recurring handoff depends on someone remembering to chase it? What information already exists but never reaches the person who needs it?
The opportunity might call for an agent. It might call for a custom application or an ordinary automation. I do not need a model in every step to consider the work successful.
That judgment matters more than adopting the newest interface quickly.
Build capability, not dependence
My internal implementation work includes coaching 19 marketers and six executives, and tools reaching more than 250 sales reps. Those are the figures recorded in my portfolio. The point is not that every person became a developer. It is that useful implementation includes people, not only software.
A person should understand what a workflow does, where its information comes from, what needs review, and how to recover when it fails. Otherwise the organization has exchanged one bottleneck for another.
Reusable skills and working methods are part of that handoff. So are plain-language explanations and sensible limits.
Tie the claim to its scope
Across my internal work, the portfolio records recurring savings from replacing agency work and software subscriptions. It also records a $20,000-plus sales opportunity surfaced by a scheduling application.
These are different kinds of outcomes. Recurring savings are not revenue. An opportunity is not a closed sale. Reaching users is not proof that every user engages equally.
Keeping those distinctions intact makes the case stronger, not smaller. A business should be able to understand exactly what changed.
What I would measure next
For a new implementation, I would establish the baseline before the rollout: task completion time, exceptions, rework, adoption, and the relevant commercial outcome. Then I would compare the new workflow with the old one and examine where the improvement actually came from.
I also want to know whether the team keeps using it after the initial attention wears off. A process that works only while its builder is standing next to it is not finished.
Move early. Stay accountable.
The reason to start is to learn through real work. The reason to keep evaluating is to avoid mistaking activity for progress.
That is the version of early adoption I care about: more useful capability inside the business, fewer unnecessary steps, and people who understand the system well enough to improve it.
Revision note: Updated September 20, 2026 to focus on implementation and distinguish adoption, savings, and sales opportunities. The original May 14 publication date is preserved. Reported outcomes come from my portfolio’s documented work; they are not a forecast for another organization.