Short letters about where AI leverage actually hides in real businesses.

Where I've seen proposal workflow leverage hide most often

Dear Reader,

I've run the Discovery session enough times now to know a small number of places where leverage hides in services businesses more often than anywhere else. The most common one, by a wide margin, is the proposal workflow.

Here's the pattern I see, in seven words: the founder rewrites every proposal his team drafts.

He didn't start doing this on purpose. Early on, there was no team, so he wrote every proposal himself. Then he hired, and he asked the new person to draft proposals, and the first one came in and it wasn't quite right, so he rewrote it. Then the second one. Then the third. After about ten of these, an unspoken pattern settled in — the team drafts, the founder rewrites. The founder doesn't love this. Neither does the team. But nobody has sat down and redesigned the workflow so that it doesn't need to happen.

Here is the move I've seen work. It's not what most people reach for first.

Most people's first instinct is "have AI write the proposal." That doesn't work. AI writes a proposal that is 70% of the way there and still needs the founder's rewrite, so nothing has been gained.

The move that works is this: have AI compile the inputs the founder actually rewrites around. The client's specific language from past emails. The founder's previous three similar proposals, with the sections he most reused. The pricing logic from the last time this kind of project was scoped. An AI-generated first draft that is explicitly labeled as "draft one — founder to revise" and is calibrated to the founder's actual voice, not some neutral consultant voice.

What happens next is the part most vendors miss: the team gets faster at finishing the draft themselves, because they can see what "ready for founder" looks like. Within a few weeks the founder is only rewriting 30% of proposals instead of 100%. Within a quarter, 10%. The founder time recovered goes straight to pipeline and deals.

If this pattern sounds familiar, that piece of work is where your leverage probably lives. I'd start there.

Jonathan

The founder-bottleneck pattern — and why it's almost always the same shape

Dear Reader,

Every founder-led company I work with has a version of the same bottleneck. The specific flavor varies. The shape doesn't.

Here is the shape. There is a piece of context that lives entirely in the founder's head. It could be client history. It could be pricing judgment. It could be the weird way a particular vendor needs to be talked to. It could be which customer is about to churn and why. The team can't do the work around that piece of context without asking the founder, and the founder can't externalize it without taking an hour that he doesn't have, and so the context stays in his head, and the team keeps asking.

Most founders try to solve this with documentation. Notion pages. Shared drives. Airtable bases. I have watched dozens of these projects collapse. They collapse because documentation requires a human to decide a piece of context is worth writing down, then write it down, then keep it updated. No busy founder does this reliably. The documentation project stalls at 40%, the team stops trusting it, everyone goes back to asking.

The move I've seen work is different. Don't try to pre-document the context. Capture it as it happens.

Set up a pattern where every client interaction — every email, every call transcript, every Slack thread — automatically lands in a per-client context document. AI maintains the document. It doesn't generate new truth; it organizes the truth that's already flowing through. The team can read the document when they need context, and what they read is fresher than anything the founder could have written down after the fact.

The founder doesn't have to do anything different. The context externalizes itself, in the background, from the actual working surface of the business.

I've seen this one move alone give a founder 6–10 hours a week back. That time almost always goes straight to the next constraint on the business, which is usually sales motion. One change, one constraint dissolved, the next one becomes the work. That's the compounding.

Jonathan

What AI is bad at, in my experience

Dear Reader,

I want to write about this because I think the AI-consultant industry has a problem being honest about limits, and I'm not going to play that game.

Here are the things I have watched AI fail at, repeatedly, across all the businesses I've worked in:

Judgment calls with high downside. Firing a client. Deciding to raise prices. Letting someone go. Pulling the plug on a project. AI is a decent sparring partner for these, but if you let it make the call, you'll get a confident wrong answer and regret it.

Knowing what not to do. AI is an enthusiastic helper. It will always suggest doing something. Half the most valuable decisions in a business are "don't do that." AI is bad at surfacing those. Humans with experience are not.

Actually listening to a customer. AI can summarize a call transcript. It cannot notice the thing the customer didn't quite say out loud that matters more than everything they did say. That noticing is the whole craft of customer work, and it's still a human job.

Long-horizon consistency. If you're writing a book, building a product over months, or maintaining a voice across a year of communication, AI drifts. Without strong human editing the result is plausible-but-bland. The drift gets worse as the horizon lengthens.

Knowing when it's wrong. This is the big one. AI will tell you a confident lie with the same voice it uses for a confident truth. For any output that matters, you need a human-designed verification layer. The verification layer is usually where the real engineering is.

If someone pitches you an "AI solution" that doesn't acknowledge these limits, they're selling a story, not a result. A real installation of AI in a business works around these weaknesses, not in denial of them. The craft is knowing where to put AI and where to keep humans — which is, incidentally, most of what the Leverage Discovery session is for.

Jonathan