Late October on the South Shore has a particular color to
it. Drive past one of the bogs this time of year and the harvest may be
underway, with the bog flooded and the surface covered in red berries pushed
into long, curving rafts. It's one of those sights people come from elsewhere
to photograph. Those of us who live here pass it on the way to a client meeting
and barely look up.
The cranberry business is so much a part of this landscape
that it's easy to forget it had to start somewhere. Wampanoag people harvested
wild cranberries in southeastern Massachusetts for thousands of years before
any European arrived. But the idea of growing them, cultivating them on
purpose, came later and from a surprisingly ordinary place. According to the
industry's own history, commercial cultivation began in 1816 with Captain Henry
Hall, a Revolutionary War veteran in Dennis. He noticed that the wild vines on
his land did better where sand had blown over them.
That's the whole insight. There was no new invention and no
outside expert. Hall paid attention to something the wind had been doing on his
land for years, saw that the result was better where it happened, and started
doing it on purpose. He transplanted vines and spread sand over them. His
neighbors weren't impressed at first, and he was criticized for tinkering with
the vines. Then other growers tried his method, and it caught on. Over the rest
of the century, landowners across the region converted swamps, wetlands, and
wet meadows into bogs. By 1885, Plymouth County had more than 1,300 acres under
cultivation, and by 1900 the acreage had roughly tripled.
I keep coming back to the order in which that happened. The
observation came first, then the deliberate practice. Expansion came last,
after the practice had shown it worked. Nobody converted a swamp because
sanding sounded promising. They converted swamps because a man in Dennis had
looked closely at his own work, changed one thing, and could show what
happened.
I've been thinking about that sequence because I suspect
most businesses are being encouraged to run it in reverse.
The conversation about artificial intelligence usually
starts with the tool. Someone shows you a meeting summarized in seconds, or a
proposal assembled from a page of rough notes. A long email thread gets
condensed into a tidy paragraph, and a report that normally takes an afternoon
appears before your coffee has cooled. The demonstrations are genuinely
impressive, and they lead almost automatically to one question: Where can we
use this?
It's a reasonable question. I just don't think it's the
right first one. It puts the expansion before the observation. It asks you to
convert the swamp before anyone has looked carefully at the vines.
A more useful starting point is quieter and more local.
Where in your business have you already noticed that the work takes more effort
than the result seems to justify?
Almost every owner I know can answer that without much
thought, because the evidence is all around them. A meeting ends and someone
has to turn forty-five minutes of conversation into a follow-up that captures
what was decided. A customer calls with a question, and the answer is somewhere
in six months of email between three people, one of whom has left the company.
A proposal has to be built from notes in a notebook, a shared document, and
someone's memory. An internal procedure has changed three times since anyone
updated the document that describes it, so new employees learn it by asking
whoever is nearby.
None of this is hard work, and that's part of the problem.
Each task is too small to become a priority on its own. Nobody puts
"reduce the time we spend reconstructing email threads" on a
strategic plan, and nobody holds a planning session about the twenty minutes
after every meeting. So we put up with it. The minutes go to the work that sits
between the work, and they add up to a surprising share of the week. They also
compete with the things that actually need us: serving customers, supporting
the people who work for us, and making the decisions nobody else can make.
That's where AI is genuinely interesting to me. It isn't
because it promises to make this friction disappear, which is a promise I'd
treat with caution. It's because trying to use it well forces us to look again
at work we stopped seeing a long time ago.
Take the most ordinary example I can think of: the follow-up
after a routine project meeting.
When the meeting ends, someone has notes, or perhaps a
transcript. Their job is to work out what was decided, what's still open, who
agreed to do what, and by when. Then they have to write it up clearly enough
that nobody leaves with a different version of what just happened. It's hardly
cutting-edge, and that's exactly why it's a good place to start. You know what
goes in and roughly what should come out. Most importantly, you have someone
who was in the room and can read the result and know almost immediately whether
it's right.
Give that job to an approved AI tool, and a clean, confident
draft may appear in under a minute. It's tempting to stop there and call it a
success. The real experiment starts after the draft appears, because the work
isn't finished when the words exist. It's finished when an accurate follow-up
has gone out.
Sometimes the draft is excellent. The reviewer changes a
phrase or two, hits send, and twenty minutes of routine work becomes five.
That's a real gain.
Sometimes it isn't. The draft gives an action item to the
wrong person. Or it takes something the group floated as a possibility, the
"we should probably look into that" kind of remark, and writes it up
as a commitment. Or it leaves out the concern someone raised quietly near the
end, which everyone in the room understood was the real issue. When that
happens, the reviewer has to slow down and check every line. Polished prose
doesn't announce its mistakes. A rough draft looks like it needs work, while a
smooth one looks finished, and that's exactly what makes its errors easy to
miss.
So the number that matters isn't how fast the draft
appeared. It's how long it took to get something accurate out the door, whether
decisions came out clearer, and whether fewer action items slipped through.
It's whether the person who used to write these follow-ups got back to client
work sooner, or whether the business simply moved twenty minutes from writing
to checking and called it progress.
That question is easy to skip, because watching the words
appear feels like proof. But there's a gap between what we can see happening
and what's actually happening to the work, and that gap is where most of the
honest evaluation lives.
There's another reason a familiar task makes a good first
experiment, and it's the one I find most interesting.
Every business has people who can do certain work remarkably
quickly. That isn't because the work is simple. It's because they've built up
thousands of small judgments about it over time. They know which client needs
things spelled out and which one finds that patronizing. They know a sentence
in a proposal can sound harmless and still create an expectation nobody wants
to own six months later. They know when "we talked about it" means
"we decided it" and when it very much doesn't. They notice a number
that looks wrong before they can say why.
Almost none of that is written down. Ask them how they do
the work and the honest answer is often some version of I just know what to
look for. Hall, I suspect, would have said something similar about his
vines. Being able to see the difference is itself the skill.
When you bring AI into a familiar process, that hidden
judgment starts to show. The tool produces a draft. Someone experienced reads
it and says, "No, that's not quite right." Suddenly you have a
question in front of you that the business may never have asked out loud: Why
isn't it right?
The answers vary, and each is useful in its own way. Maybe
the tool needed better instructions, or it was missing a piece of information
that lives only in someone's head. Maybe nobody has ever agreed on what a good
result looks like, and two experienced people would have written the follow-up
two different ways. Maybe the task turns out to need far more judgment than
anyone gave it credit for, and it should stay exactly where it is. Or maybe
half of what your most experienced person does in that task really is
mechanical, and there's no good reason their attention should keep going to it.
In every one of those cases, you know your own business
better than you did before the experiment. You can't get that from a list of AI
capabilities, however long the list. You can only get it by looking closely at
a piece of your own work, the way you'd look at a patch of vines.
This is why I'd encourage you to make your first AI project
a fairly modest one.
Don't start with your pricing strategy, or the hardest
judgment call your most senior person makes, or the ambitious automation tying
five systems together that someone sketched on a whiteboard. Start with
something that happens often, follows a reasonably consistent pattern, and
produces a result someone qualified can check. Ideally, it's a task your team
would be quietly glad to spend less time on.
Then ask a handful of plain questions before anyone opens a
tool. What exactly is the task? What does a good finished version look like?
What information would the tool need, and is that information appropriate to
put there? Who can review the result and take responsibility for it? How will
you tell whether the work actually got better, counting the time spent checking
and correcting?
These questions are less exciting than choosing a platform
or watching a demonstration, and I think that's a good sign. New technology
tends to make us want to rush past the dull questions to get to the interesting
part. But the dull questions are usually where the real work of running a
business gets done. They're also where an experiment starts to produce
something you can trust.
The answers won't always be flattering. You may find that
the follow-up email saves fifteen minutes a meeting, and that's a modest, real
gain worth keeping. You may find the task shouldn't involve AI at all, because
checking the output takes as long as doing the work. Or you may find the task
was never the problem. The real friction was in the process around it: the
unclear ownership, the decision nobody wrote down, the information spread
across five places. All three are good outcomes, because each one is grounded
in something you actually saw rather than something you were promised.
There's one more part of Hall's story I find instructive.
When he started spreading sand on his vines, his neighbors thought he was
meddling with something best left alone. They came around because the results
were there to see, not because he argued them into it. The idea spread one bog
at a time, as other growers tried it on their own land and watched what
happened. The rapid growth came at the end of that process, not the beginning.
I think AI will reach most small businesses in much the same
way. There will be the occasional dramatic transformation, but more often it
will happen one task at a time. Someone will notice that a piece of work takes
more than it should, try something on purpose, and look honestly at the result.
Some of those experiments will be worth repeating and some won't. The
businesses that come out ahead probably won't be the ones that adopted the most
tools the fastest. They'll be the ones that paid the closest attention to their
own work while they were adopting them.
The goal was never to put AI into your business as quickly
as possible. It's to understand your business a little better, remove some
friction nobody needed, and make a bit more room for the work that deserves
your attention: the client conversation that shouldn't be rushed, the employee
who needs an hour of real coaching, the decision you've been too busy to think
through properly.
That room is worth more than any single tool. And as Hall's
neighbors eventually saw, it usually starts with someone looking closely at
work they've watched for years and noticing where it could be better.
Let's keep the conversation going.
