Skip to content

AI Strategy#

AI Isn't the Story. The Report Is.

AI Isn't the Story. The Report Is.

You have probably seen the clip by now. CEO involvement in AI. Better returns. Simple story. Easy to repost.

That is not wrong. It is just incomplete.

KPMG's Global AI Pulse Q2 2026 looks at 2,145 senior leaders across 20 countries, territories and jurisdictions. The survey says:

  • 76% of organizations are already delivering meaningful business value
  • 79% would keep investing even in a recession
  • 22% say they have reached the driving-adoption phase, up from 13% in Q1

So yes, AI is still moving.

But the report is not mainly about adoption anymore. It is about what happens after adoption. That is where the friction lives.

The real frame is three buckets: pragmatic AI adoption, governance, and the economics of AI. That is the part worth reading twice.

What the report actually says

The headline is that the work has shifted.

Most organizations are past the novelty stage. They are trying to decide how to run AI without making a mess of cost, oversight, and accountability.

The CEO line everyone keeps repeating is only half the story

Roughly three-quarters of organizations say the CEO actively owns AI as a strategic priority.

Only 24% say the CEO or executive committee is ultimately accountable for AI-informed decisions. Here is where the rest of the accountability actually sits:

  • 29% point to a named C-suite executive
  • 29% say a business unit or function leader
  • 15% a centralized governance or risk committee
  • 13% shared accountability
  • 13% no clear owner
  • 3% autonomous AI systems within approved limits
  • 1% unsure

That is the gap. Sponsorship is common. Accountability is fragmented.

The report says the strongest outcomes show up where leadership commitment turns into clear decision rights, governance, and a single person who can answer for the result. That is a different sentence than the one getting reposted on LinkedIn.

Governance is not overhead

KPMG says governance cannot sit on the sidelines anymore. The practical questions are plain: who can override the system, who reviews outputs, who owns the cost, and what happens when the model is wrong?

The uncomfortable part is that only about one-third of organizations say their roles, responsibilities and processes are very clear and well managed. In other words, a lot of companies have policies, but fewer have operating discipline.

That is why AI feels productive in a demo and messy in production. The tool is not the whole system.

The money question is the real pressure point

This is the part that gets lost in the sound bite.

Forty-nine percent of organizations say they have questioned, delayed, or scaled back AI deployment because the expected costs started to outweigh the value. That is a warning light.

The report also shows the control stack is still uneven:

  • 54% have cost review as part of AI approval processes
  • 53% use AI cost-monitoring dashboards
  • 40% have usage or token budgets
  • 39% have architecture or prompt design standards in place

Those are real controls, but they are not yet universal.

If you cannot see the meter, you do not have control. You have spending.

What to do with the report

If you are responsible for AI, start with a map. Name one owner. Pick one workflow. Put one cost dashboard in front of the team. Then decide who can stop the system, who can fix it, and what signal says it is actually working.

The companies that get past the demo phase decide who can override the output, who can see the spend, and what counts as a win before the tool is everywhere. That is what turns AI from an experiment into something the business can actually run.

That is the part I keep coming back to. AI usually fails in the handoff, the budget, or the accountability chain. KPMG just put numbers on that pattern.

What the report is really saying

CEO involvement helps. That part is real.

But KPMG's Q2 2026 data says the bigger divider is whether someone is actually accountable for the outcome and whether the organization has built the governance to support that accountability.

That is the useful lesson for anyone trying to make AI pay back.

Not a bigger model. Not a louder rollout. A cleaner operating model.

So the better question is who owns the result, who watches the cost, and who can prove the work is worth it.

If that answer is fuzzy, the problem is the operating model.

Sources

  • KPMG Global AI Pulse Q2 2026, KPMG International, June 2026
  • KPMG Global AI Pulse landing page, KPMG International

A Real AI Automation Sprint Ends With a Working Workflow

A 30-day AI Automation Sprint: one owner, one workflow. Stacks of paperwork beside a printer give way to a clean, working system on screen.

Most AI projects do not fail because the model was weak.

They fail because nobody forced the business process into something real enough to run.

That is the part people skip.

Grant Thornton's 2026 AI Impact Survey of 950 senior business leaders found that organizations with fully integrated AI were far more likely to report revenue growth than those still stuck in pilots.

A company gets excited about AI. Somebody runs a demo. The room lights up. A pilot gets approved. Then the whole thing stalls the second it has to survive real operations.

Because a demo is not a workflow.

And an outcome is the only thing that matters.

If you are running a real AI Automation Sprint, the goal is not to leave with a slide deck, a prototype, or a list of future ideas. The goal is to leave with one working system tied to one operational bottleneck that matters enough to fix.

That is the standard.

Start With the Drag, Not the Tool

I would not start a sprint by asking what model you want to use.

I would start by asking what is slowing the business down every single week.

What gets stuck in inboxes?

What gets rekeyed by hand?

What requires somebody to chase three systems just to answer one customer question?

What depends on one employee who "just knows how it works"?

That is where the sprint starts.

Not with AI as a concept.

With drag.

Intuit's 2026 AI Impact Report reinforces this.

If you cannot name the bottleneck clearly, the sprint will drift. It turns into experimentation without consequence. People stay busy, but nothing meaningful ships.

A real sprint needs a tighter frame:

  • one workflow
  • one owner
  • one measurable outcome

This friction is real. That is how you stop an AI project from turning into theater.

Data Prep Shows You the Truth

This is the part people underestimate.

They assume the workflow is clean because the team can describe it in a meeting.

It usually is not.

The files are messy. The fields are inconsistent. The CRM says one thing, the spreadsheet says another, and half the process lives in side conversations nobody documented. Then you find the exceptions. Then you find the approvals nobody mentioned. Then you find the step where somebody quietly fixes bad data before it breaks downstream.

Good.

That is exactly what you want to find early.

I would rather find the mess in week one than after launch.

Taking the time here is what separates the sprints that hold up from the ones that quietly fall apart after launch. The best sprint teams sit in it long enough to understand what has to be cleaned up, what can be automated, and where human judgment still belongs.

That is not delay.

That is implementation.

Prototype Fast, But Do Not Trust It Blindly

Once the workflow is scoped and the inputs are clear enough, then you build.

Fast matters.

Blind does not.

The first prototype is not there to impress people. It is there to expose weak spots while the stakes are still low.

Where does the output break?

Where does the logic fail?

What does the system handle well?

What still needs review?

What should never run without approval?

Those questions matter a lot more than whether the prototype looks polished.

If the output cannot be checked, it is not ready.

If nobody can explain when a person steps in, it is not ready.

Integration Is the Real Test

A workflow is not real because it worked once in a sandbox.

It is real when it fits the business the way the business actually runs.

That means it has to live where the work already lives. In the inbox. In the CRM. In the file flow. In the approval chain. In the places where people actually make decisions and hand work off to the next person.

This is where a lot of pilots quietly die.

They looked good in isolation. Then they hit the real operating environment and exposed every unresolved problem underneath them.

Weak ownership.

Messy inputs.

No exception handling.

No agreement on what happens when the output is wrong.

No defined handoff back to a human.

That is the moment the business stops trusting the system.

And once trust drops, usage drops right behind it.

Governance Is Part of the Build

A lot of teams treat governance like paperwork.

That is a mistake.

Governance is what keeps a useful workflow from turning into a liability. It isn't just paperwork — it's how you protect the value of your process. As explored in our piece, Why Your Domain Expertise Is More Valuable Than Your AI Prompt, the technology only works when it's framed by the specific business logic you already own.

Before handoff, I want clear answers to basic questions:

Who owns this workflow?

What gets logged?

What triggers review?

What can the system do on its own?

What is it explicitly not allowed to do?

Those are not legal questions.

Those are operating questions.

Without them, small mistakes compound. People stop trusting the system. Work starts routing around it. The workflow becomes one more thing the business has to manage instead of one more thing helping the business move faster.

Governance does not slow the sprint down.

It is part of what makes the sprint worth doing.

What the Sprint Should Actually Deliver

By the end of a real AI Automation Sprint, the business should have something concrete:

  • one working workflow
  • one owner
  • one measurable result
  • clear guardrails
  • a clear definition of where human judgment stays in the loop

Not a presentation.

Not a proof of concept that only works when the builder is in the room.

Not a pile of ideas for phase two.

A working system doing useful work now.

That is the bar.

A sprint gets you the first workflow.

Keeping it performing, governing it well, and expanding it across the business is the next job.

But if the first workflow is not real, none of that matters.

Most companies do not need another AI demo.

They need one outcome worth chasing, and the workflow that reliably delivers it.

Sources: Grant Thornton, "2026 AI Impact Survey" (950 business leaders, fielded February–March 2026), https://www.grantthornton.com/services/advisory-services/artificial-intelligence/2026-ai-impact-survey; Intuit QuickBooks, "2026 AI Impact Report" (May 2026), https://www.intuit.com/blog/global-stories/ai-impact-report/; JOV AI, "Why Your Domain Expertise Is More Valuable Than Your AI Prompt" (April 2026); JOV AI, "The Cost of Software Is Now Zero" (March 29, 2026)

Fractional AI Team vs. Point Solutions: What SMBs Actually Need

Do you need another AI tool? What SMBs actually need. A business owner overwhelmed at his desk, facing a screen full of AI tools.

Buying another AI tool feels like progress. Most of the time it means you added one more subscription to a workflow that was already messy.

That's the pattern I keep seeing in SMBs right now. The team buys a writing tool, a chatbot tool, a meeting tool, an automation tool, maybe an agent tool on top of that. The demos look sharp. The trial goes well. Then the real business shows up. Data is inconsistent. Nobody owns the workflow. The approvals are fuzzy. The CRM is half-right. The reporting is manual. The tool didn't fail. The operating system around it did.

That's why so many AI investments stall after the excitement phase.

The numbers back up what I keep seeing. 47% of SMBs name data readiness as their top AI barrier. Another 37% say a skills gap is slowing them down (AWS/Techaisle, May 2026). The market is full of tools. What's scarce is the people, process, and governance to turn those tools into repeatable operating value.

Buying Tools Won't Build Capability

A point solution helps with a task. The bigger jobs sit upstream: deciding which workflow matters most. Cleaning up handoffs between marketing, sales, ops, and service. Forcing accountability when the output is wrong, slow, or unusable. Building adoption across a team that already has too many systems and not enough time. That work belongs to people, and somebody has to own it.

This is the real divide between buying software and building capability.

Point tools are useful when the job is a single, well-defined task. A fractional AI team is an outside crew of people who own the workflow for you. It earns its keep when the workflow is still fuzzy. When priorities are competing. When scattered use cases need to become one operating plan.

That's the gap too many SMBs miss. They compare license cost to service cost and think they're making a smart financial decision. The smarter comparison is wasted license spend versus deployed value. Zylo's 2026 SaaS Management Index found the average organization leaves 36% of its SaaS licenses unused. A percentage like that doesn't care about company size. A 40-person company carrying five overlapping AI subscriptions leaks the same way, just with fewer zeros.

A tool is cheaper on paper. A team is cheaper in the real world if it helps you avoid six months of drift.

Here's the practical way I'd evaluate platform versus team.

1. Start with the workflow

If a vendor starts by showing features before helping you define the workflow, be careful.

I ask every new client the same first question: where does money, time, or trust leak in the current process?

Lead response lag. Proposal turnaround. Sales follow-up. Content production. Reporting reconciliation. Intake and qualification. Customer support triage.

Serious AI work starts there.

If you can't point to the workflow owner, the bottleneck, the current baseline, and the KPI you want to move, you're still defining the job. Evaluate tools after that.

That's where a sprint comes first.

A sprint should identify the use case, map the workflow, expose the handoff failures, and define what success looks like. It gives the business a real operating target instead of a vague "we need AI" mandate.

A home services company we work with was filling out permit applications by hand. About 20 minutes each, every time a technician needed one. We didn't hand them a tool. We built the workflow into the system they already use, so the applications now file themselves. The tool was never the point. Owning the workflow was.

2. Price the full operating burden

Most SMBs underestimate the hidden cost of point solutions. The monthly fee is visible. The internal drag is not.

Who will implement it? Who will train the team? Who will rewrite prompts when the outputs degrade? Who will handle governance? Who will integrate it into the CRM, inbox, reporting stack, and approval flow? Who will monitor whether the workflow is actually improving?

If the answer is "somebody on the team will figure it out," that usually means nobody owns it.

That's how AI becomes shelfware. I see it every week.

A fractional AI team changes that equation because the core value is operating ownership. Someone is responsible for setup, prioritization, KPI tracking, optimization, and course correction. That's what turns AI from an experiment into a managed function.

3. Demand proof of operational improvement

Don't ask whether the tool is impressive. Ask whether the workflow is better.

Are response times down? Is cycle time shorter? Are more leads converting? Are approvals faster? Is reporting cleaner? Is margin leakage lower? Is the team spending less time on manual coordination?

That's the scoreboard we use with clients.

A good fractional team should be able to tell you what moved, why it moved, and what gets optimized next. If the answer is vague, you're buying activity instead of outcomes.

Here's what happens once you run that scoreboard. "Tool or team" stops being the question.

The real sequence for most SMBs looks like this:

Run the sprint. Install operating discipline. Then decide which tools belong in the stack. Then keep optimizing.

The tool comes fourth. Not first. That ordering is the whole argument.

Isolated software gives you capability on a pricing page. Managed implementation gives you capability inside the business.

And that distinction matters a lot right now, because the AI tool market is getting more crowded by the week. Every roundup of "best AI tools for small business" proves the same thing: there's no shortage of options. The shortage is operational capacity to choose the right use case, integrate the tool into real workflows, govern the output, and keep improving after launch.

Enough AI theater. SMBs need fewer disconnected tools, clearer ownership, and faster movement from pilot to production.

That's what a fractional AI team is supposed to solve: making sure the software you already bought finally does useful work.

If you're staring at a stack of AI subscriptions and can't say which one is moving a KPI, that's worth a conversation before you buy anything else. Reach out. Twenty minutes is usually enough to tell whether you need another tool or an operating plan.

Sources: AWS / Techaisle, "From pilot to production: How SMBs are winning in the AI era" (May 2026), https://aws.amazon.com/smart-business/resources-for-smb/techaisle-ai-adoption/; Zylo, 2026 SaaS Management Index (2026), https://zylo.com/news/2026-saas-management-index

You Don't Need an AI Hire. You Need an AI Champion.

You don't need an AI hire. You need an AI Champion. The advantage isn't AI alone. It's domain expertise + AI.

The instinct makes sense. Hire someone younger who gets AI. Have them sit next to the person who knows the work. Let them figure it out.

It won't work. Here's why.

A business owner in a session I co-hosted came in with a plan.

He runs a service business. Sharp guy. His construction accountant is good at her job. He doesn't understand her work and doesn't need to. His plan: hire a college student at a thousand dollars a week, have them sit next to her, figure out how AI could make her more efficient. He'd already done the ROI math in his head.

He had the right idea. He saw the bottleneck, he did the ROI math, he was ready to move. He was just wrong about who should do the work.

The Correction Came From Someone Else in the Room

Another business owner cut in -- not me, not my co-host. A peer.

"It'll give you an advantage. But hiring a kid -- you won't know what to tell them to work on. You know what your business needs better than anybody."

That's the line that matters. Not because it's surprising, but because of who said it.

Not a consultant. Not someone with a service to sell. Someone in the same seat.

Here's the trap he saw: if you hire someone who doesn't know the work to implement the tech, you're just adding another layer of management. You're now managing a kid who's trying to manage a process he doesn't understand. That's $4,000 a month -- $1,000 a week, four weeks -- before you've changed a single process.

The Matrix Problem

My co-host put it this way: when you're a subject matter expert watching AI work through your domain -- accounting, legal, operations, doesn't matter -- you immediately know when something is wrong. You can feel it before you can name it.

Someone else watching the same screen? It's a wall of scrolling text. Impressive-looking. Meaningless to them.

The kid can learn to use the tools. He cannot catch the mistake in work he doesn't understand.

Your construction accountant has been doing this for years. She knows when the number doesn't look right. She knows which edge cases matter and which don't. She knows which reports take six hours that should take six minutes.

She needs to be the one watching the screen. Not as a spectator. As the person whose judgment the whole system depends on.

That's not a junior hire. That's someone you already have.

What an AI Champion Actually Is

Here's what I keep seeing every time this works.

The company finds the person who knows a specific workflow cold. Not the most tech-savvy person on the team. Often not even close. The person who knows the work best.

They give that person time and permission to experiment. They pair them with someone who can build what that person can judge. And then they protect the feedback loop -- the champion's ability to say "that's wrong" is the whole system.

McKinsey put a name to it -- "AI translators." Their 2025 State of AI report found that high-performing organizations are 3x more likely to have one actively championing AI. Different label. Same model.

Another founder -- he runs a plumbing company -- was already doing this. He wasn't hiring anyone. He was enlisting his existing SME. His framing: "You gotta break the seal. Once you break the seal, it changes."

That's it. One person. One workflow. An outside partner who can build what that person can judge. Neither half works without the other.

The outside partner can't do this alone -- they don't know which output is wrong. The inside champion can't do it alone -- they don't have the build skills to harden what works.

The Gap Most Businesses Are Stuck In

The gap has a number. Goldman Sachs put it on paper last March -- 10,000 small business owners. 93% of AI-using businesses say it's had a positive impact. Only 14% have fully integrated it into core operations. (Goldman Sachs 10,000 Small Businesses, March 2026)

79 points between "it helps" and "it's embedded in how we run."

That gap has a name. It's the absent Champion.

The business tried something. It worked. Nobody owns it. Nobody teaches the team. Nobody builds the next thing on top of it. Six months later they have four AI "projects" and no AI muscle.

The Champion is the missing piece. Not because they're technical. Because they know the work well enough to say what good looks like.

He Got There

At the end of the session -- two-plus hours in, same room, same people -- the same exec came back to it.

"If I hire this kid, can I hire you to teach him? Help him be my champion?"

He got there. Not through persuasion. Through the conversation. Watching other owners work through it.

The model is that simple once you've seen it working.

The Question to Answer Before You Post a Job

Who in your company already knows the workflow you most need to fix?

Not "who's excited about AI." Not "who's most technical." Who knows the work so well that they'd catch a mistake in three seconds that would take anyone else an hour to find?

That's your starting point. One person. One workflow. If you missed the earlier post on why your domain expertise is worth more than any AI prompt, this is the practical application of that idea.

If you need the outside-partner half of that equation -- someone who can build what your Champion can judge -- that's exactly what we do at JOV AI.

Let's talk.

This is the fourth post in a series about what I learned co-hosting a 140-minute AI session with a group of business owners.

Why Your Domain Expertise Is More Valuable Than Your AI Prompt

Why Your Domain Expertise Is More Valuable Than Your AI Prompt

Most business owners are quietly paying for software that almost fits their business.

A platform that locks them in. A vendor that ships features they didn't ask for. A line item that climbs every renewal whether the team uses it or not.

Last month, an owner in a room I was in mentioned, almost as an aside, that he'd built his own property management operating system with AI. In seven days. The kind of thing his industry rents from vendors for around $200,000 a year.

The room went quiet.

Here's the shift: it's not about software getting cheaper. It's about your unfair advantage finally becoming buildable.

You could feel everyone recalibrate.

Ben already wrote the software-side argument from this same session: the cost of software is moving toward zero. He's right.

But the lesson isn't "I should build all my own software now."

The real lesson is simpler.

AI makes domain expertise executable.

The Build Was Impressive. The Builder Mattered More.

Everyone asks one question: "What tool did he use?"

The answer is the trap.

You'll copy the tool. You won't copy the understanding.

The build worked because he knew the business. He knew which fields mattered and which ones only existed because a vendor needed them. He knew which reports helped people make decisions. He knew the weird exceptions that break clean workflows. He knew the handoffs that quietly fail near renewal time.

That's the part a generic software product never has on day one.

It's also the part a junior "AI hire" doesn't have. A smart kid can learn the tools. They can't walk in and know why a dashboard is lying, which tasks create risk, or why the same customer record shows up three different ways.

The AI didn't replace business knowledge.

It finally gave business knowledge a build surface.

The Prompt Is the Visible Part. The Judgment Is the Asset.

Most companies get this backwards. They look at a story like the seven-day build and decide they need to find the person who can prompt the best.

That's the wrong hire.

If you ask AI to build a workflow and you can't explain how the workflow should actually work, you get noise. Maybe polished noise. Maybe useful-looking noise. But still noise.

The model isn't the bottleneck. The clarity is.

The owner in that room didn't succeed because he had a magic prompt. He succeeded because he could look at an AI-built version of his business and say:

This field is wrong.

This report is missing the decision.

This handoff will fail at renewal.

This is how my team actually works.

This step needs to happen before the manager ever sees it.

That's not technical knowledge. That's operator knowledge. And right now, operator knowledge is wildly underpriced.

Why This Shift Happens Now

Three years ago, this story would have started with a developer. Scoping took weeks. The first useful version cost real money before anyone knew whether the workflow was right.

Today, the operator can build the rough first version himself. Then someone with software judgment hardens what works: permissions, data quality, security, reliability, and edge cases.

That changes the economics. The first question is no longer, "Can we afford custom software?" It is, "Can we prove this workflow is worth owning?"

That is where JOV fits. We are not trying to replace operator judgment with tools. We are trying to turn operator judgment into working systems.

Your Unfair Advantage Is the Stuff Vendors Never Learn

Every business has an operating layer vendors never learn: the Friday spreadsheet, the client report stitched together from three systems, the intake exception, the renewal workflow carried by a veteran employee.

That stuff is invisible. It's also where AI gets real.

Not "write me a strategy." Build the thing that removes drag from the business you already understand.

That's why the seven-day build matters. Not because every owner should spend the weekend replacing their software stack. Most shouldn't. Security, permissions, data quality, and production reliability still matter.

It matters because it proves the bottleneck moved. The bottleneck used to be whether you could afford software built around your business. Now it is whether you can describe the work clearly enough for AI to help build it.

What This Looks Like at SMB Scale

The seven-day build is the dramatic version. Here's the everyday one.

A multi-location wellness operator I work with runs the business on a vertical-specific accounting and booking platform that costs around $150,000 a year. The kind that keeps everything in a closed ecosystem because that's how they upcharge you. Every adjacent feature is a paid line item. The person handling operations isn't a developer, but he knows the business. Over the last several months, he has been using AI to build small apps that work around the closed platform. Each one replaces one paid upsell. He's stacking these.

Ben is helping turn the working ones into production-grade tools. That's the maturity arc: an operator builds the first version because he knows the business. Someone with software judgment hardens what works for security, reliability, and the edge cases. Neither half does it alone.

That's the model. It scales down to one retired line item at a time, and up to a $200K system in seven days.

Two Bad Reactions, One That Actually Works

We see two predictable reactions to this shift.

The first is DIY bravado. "Great, software is free. We'll build everything ourselves."

Result? A prototype becomes one person's private system. No permissions model. No audit trail. No one else trusts the data, so the old vendor stays live in parallel.

The second is vendor reflex. "Great, let's hire an AI person and have them figure it out."

Result? Someone learns the tools but never the business. They automate the obvious stuff and miss the expensive stuff: the exception, the handoff, the renewal risk, the report that actually drives a decision.

The version that works is a partnership.

One operator inside who can say what good looks like. One implementation partner outside who can turn that into AI workflows, software, automations, and guardrails.

Start with the workflow that already has a number attached to it: the tool you keep renewing reluctantly, the report that takes six hours, the handoff that creates rework, or the process your best employee carries in their head.

If you can't put a dollar, hour, risk, or revenue number on it, it can wait.

The Next Seven Days

Don't start by asking, "What app should we build?"

Start with three questions:

  1. What part of the business do we understand better than any vendor ever will?
  2. What recurring workflow is expensive because it's trapped in people, spreadsheets, or rented software?
  3. Who inside the business can judge whether the AI-built version is actually right?

That third question is the one most people skip.

Without that person, AI produces demos. With that person, AI produces operating leverage.

That's the shift. For SMB owners, it's the opportunity.

Start here: which of these is costing you the most?

  • [ ] A vendor subscription for features your team doesn't use
  • [ ] A manual report or process your best employee carries in their head
  • [ ] A workflow trapped between three systems with no clean handoff
  • [ ] A renewal price that climbs every year

Pick one. Then Let's Talk. We'll use it to scope the first useful build: the smallest workflow that can free capacity, retire spend, reduce risk, or unblock revenue.

Sources:

Only 11% of Companies Are Scaling AI. The Rest Keep Starting Over.

Only 11% of Companies Are Scaling AI

You automated a workflow. It worked. Maybe you saved six hours a week on reporting, or cut your meeting prep in half. Your team noticed. You felt the win.

Then you tried to do it again in another department and hit a wall.

That wall is where most businesses get stuck. Not at the start. After the start.

Here's the number I can't get past: only 11% of companies qualify as AI leaders in KPMG's Q1 2026 Global AI Pulse.

Not 11% using AI. Almost everyone is using AI.

Eleven percent getting coordinated results across the business.

The other 89% aren't failing. They're just not compounding.

And yes, KPMG's sample is larger companies. But I see the same pattern even faster in SMBs, where smaller teams have less room for vague ownership and broken handoffs.

The Word Nobody Wants to Hear

Here's the word most business owners don't want to hear: governance.

I know. You heard "governance" and thought: lawyers, compliance, red tape.

That's not what I mean.

McKinsey made the point clearly in March 2026. Governance isn't the thing that slows AI down. It's the thing that lets it expand.

Think about it practically. If nobody owns the output, if nobody defined what success looks like before rollout, and if there's no plan for when the system gets it wrong — you can't responsibly give AI more responsibility inside the business.

So it stays at the edges. Drafting a few emails. Summarizing a few notes. Maybe saving some time.

But it never changes the way the business actually runs.

That's not a governance failure. That's a governance vacuum. And it's the reason most companies stay stuck after their first win.

Why the Second Workflow Is Harder Than the First

Here's the pattern I keep seeing.

First workflow works great. Owner gets excited. Tries to roll out three more at once. Each one gets managed by a different person, with different tools, different standards, and a different definition of success.

Six months later you have four AI "projects" and no AI "system."

KPMG's Global Tech Report puts a number on the operational problem: 51% of tech executives say legacy processes are contributing to poor ROI on their tech investments. In smaller companies, Goldman Sachs found the same gap — 93% of small businesses using AI say it's had a positive impact, but only 14% have fully integrated it into core operations (Goldman Sachs 10KSB, March 2026).

That's not about old software. It's about old handoffs, unclear ownership, and workflows nobody fixed before layering AI on top.

The first win doesn't require a system. You just need one person, one problem, and one tool. But the second win? The third? Those require something the first one didn't: a repeatable model for how AI gets deployed, measured, and improved inside the business.

Without that model, every new workflow starts from scratch. And starting from scratch every time is how you stay in the 89%.

What the 11% Do Differently

When I look at what separates the companies getting coordinated results from the ones collecting standalone wins, three things show up every time.

1. One person owns AI outcomes, not AI tools.

Not a Chief AI Officer. Not whoever is most "tech-savvy." The person who owns the business outcome the workflow is supposed to improve. If AI is supposed to cut reporting time, the person who owns reporting owns the AI outcome too. Ownership follows the metric, not the technology.

2. Success is defined before rollout, not after.

The 11% don't launch AI and then check if it helped. They name the metric first. Time saved. Errors reduced. Revenue influenced. If you can't name the metric before you start, you're not ready to scale.

3. Guardrails are built into the workflow, not bolted on later.

What data can the tool touch? What requires human review? What happens when the output is wrong? The companies scaling AI answer these questions before the second workflow launches. Not after the first incident.

None of this is complicated. But it's the part almost everyone skips.

What Happens When This Clicks

When those three things are in place, something changes.

The second AI workflow deploys in days, not months. The third is faster still. Each one inherits the ownership model, the measurement framework, and the guardrails from the last.

That's what "AI leader" actually means in the KPMG data. Not more tools. Not bigger budgets. AI leaders report meaningful business value at 82%. Non-leaders: 62%. Same market. Same access to tools.

Different operating discipline.

The gap isn't about adoption anymore. It's about whether your AI efforts compound or just coexist.

This is the part most businesses skip. Not because they don't believe in it, but because nobody walks them through it while the work is happening.

That's how we operate. We start with the bottleneck. Find the quick win. But while we're building that first workflow, we're asking the questions that make the second one faster: who owns this, how do we measure it, and what are the guardrails?

We built this framework with a Dallas foundation from scratch - policy, data classification, ownership model. It's the same approach we bring to every engagement, because it's how AI stops being a project and starts being the way you run.

If you've had your first AI win and want the next five to stick, let's figure out how to pair these tools with the people who actually know your business. Let's Talk.

Sources:

AI Slop Is a Confession

AI Slop Is a Confession

You've seen it. The LinkedIn post that reads like a robot summarized a robot. The sales email that opens with "Dear [First Name]" and goes downhill from there. The blog post so generic it could be about any company in any sector on any planet.

"Slop" became Merriam-Webster's Word of the Year in 2025. The American Dialect Society picked it too. Everyone agrees the problem is real.

But here's the question nobody's asking: why does the slop exist?

The Amplifier, Not the Problem

I was in a room full of business owners recently when my CTO reframed the whole conversation. He compared AI to a guitar amplifier.

If you're a great guitarist, an amplifier lets you fill a stadium. If you're a terrible guitarist, it just makes you louder and noisier to more people.

Same tool. Same technology. Completely different outcomes. The variable is the person plugging in.

That's AI right now. The same AI subscription that produces thoughtful, specific, useful content for one person produces pure garbage for the person sitting next to them. The technology didn't change between those two desks. The expertise did.

And this doesn't change just because the AI gets more sophisticated. If you hook a powerful system up to a broken process managed by someone who doesn't understand the domain, you don't fix the problem. You just automate the creation of slop at scale.

The Confession Nobody Hears

Here's where it gets uncomfortable.

When someone says "it made AI slop," they're making a confession. They're telling you, without meaning to, that they couldn't coach AI into producing good work. Not because the AI can't do it. Because they didn't know what good looked like in the first place.

Think about that. If you can't recognize bad output, you can't fix it. If you can't define what good looks like, you can't direct the tool toward it. The slop isn't an AI failure. It's a skills gap wearing a technology mask.

I've been guilty of this too. I'm not a natural writer, so the amplifier didn't work for me out of the gate. I had to build the expertise first. The AI only got good once I learned what good looked like.

This isn't just a hot take from a room. Harvard Business School published research in March 2026 that backs it up: AI helps people generate ideas and frame problems, but it can't help them execute when they lack the experience to know what good execution looks like. The researchers put it plainly: when a task requires "concrete application and context-bound nuances," the person without lived experience stays at a disadvantage, AI or not.

AI doesn't close the expertise gap. It highlights it.

The difference between slop and signal isn't the software. It's the driver steering the prompt.

The Tale of Two Prompts

The Junior Hire (No Domain Expertise): "Write a warranty claim for this HVAC repair: 'unit dead. capacitor blown. replaced it.'" Result: A vague, three-paragraph letter that no warranty clerk would approve. Missing the model number, the failure code, the diagnostic readings, the part specs. Slop.

The 15-Year Ops Lead (Deep Domain Expertise): "Draft a warranty submission for a Carrier 48TCED06 RTU. Use Condition/Cause/Correction format. Field data: 70/7.5 mfd 440V dual run cap vented with oil leak. Contactor points pitted from high-amp draw. Compressor windings verified good (megohm test >500M). Replaced cap and 3-pole 30A contactor. 2 hours total: 0.5 diagnostic, 1.0 repair, 0.5 system test. Tone: clinical, no fluff. Address to Carrier National Warranty Dept." Result: A clean, compliant, ready-to-submit warranty claim that gets the business paid.

Same AI. Same field notes. One person had the domain knowledge to direct it. The other didn't.

What This Means for Your Business

If your team is producing mediocre AI output, don't cancel the subscription. Look at who's driving.

Last September, HBR reported that 41% of workers are already dealing with "workslop," memos and reports that create more rework than they save. Every incident costs about two hours to clean up.

The answer is pairing AI with someone who actually knows the work. Someone who can look at what the AI produced and say, "No, that's wrong. Here's why, and here's what right looks like."

In most SMBs, that person already exists. Your operations lead who's been doing the work for fifteen years. Your sales manager who can spot a bad proposal in two sentences. Your controller who knows which numbers actually matter.

They don't need to become AI experts. They need to become AI editors. The person who knows the work is the difference between slop and signal.

The Real Question

The next time someone shows you AI slop (a terrible email, a generic blog post, a report that says nothing), don't blame the technology.

Ask who was driving.

If your team is bleeding hours cleaning up mediocre AI output, we should map out your bottlenecks. Let's figure out how to pair these tools with the people who actually know your business. Click Let's Talk to start the conversation—no pitch, just shop talk. Let's Talk.

What Block Gets Right and Wrong About AI-Driven Organizations

Block recently published an essay arguing that AI will replace organizational hierarchy — that the span-of-control constraint governing every large organization since the Roman legions can finally be broken. The essay, introduced with an endorsement from Sequoia, spends considerable time on military history before arriving at Block's vision: a company organized as "an intelligence" rather than a hierarchy, where AI maintains a "world model" of operations and coordinates work that previously required layers of human management.

The piece is ambitious. It is also roughly 80% historical context, 15% vision, and 5% acknowledgment that none of this exists yet. Let's extract what's actually useful.

They Don't Want to Learn AI. They Want the Easy Button.

Where's the AI Easy Button?

We recently hosted an AI session for a group of business owners. We had slides. We planned for a 30-minute presentation and 30 minutes of Q&A.

They kept us for almost three hours.

Not because the slides were great. Because every question opened another question. The room included owners, investors, and executives from financial services, construction trades, property management, and protection services. Industries that have nothing in common except this: they all know AI matters, and none of them are sure what to do about it.

"I'm Not Creative Enough to Know What Problems to Bring to AI"

One exec said this out loud. Nobody laughed. Everyone nodded.

This was a successful, experienced leader being honest about a specific blind spot: he couldn't picture what AI does for his specific role. Not "AI can improve efficiency." He needed to know what it looks like on a Tuesday morning when he sits down at his desk. He couldn't even frame the right questions to ask.

These are leaders with vision -- that's how they built what they built. The gap is translating "AI matters" into a picture of what it actually does inside their business. And that gap is everywhere. Kellogg just published research naming this exact pattern. They call it Stage 1. Your people are using ChatGPT for the stuff they find annoying, but there's no strategy. No structure. Nobody connecting it to business outcomes. The tools exist. The vision doesn't.

"In Six Months, Will There Be a Product That Eliminates the Need to Do All This Learning?"

A different exec asked this one.

Another founder in the room took it further. He'd already decided to hire someone junior to start digging in. His real question was whether he could then hire us to train that person. He'd even framed the ROI on the spot -- $1,000 for a week to sit with his operations team and find the savings. He wasn't looking for a vendor. He was describing the model without knowing it had a name.

Two different people. Same request. Give me the easy button.

Here's the thing: that instinct is exactly right. The smartest thing a busy CEO can do is recognize what they're great at, running their business, and find someone to handle the rest. You don't build your own accounting software. You hire a CPA.

The problem isn't wanting the easy button. The problem is that most of the "easy buttons" on the market don't actually work.

Why the DIY Approach Stalls

The most advanced AI user in the room, someone who'd built a full property management operating system in seven days using AI, pushed back hard on the "hire someone" instinct.

His point: you can't hire a kid right out of college to figure this out for you. AI requires domain expertise. A junior hire doesn't know your business. They don't know which processes are bleeding money, which reports take six hours that should take six minutes, or which customer touchpoints are quietly falling apart.

Here's the number that tells the story: 56% of CEOs investing in AI still haven't seen revenue or cost benefits (PwC, January 2026). Not because the technology failed. Because the implementation did. They bought the tool without connecting it to a business problem. Or they handed it to someone who didn't understand the business well enough to know where to point it.

That's the pattern we see on almost every discovery call. Someone bought a tool, or assigned it to the most "tech-savvy" employee, and six months later the tool is gathering dust and the employee is back to doing things the old way. Not because anyone failed. Because the approach was wrong from the start.

What It Looks Like When It Works

Here's where the conversation turned. My CTO drew the distinction that stuck with everyone: the difference between an AI implementer and an AI champion. An implementer installs the tool and moves on. A champion is someone inside the business who changes how the team actually works. That's the role that matters -- and it's not a role you can hire off a job board.

The model that came out of the room was simple. Don't hire an AI person. Find someone already in your business who's curious, give them time and permission to experiment, and pair them with someone who actually knows the tools. Not an IT project. A business operations project. One founder put it simply: it's the same reason companies hire an MSP instead of building an internal IT team, or a fractional CFO instead of a full-time hire. You need the result. You don't want to manage the complexity.

That's the AI champion model. One person inside who knows the business. One partner outside who knows AI. The inside person spots the problems worth solving. The outside partner builds the solution and trains the team to use it.

We use this model ourselves. Our own AI systems handle daily briefings, prospect research before meetings, and coordination across our delivery team. Meeting prep that used to take 30 minutes now takes 5. We built them the same way -- started with the bottleneck, pointed AI at it, and trained ourselves to use it. We're our own first client.

The Easy Button Exists. It Just Doesn't Look Like Software.

That's not laziness. That's leadership. The CEO's job is to run the business, set the vision, and make the calls. Not to spend weekends watching YouTube tutorials about AI agents.

The easy button isn't a product you buy. It's a partner who already knows the tools, pairs with someone who knows your business, and builds systems your team can actually use. No more handing it to whoever seems most tech-savvy and hoping for the best. Just someone who's done this before, paired with someone inside who knows where the problems are.

If you're the person in that room nodding along, thinking "that's exactly what I want," that's what we built JOV AI to be.

If you want to talk through what this looks like for your business, reach out. I'll send you the three questions we use to find where AI saves the most time. Just a starting point.

Sources:

The Cost of Software Is Now Zero

A survival rubric for software and SaaS entrepreneurs in the era of vibe coding.

In February 2025, we published The AI-Driven Transformation of Software Development. Our central thesis: AI would trigger a fundamental shift in the build-versus-buy calculus, accelerating a "Cambrian explosion of software" and driving development costs toward zero. We predicted that businesses would find building tailored solutions increasingly cost-effective and strategically superior to purchasing off-the-shelf software.

The thesis has played out. The cost of code is, for most practical purposes, zero.

What's Actually Happening Out There

We sat with two business owners last week. The conversations were different in detail but identical in conclusion: both had stopped buying software.

One is building a complete property management operating system: property records, CRM, fleet tracking, risk management, financials, task management, and more. Not a subscription he configured — a system his company owns outright, built for exactly how his operation works. He built it in two weeks — what would have cost $200,000 a year to rent from a vendor.

The other runs a retail chain. Someone on his team has been working through the software stack systematically — not one big build, but a rolling replacement of every tool they'd been renting. He's already cut $300,000 in annual costs. He's roughly halfway through. When the last subscription is gone, he's asked us to review the whole thing before it goes live — security, scalability, and production robustness.

Operators are replacing project management tools, CRMs, inventory systems, client portals — the entire layer of workflow software that SMBs have been renting for decades. Not because they became developers. Because describing software and building software are now the same thing.

The savings compound at exit. At a typical acquisition multiple, a $300,000 annual reduction in software costs adds over a million dollars to the sale price.

Now look at the same picture from the other side — the side trying to sell software to these operators.

One Million Vibecoders Writing the Same Thing

A massive crowd lined up for "Vibe Coders" and one person in line for "Users"

A million people are building ERP systems. A million people are building project management tools. A million people are building CRMs. They're all working on the same categories, pouring effort into software they intend to sell — and none of them have a market. Because anyone who wants that software will just build their own.

The vibecoders building products to sell are wasting their time. Their potential customers have the same tools they do.

The only vibecoders whose code actually gets used are the ones who are also the users: owner/operators building custom software for their own businesses. That ERP built specifically for one company's workflows, by the person running that company — it doesn't need to find a customer. It already has one.

This is the dividing line. Vibe coding is not a new software business model. It's the tool that lets operators stop being software customers.

The businesses in trouble aren't failing because they have bad products. They're failing because the people who used to buy from them have a better option: build it themselves, tailored to their exact needs, with no recurring subscription.

The Question That Follows

If code is free to produce, software businesses that sell code lose their moat.

The value proposition was never really the software itself. It was the arbitrage: someone already built this, so you don't have to pay a developer. That arbitrage is gone. The operator with a weekend and a capable AI assistant can now build exactly what they need, perfectly suited to their workflow, with no recurring subscription cost.

Not all software businesses face this. The ones selling code packaged as a product are in trouble. The ones that were always selling something else — using software as the delivery mechanism — are fine. Some are better than ever.

The question every founder needs to answer honestly: if code were free, would anyone still buy from us?

What Survives

Twenty years ago my colleague John Cage introduced me to Treacy and Wiersema's Value Disciplines. Operational Excellence, Product Leadership, Customer Intimacy — pick one to dominate, maintain threshold in the others. I've applied it to every strategic engagement since. Vibe coding just took one of the three off the table.

Operational Excellence. Competing on lowest cost and highest efficiency has been the dominant strategy for SMB SaaS. It's no longer defensible. When an operator can build exactly what they need at zero recurring cost, "cheaper than building it yourself" isn't a position.

Product Leadership survives — if the complexity is real. Feature-rich workflow software doesn't qualify. Genuine product leadership means ML models, optimization systems, domains that require years of specialized expertise to build correctly. A vibe-coded app can approximate a dashboard. It can't approximate a decade of algorithmic research.

Customer Intimacy not only survives, it wins. Anywhere the deliverable is judgment, accountability, or trusted expertise — with software as the delivery mechanism rather than the product. Cheap code helps these businesses. They deliver faster, operate leaner, and take on more clients with the same team. The operators winning here aren't the ones handing everything to AI — they're the domain experts who can supervise it. That's precisely why they're winning.

Two additional categories fall outside the disciplines but are equally defensible:

Regulatory and compliance moats. Healthcare software, financial systems, anything requiring liability acceptance, certifications, or audit trail requirements. A vibe-coded replacement might replicate the features. It won't replicate the compliance posture.

Infrastructure position. The picks-and-shovels layer that vibe-coded applications depend on: authentication, payments, deployment, APIs, databases. Network effects live here too — platforms where years of data and an embedded partner ecosystem make migration genuinely expensive. Vibe coding expands this market, not shrinks it.

The Rubric

Score your business across seven dimensions. Add them up.

Dimension 1 — Exposed 2 — Mixed 3 — Defensible
Value Delivery Software is the product. Customers pay for features. Software enables a service. Code and expertise blend. Judgment, trust, or accountability is the product. Software is delivery.
Switching Cost Data is portable. No integrations, no ecosystem. Meaningful friction: data history, integrations, learned workflows. Network effects or regulatory data residency. Migration is genuinely expensive.
Compliance Moat No requirements. Anyone can build a replacement. Compliance matters, but a determined operator could manage it. Certifications, liability acceptance, audit trails. Vibe coding can't satisfy these.
Problem Complexity Forms, dashboards, CRUD. Buildable in a weekend. Non-trivial integrations or moderate algorithmic depth. ML, optimization, real-time systems. Years of specialized expertise required.
Buyer Profile SMB operators — the people now building their own tools. Mid-market with some IT governance. Regulated enterprises, governments. Procurement and legal sit between you and replacement.
Layer End-user application for a specific use case. Platform with some application features. Infrastructure that vibe-coded apps depend on.
Proprietary Data / Content / IP No proprietary data or IP. Anyone starting from scratch would reach feature parity quickly. Some accumulated data advantage — user history, transaction data — but replicable with time and effort. Proprietary datasets, content licenses, or IP that cannot be recreated from scratch. The asset is the moat.

Reading Your Score

Total What it means
7–12 Pivot urgently. You're in Operational Excellence territory — the discipline vibe coding just ended.
13–17 Reinforce or reposition. You have assets but meaningful exposure. Identify which dimensions can be strengthened.
18–21 Press the advantage. You're operating in Customer Intimacy, Product Leadership, or infrastructure. Double down.

Two Examples

Monday.com scores a 10. It's a $10 billion company. It's also a work management application — forms, boards, and status columns with a clean interface. No compliance requirements. No proprietary data. No algorithmic depth that requires years to build. Its switching cost scores a 2 because workflows and integrations create some friction, but nothing that survives a determined replacement effort. The rubric doesn't care about revenue multiples. A tool called Zapta already lets teams feed in their Monday.com API token and vibe-code a custom replacement — database, authentication, and all — for $29 a month.

Stripe scores a 21. Every dimension is defensible, and most reinforce each other. The compliance posture is what creates the enterprise buyer. The enterprise buyer generates the transaction data. The transaction data trains the fraud models. The fraud models deepen the moat. A vibe coder building a payments app doesn't compete with Stripe — they depend on it.

The M&A market is already pricing this divergence in. Q1 2026 data shows that in vertical software acquisitions, revenue growth carries 2.4 times the predictive weight of EBITDA margins in explaining valuation outcomes. Buyers are paying for stickiness — which is another way of saying they're paying for defensibility.

What This Means

Most software businesses were built on the assumption that code was scarce. It isn't anymore.

The question in the middle of this article — if code were free, would anyone still buy from us? — isn't rhetorical. Run the rubric. If you're scoring in the 7–12 range, the answer is no, and your replacement isn't a competitor. It's your customer.

JOV AI helps technology businesses navigate this shift. If your rubric score raised questions about your position — or if you're building the thing that replaces someone else's and want it done right — let's talk.