Last week I wrote about the scaling wall. The pattern where a company hits product-market fit, doubles the team, and then watches operational overhead eat everything.

The response surprised me. Not because people disagreed. Because the most common reply was some version of: “OK, I get it. But where do I actually start?”

Fair question. Naming the problem is step one. But if you can’t point to the specific constraint that’s capping your team, you’re just agreeing with a diagnosis you can’t act on.

So here’s the diagnostic I run in the first two hours of every engagement. You can do it yourself, Monday morning, with a whiteboard and your leadership team.

The Three-Question Diagnostic

I’ve tried complicated frameworks. Weighted matrices. Priority scoring systems. None of them work as well as three direct questions.

Question 1: Where is your most expensive person spending their cheapest time?

McKinsey research found that managers spend just 23% of their time on strategy. Another 31% goes to individual-contributor work. Nearly a full day each week disappears into administrative tasks.

Now think about your CTO. Your COO. Your head of ops. What are they actually doing all day?

Not what their job description says. What they’re actually doing.

In my experience, the answer usually involves some combination of: manually pulling reports, coordinating across tools that don’t talk to each other, onboarding new hires into processes that only exist in someone’s head, and putting out fires that started because nobody automated the thing that catches them early.

That’s your CHF 180k-a-year person doing CHF 60k-a-year work. Not because they’re bad at their job. Because the systems around them force it.

Question 2: What would break if one person went on vacation for two weeks?

This is the fastest way to find single points of failure.

If the answer is “nothing, we’d be fine,” congratulations. You don’t have the problem I’m describing. But in most 15-35 person companies, at least one critical process lives entirely in one person’s head. The weekly client report. The deployment pipeline. The invoice reconciliation.

That’s not a people problem. That’s a systems problem wearing a people costume. And it tells you exactly where your fragility sits.

Question 3: What are you doing manually that you’ve been meaning to automate for six months?

Every scaling founder has a list. The spreadsheet that should be a dashboard. The email sequence that should be triggered automatically. The data entry that someone does every Friday afternoon.

The reason it hasn’t been automated isn’t that it’s technically hard. It’s that nobody has the bandwidth to fix it, because everyone’s bandwidth is consumed by the manual work itself.

That’s the loop. And breaking it is usually simpler than you’d expect.

How to Read the Answers

Run these three questions with your leadership team. Write down every answer. You’ll probably end up with 8-12 items across all three.

Now sort them by one criterion only: which one costs the most senior attention per week?

Not the most annoying. Not the most technically interesting. The one that eats the most hours from the people whose time matters most.

That’s your bottleneck. That’s where you start.

Not three things. Not a roadmap. One constraint.

Why One, Not Three

The instinct is to fix everything at once. Build a “digital transformation roadmap.” Hire a consultant to map all the processes. Spend two months planning.

I’ve watched this play out dozens of times. The roadmap gets built. It sits in a slide deck. Six months later, the same fires are burning.

One bottleneck, fixed completely, does something a roadmap never does: it creates belief.

When the team sees their Friday afternoon data entry disappear, or the CTO gets four hours back because the deployment pipeline doesn’t need hand-holding anymore, something shifts. The next fix becomes easier to justify. Not because of ROI calculations. Because everyone saw it work.

The Mercury Startup Economics Report 2025 found that 69% of companies with significant AI adoption increased their use of external specialists in the past year. Not because they couldn’t build internally. Because they learned that fixing the first constraint fast creates momentum that internal teams can then carry forward.

What Happens After the First Fix

This is the part that matters more than the diagnostic.

Once the bottleneck is solved, the question becomes: can your team solve the next one without outside help?

The best engagements I’ve run follow a pattern:

→ Week 1: Fix the constraint. Working software, running in your environment.

→ Week 3: Hand over. Train the team to extend and maintain what was built.

→ Month 3: Advisory. Available for strategic questions, not daily operations.

→ Month 6+: Independence. Your team picks up the next bottleneck themselves.

Every other option on the market has a structural incentive to keep you dependent. Agencies bill monthly. Consultancies extend engagements. Internal hires become permanent cost.

This model has a structural incentive to leave. And that’s exactly the point.

Try It Monday

Block 90 minutes with your co-founder or leadership team. Ask the three questions. Write down everything. Sort by senior attention cost.

You’ll walk out with one clear constraint. Not a strategy deck. Not a hiring plan. One thing you can fix, probably faster than you think.

The scaling wall is real. But it’s not abstract. It’s specific. And specific problems have specific solutions.

Start there.

Damian Nomura helps scaling startups close the capability gap between where they are and where they need to go. His Build Week format takes the biggest operational bottleneck and turns it into working software in 5 days. Simple. Clear. Applicable.

The company hits product-market fit. Revenue grows. The team doubles from 10 to 25. Then something breaks.

Not the product. Not the market. The machine around the product.

Operations starts eating everything. The CTO stops building and starts firefighting. Every new hire adds coordination overhead that nobody budgeted for. And the CEO sits in a room with a growing team, thinking: “We know where we need to go. We can’t get there with what we have.”

I hear some version of this in almost every discovery call.

The Wall

I call it the scaling wall. It shows up somewhere between 15 and 35 people.

What worked at 10 stops working. The informal processes, the quick Slack messages, the “everyone just knows what to do” culture. All of it collapses under its own weight.

And the instinct is to hire. Stretched? Hire. Drowning in admin? Hire. CTO can’t keep up? Hire a second one.

Premature scaling contributes to 74% of high-growth startup failures. Not because the market wasn’t there. Because the internal systems couldn’t support the growth.

Hiring creates coordination overhead, more meetings, and pulls people further from product. Worklytics’ 2025 engineering benchmarks found that the median engineering team already spends 28% of its workday in meetings. At the 25th percentile, that number hits 35%. Coding time drops to 22% of the day.

Your most expensive people, doing their most valuable work, less than a quarter of the time.

Where the Gap Opens

Teams are strong. The gap between where the company is and where it needs to go just can’t be closed by adding headcount alone.

“Operations is eating us alive.”

I hear this exact phrase. Not my words. Theirs.

The CEO feels it as growth slowing down despite hiring. The CTO feels it as context-switching between operational fires and product roadmap. The team feels it as everyone doing three jobs, most of which aren’t the job they were hired for.

Techreviewer’s 2026 research backs this up: 72% of companies rate their talent pool as strong, yet 53.7% still can’t find candidates with the skills they actually need. The talent is there. The fit rarely is.

The capability gap runs deeper than hiring can reach.

Breaking Through

The companies I’ve seen get past the wall share a common move: they name the constraint before deploying resources.

Not “we need more people.” Instead: “Our CTO spends 40% of their time on non-product firefighting. That’s the constraint.”

Naming it changes everything. You stop solving “growth” in the abstract. You solve one specific bottleneck that’s capping your team’s ability to focus on product.

Then they fix systems before hiring. Every operational bottleneck you automate is a hire you don’t need to make. And unlike a hire, automation reduces coordination overhead instead of adding to it.

The math is straightforward. If your senior team spends 60% of their time on non-product work, that’s 60% of a CHF 180k salary going to tasks that don’t move the company forward. Fix the top three time sinks and you’ve freed up more capacity than a new hire would bring, without the onboarding curve.

And they start small. No 12-month roadmap. No strategy deck that pulls people off product for two weeks to read. One bottleneck. One solution. Working software by the end of the week.

One solved problem creates belief. Belief creates the next solved problem.

Why This Stays Stuck

None of this is technically hard.

The hard part is cultural. The CEO who believes hiring is the answer because hiring has always been the answer. The CTO who can’t let go of the firefighting because if they don’t do it, who will. The team so deep in “keeping the engine running” that they can’t imagine a world where the engine runs itself.

The scaling wall looks like a growth problem. The bigger issue is systems. And systems can be redesigned.

One Question to Start

If you’re running a 15-35 person company and you recognize this pattern, start here: where is your CTO spending their time?

If the answer is “operational fires,” that’s your constraint. Name it. Then look at the top three tasks eating your team’s product time. Those are your targets. And ask whether you can fix one of them in a week. The answer is almost always yes.

The capability gap is real. It also closes faster than most founders expect, once they stop adding headcount and start fixing what’s underneath.

The best teams I work with don’t need more people. They need their people back on product.

Then there’s the other 90%.

The frontline. The people who actually run the business day-to-day. Their reaction to “AI adoption” ranges from a polite nod to silent dread. “Not another change initiative. We just finished the last digital transformation. Can I just do my job?”

Both sides think they’re right. Both sides are. And neither side is talking about the same thing.

The confusion nobody names

BCG’s 2025 AI at Work report found that 78% of managers use generative AI regularly. Frontline workers? 51%. And that number hasn’t moved in two years.

That gap isn’t about training budgets or tool access. It’s about a fundamental confusion baked into how we talk about AI.

When leaders say “AI adoption,” they usually mean one thing: deploying AI-powered features. Chatbots. Prediction engines. Recommendation systems. AI as the product. AI as the solution.

But there’s a whole other side of AI adoption that most companies aren’t even naming. Using AI to build better things faster. Not AI as the thing your team interacts with. AI as the way you create what your team interacts with.

A better onboarding flow. A cleaner data pipeline. A dashboard that actually answers the question someone had. None of these are “AI solutions.” But all of them can be built in days instead of months when you use AI as a development tool.

The distinction matters. Because only one of these requires your entire team to change how they work.

Two kinds of AI adoption

Let me make this concrete.

AI as solution: You deploy a chatbot that handles customer inquiries. Your team needs to learn how to manage it, train it, handle escalations. The end user interacts with AI directly. This is what most people picture when they hear “AI adoption.”

AI as development tool: You use AI to build a custom scheduling system that eliminates the three-hour weekly coordination nightmare. The end user sees a clean interface. They never touch AI. They just get their time back.

Both are real AI adoption. Both create value. But they require completely different change management approaches.

The first one demands that the 90% learn something new, trust something unfamiliar, and change their daily habits. No wonder there’s resistance.

The second one? The 90% just gets better tools. Faster. Their workflow improves without them having to become AI-literate. The “what’s in it for me?” gets answered before anyone even asks the question.

Why the echo chamber persists

The 10% who are excited about AI tend to be excited about AI-as-solution. It’s the flashy stuff. The demos. The future-is-here moments. And they talk to each other constantly. Executives validate each other. Tech leads showcase possibilities. They’re in an echo chamber of excitement.

Meanwhile, the 90% hears “AI adoption” and braces for impact. Because to them, it means learning new tools, changing processes, and wondering if they’re being replaced. Their skepticism isn’t irrational. It’s information.

Gartner predicted that [at least 30% of generative AI projects would be abandoned after proof of concept by end of 2025, citing unclear business value and escalating costs. And that number only covers the projects that got started. It doesn’t count the ones that died in the echo chamber before anyone built anything.

The pattern repeats. Excitement at the top. Resistance at the bottom. Paralysis in the middle.

The bridge is in the reframe

When you stop asking “how do we get everyone to use AI?” and start asking “what problems are we actually solving?”, something shifts.

Some of those problems will be best solved by AI-powered features. Great. Build them. But a surprising number will be best solved by solutions that are built with AI but don’t require anyone to interact with AI at all.

BCG’s report landed on the same conclusion: “Real value is generated when businesses reshape their workflows end-to-end,” not when they simply introduce AI tools into existing ways of working.

This is the reframe that bridges the echo chamber gap. You stop selling AI to the 90%. You start solving their actual problems. Sometimes AI is the solution. Sometimes AI is just how you build the solution. The team doesn’t need to know or care which one it is. They just need things to work better.

What this looks like in practice

The companies getting this right don’t start with an AI strategy document. They start with a problem. One bottleneck. One process that eats time.

Then they build. Fast.

Day one, they expand the team’s understanding of what’s possible. Not a pitch about AI. A demonstration of what it can do for THEIR specific pain points. This is where eyes open. Where frontline workers say “wait, that thing I spend three hours on every week... you could fix that?”

Days two through five, they build the fix. Some outputs are AI-powered. Some are just built faster with AI. The team leaves with working software, not a slide deck about AI strategy.

The gap between the 10% and the 90% closes not through training or mandates. It closes through proof. Through someone’s daily friction disappearing. Through getting their time back.

The question to bring to your next leadership meeting

Stop debating whether your company should “adopt AI.” That question is too vague to be useful.

Ask instead: what are the three biggest time-wasters for our frontline teams right now? Then ask: for each one, is the answer an AI-powered feature, or is it a solution that could be built faster with AI?

That distinction changes the conversation. It moves from “how do we get people to use AI” to “how do we solve problems faster.” One creates resistance. The other creates results.

The echo chamber gap doesn’t close with more excitement from the top. It closes when the 90% starts seeing their problems disappear.

And sometimes the best AI adoption happens when nobody even realizes AI was involved.

Damian Nomura helps scaling startups close the capability gap in a week. No slide decks. Working software. Follow for more.

Over the past year, I’ve run multiple hackathons where non-technical teams build real software in hours. An automated monitoring system that proactively proposes services to future clients. Fully automated video avatars that reach out to prospects with personalized messages in the prospect’s language. An applicant screening tool.

An automated client qualification system. A customized content creation engine. All built by people who had never written a line of code in their lives.

Every time, the same thing happens. The energy in the room is electric. And then it hits me.

Not one team asks about data protection. Not one asks what happens if their video avatar says something wrong, or if their screening tool discriminates, or who’s liable when the monitoring system flags a false positive. They don’t skip these questions on purpose. They don’t know the questions exist.

This is the paradox nobody’s talking about. The same AI tools that give small companies and non-technical builders unprecedented power also hand them unprecedented responsibility. And responsibility without knowledge is a dangerous combination.

The Power Is Real

Let me be clear: the competitive shift is happening, and it’s massive.

I built a client portal two weeks ago. Full authentication, database, user management. Two days. That used to require a pre-project budget, a dev team, and several weeks of scoping before a single line of code got written.

A colleague shared data from CJS Agency, the company behind GoDaddy’s website. They cut 50% of their workforce. Same revenue. They shifted their entire business model from one-time project fees to revenue-share and equity deals with builders. The agency model itself is being disrupted.

And it’s not just agencies. Small companies now hold structural advantages that enterprise can’t match. No legacy systems to maintain. No approval hierarchies to navigate. No multi-culture disasters from forced acquisitions. Pure agility. One subscription. Four parallel sessions. The output of a team.

You don’t fight the big ones. You just provide real value at a fraction of their budget. They’ll struggle on their own.

68% of U.S. small businesses now use AI regularly, up from 48% just a year ago. This isn’t hype. It’s a structural inversion. Small is becoming the advantage.

But Power Without Knowledge Is a Problem

And this is where it gets uncomfortable.

Professional development teams have entire functions dedicated to what non-technical builders skip. Security reviewers who check for vulnerabilities before deployment. Compliance officers who ensure GDPR and data protection requirements are met. Legal counsel who assess liability exposure. QA engineers who test edge cases. These roles exist because decades of software failures taught us they’re necessary.

Non-technical builders skip the entire curriculum. Not because they don’t care. Because they don’t know it exists. If you’ve never worked in software, you don’t know it needs security review. The same way someone who’s never built a house doesn’t know about load-bearing walls. You can’t check for something you’ve never heard of.

Veracode’s 2025 GenAI Code Security Report] tested over 100 large language models across 80 coding tasks. The finding: AI-generated code failed security tests in 45% of cases. Nearly half the time, the code contained vulnerabilities from the OWASP Top 10, the industry’s standard list of critical security flaws.

And here’s what should concern you: the models got better at writing functional code. They did not get better at writing secure code. Speed improved. Safety didn’t.

The Liability Chain Nobody Talks About

Right now, there’s a gap in accountability that most builders don’t even see.

The AI providers have their disclaimer: “AI can make mistakes. Verify the output.” That language exists for a reason. It shifts liability from the platform to whoever deploys the code.

The builder says: “I didn’t know.” Genuine ignorance. Not malice, not negligence in the traditional sense. They simply weren’t aware that their coaching bot could give harmful advice, that their health tracker wasn’t encrypting user data, or that their financial tool was storing credentials in plain text.

The user? They just got harmed.

So who pays?

Right now, often nobody. The legal frameworks haven’t caught up. But they will. The Colorado AI Act, effective in 2026, already imposes a duty of reasonable care on deployers of high-risk AI systems. The EU AI Act is applying similar principles. The regulatory machinery is warming up.

The first serious incident involving a vibe-coded app will accelerate everything. A health app that gives dangerous advice. A financial tool that exposes personal data. A coaching bot that drives someone to harm. When that happens, regulation won’t just target the app. It could stifle the entire builder movement. The same democratization that makes this moment so exciting could get locked down because a few people built fast without building responsibly.

The Safety Manual That Should Exist

So what do you actually need to know before shipping?

Not four hundred things. Four things.

1. Does your app handle personal data? If yes, you’re likely subject to GDPR (or your local equivalent). That means consent, encryption, the right to deletion, and a data processing record. Most vibe-coded apps handle personal data. Most builders never check.

2. What happens when your app is wrong? If your app gives advice, makes recommendations, or processes anything related to health, finance, or legal matters, you need to think about the consequences of bad output. Not “what if it glitches” but “what if someone acts on wrong information.” This isn’t hypothetical. It’s happening.

3. Who can access what? Access control is the thing non-technical builders get wrong most often. OWASP created an entire Top 10 security risk list specifically for low-code/no-code platforms, and excessive permissions and account impersonation sit near the top. If everyone who uses your app can see everyone else’s data, you have a problem.

4. Have you tested it like someone who wants to break it? A few weeks ago, I asked Claude to pen-test my client portal. Unprompted, it offered to check for vulnerabilities. It found issues I wouldn’t have thought to look for. The AI that helped me build it also helped me secure it. Most builders never take this step. They ship and move on.

That’s just enough. Everything else is noise. For now.

Build Fast AND Build Responsibly

The safeguard isn’t slowing down. I’m not arguing for less building. I’m arguing for informed building.

The good news: the same AI tools that create the risk can help manage it. You can ask Claude or ChatGPT to review your code for GDPR compliance. You can run security scans in natural language. You can ask “what regulations apply to an app that handles health data in the EU?” and get a reasonable starting point.

But you have to know to ask. That’s the gap.

When I build automation systems for clients through my Done-for-You work, this is baked in. Security review, compliance checks, proper data handling. Not because the client asked for it. Because they shouldn’t have to ask. That’s what professional building looks like. The safeguard is part of the delivery, not an afterthought.

For those building themselves, my Sprint program teaches teams to move fast and build responsibly. Speed and safety aren’t opposites. They’re partners. The teams that learn both will outlast the ones that only learned speed.

The Question That Matters

We’re at a remarkable moment. Small companies can compete with giants. Non-technical founders can build real products. Solo consultants can ship what used to require entire engineering departments.

This power is real. And it’s not going away.

But the builders who will thrive long-term aren’t the ones who ship fastest. They’re the ones who know what to check before they ship. The ones who build the house and understand which walls are load-bearing.

AI gave you superpowers. The safety manual is your responsibility.

The question is whether you’ll read it before or after something goes wrong.

Damian Nomura helps companies adopt AI through a human-centered approach. His Done-for-You Automation builds systems with security and compliance baked in, and his 5-Day Sprint teaches teams to build fast and responsibly. Swiss Ambassador for the Responsible AI Governance Network.

Follow for weekly essays on AI adoption that’s Simple. Clear. Applicable.

I grew up half-Japanese in Switzerland with an adopted sister from Cameroon. That combination taught me something about perspective that no book ever could.

My sister experienced the kind of racism most people picture when they hear the word. People looking down. Assumptions about intelligence. Doors that stayed closed. The negative kind.

I got the other version. The kind nobody talks about. People looking up. Assumptions about discipline, precision, cultural sophistication. “Oh, Japan!” The positive kind.

Both are the same thing. Both reduce a person to a category. And both come from the same place: a system that only knows how to see people through a narrow lens.

I keep thinking about that word. Lens. Because the same problem that shaped my childhood is now running through every AI system your company deploys.

The Coded Gaze

In 2018, MIT researcher Joy Buolamwini ran a simple experiment. She pointed three commercial facial recognition systems at a diverse set of faces and measured how often they got it wrong.

The results should have stopped the industry cold.

For lighter-skinned men, the error rate was 0.8%. For darker-skinned women, it climbed to 34.7%. One of the systems was essentially flipping a coin.

Buolamwini had discovered this problem years earlier, in the most direct way possible. She was a graduate student at the MIT Media Lab, working with facial recognition software that couldn’t detect her face. She had to put on a white mask for the system to see her.

She called this the coded gaze: the embedded perspective in AI systems that reflects the worldview of whoever built them.

The training data told the story. One major company’s face recognition dataset was 77% male and 83% white. The system worked beautifully. For people who looked like the people who built it.

When Blind Spots Get Real

This isn’t abstract. Robert Williams was arrested in Detroit in 2020 after a facial recognition system misidentified him as a shoplifting suspect. He was handcuffed in front of his daughters. Porcha Woodruff, eight months pregnant, was arrested for a carjacking in 2023 based on the same technology. Nijeer Parks spent ten days in jail in New Jersey before the case fell apart.

All three are Black. All three were innocent. All three were failed by systems trained on data that didn’t adequately represent them.

And facial recognition is just the visible edge. Recruiting tools that filter out candidates with “foreign-sounding” names. Credit scoring systems that penalize zip codes as proxies for race. Healthcare algorithms that systematically underestimate pain in Black patients. The coded gaze runs through every AI application that was trained on data reflecting a narrow slice of human experience.

Last week I wrote about how “hallucination” is [the most effective marketing term in AI history](https://mundaine.substack.com/). A nice word for a product failure. Coded bias is a different kind of failure. Not a random glitch. A systematic blind spot built into the foundation.

The Bridge: Same Problem, Different System

Now, here’s where it gets interesting.

Companies hear about coded bias and think: “We need to audit our AI tools.” Good instinct. But they’re only solving half the problem.

Because there’s another system in your company that suffers from the same blind spot. A system that also defaults to familiar patterns, rewards what it already recognizes, and systematically filters out perspectives it wasn’t designed to see.

Your hiring process.

Specifically, how you build your AI team.

The bias coded into your AI tools and the bias coded into your AI team have the same root cause: homogeneous perspectives producing blind spots that nobody in the room can see. Because everyone in the room sees the same way.

The Inexperience Advantage

When companies look for help with AI strategy, they almost always reach for the same type of person. Industry veteran. Deep domain expertise. Someone who’s “done this before.”

It feels safe. It feels smart. And it often leads to the same conventional thinking that created the blind spot in the first place.

Research from Harvard backs this up. Lars Bo Jeppesen and Karim Lakhani studied over 12,000 scientists solving problems through open innovation challenges. Their finding was counterintuitive: the further a solver’s expertise was from the problem’s domain, the more likely they were to find a winning solution. Outsiders outperformed insiders. Consistently.

Why? Because insiders know “how it’s always been done.” They’ve exercised the same patterns thousands of times. They carry assumptions so deep they don’t even recognize them as assumptions. An outsider doesn’t have that baggage. They need things to make sense from the ground up. They ask the questions that everyone else stopped asking years ago.

We celebrate first principles thinking. We praise design thinking. But then we go hire the person with twenty years of industry experience to lead our AI transformation. And we wonder why we end up with the same approaches everyone else has.

A Harvard Business Review analysis put numbers to this. In experiments conducted in Texas and Singapore, participants on diverse teams were 58% more likely to price stocks correctly than those on homogeneous teams. Homogeneous groups weren’t just less innovative. They made more factual errors. They were worse at processing information. The similarity that felt like alignment was actually a blind spot.

Two Audits, One Principle

So where does this leave you?

With two audits to run. Not one.

Audit your AI tools. Whose perspective does the training data carry? What edge cases is the system failing on? Buolamwini’s Gender Shades study forced IBM, Microsoft, and Amazon to revisit their facial recognition systems. Your company may not build facial recognition, but every AI tool you deploy carries someone’s assumptions. Who’s testing those assumptions before they touch your customers?

Audit your AI team. Who’s in the room when you make AI decisions? If everyone at the table has the same background, the same industry experience, the same mental models, you’re running a homogeneous team on a problem that requires diverse thinking. You need the person who asks “why are we doing it this way?” Not because they’re difficult. Because they genuinely don’t know. And that not-knowing is where breakthroughs live.

The principle underneath both is simple: perspective diversity is a debugging tool. The more perspectives you bring to a system, the more edge cases you catch. The more blind spots you surface. Whether the system is an algorithm or a leadership team.

What This Means in Practice

This isn’t activism. For me, it’s lived experience. Growing up between two kinds of racism taught me that the problem is never just the negative bias or the positive bias. The problem is the narrow lens. Any narrow lens.

And the solution isn’t awareness. Awareness doesn’t debug code. Action does.

When I run a Sprint with a client, one of the things we stress-test is perspective. Not just “does this AI tool work?” but “does it work for everyone it needs to serve?” And when I do Executive Sparring with leaders, part of the value is that I bring an outside perspective to their inside problem. Not because I know their industry better than they do. Because I don’t. And that’s the point.

The companies that will get AI right aren’t the ones with the biggest budgets or the most advanced tools. They’re the ones willing to look at their tools and their teams through a wider lens.

Ask yourself two questions:

1. Whose perspective is missing from your AI systems?

2. Whose perspective is missing from the room where you decide?

If the answer to both is “I don’t know,” you’ve just found your most important blind spot.

Damian Nomura helps mid-sized companies adopt AI through a human-centered approach. His 5-Day Sprint gets teams from stuck to pilot, and Executive Sparring brings outside perspective to inside challenges. Swiss Ambassador for the Responsible AI Governance Network.

Follow for weekly essays on AI adoption that’s Simple. Clear. Applicable.

I’ve been thinking about language. Not the kind machines generate, but the kind we use to describe them.

Somewhere along the way, the AI industry settled on “hallucination” to describe what happens when a language model presents false information as fact. And I think that word choice might be the single most effective piece of marketing in AI history.

Think about it. “Hallucination” borrows from human experience. It softens the blow. It makes a fundamental system limitation sound like a relatable, almost endearing quirk. “Oh, the AI hallucinated again.” As if it had a bad dream. As if it’s just a minor thing that happens sometimes.

A product is generating false facts and presenting them as truth. Confidently. Fluently. With no indication that anything is wrong.

Call it what it is. A product failure.

The Terminology Does Real Work

This isn’t just semantics. The word “hallucination” does three specific things that benefit AI companies and hurt everyone else.

It humanizes the machine. When we say a system “hallucinates,” we unconsciously attribute human qualities to it. We forgive it, the way we’d forgive a friend who misremembers a detail. This is software producing unreliable output, not a person having a momentary lapse.

It softens the severity. A hallucination sounds temporary and accidental. A product showing false facts as truth sounds like a defect you’d return the product for. The framing matters. One makes you shrug. The other makes you demand accountability.

It obscures responsibility. The word creates a strange gray zone around fault. But when a product delivers incorrect outputs presented as fact, accountability becomes much clearer. The manufacturer has a reliability problem.

Researchers at Oxford University, published in Nature, prefer a more precise term: confabulation. They define these as “arbitrary and incorrect generations” produced by language models. No human qualities implied. No cute spin. Just a technical description of what actually happens.

Why This Happens (And Why It Won’t Fully Stop)

To understand why this matters for your business, you need to understand one thing about generative AI that most people overlook.

These systems are probabilistic, not deterministic.

Traditional software is deterministic. Same input, same output. Every time. That’s what makes it reliable. It’s why your accounting software always calculates the same total from the same numbers.

Generative AI works differently. It predicts the next most likely word based on probability distributions learned from training data. Same question, asked twice, can produce different answers. Not because the system is broken. Because that’s how it’s designed.

This is where it gets important for business leaders.

Causality is binary. In the real world, something either happened or it didn’t. A legal precedent either exists or it doesn’t. A financial figure is either correct or it isn’t. Facts are true or false.

But LLMs don’t verify truth. They estimate probability. The gap between probabilistic generation and binary truth is exactly where “hallucinations” live. They’re not bugs. They’re the natural output of a system that was never designed to determine what’s true. Only what’s statistically plausible.

A 2025 survey in *Frontiers in AI* puts it plainly: “Hallucination is an inherent byproduct of language modeling that prioritizes syntactic and semantic plausibility over factual accuracy.”

Read that again. Inherent. Not occasional. Not fixable with the next update. Inherent.

The Confidence Problem

If the system at least signaled uncertainty, you could build around it. But it does the opposite.

Research from 2025 shows that AI models are significantly more likely to use confident language when generating incorrect information than when providing accurate answers. Phrases like “definitely,” “certainly,” “without doubt” appear more often in false outputs than in correct ones. An OpenAI research paper confirmed the root cause: LLMs are trained to reward confident answers over honest uncertainty, which means the system learns to bluff rather than say “I don’t know.”

The system is most confident when it’s most wrong.

For business leaders, this inverts the natural trust signal. In every other context, confidence correlates with reliability. With generative AI, it can correlate with error. If your team is using AI outputs without verification layers, they’re more likely to trust the responses that are least trustworthy.

Real-World Damage, Not Theoretical Risk

This isn’t hypothetical. The consequences are already here.

A Stanford HAI study tested AI tools specifically built for legal research. Tools marketed as reliable. Tools using Retrieval-Augmented Generation to reduce errors. The results: Lexis+ AI produced incorrect information more than 17% of the time. Westlaw’s AI-Assisted Research hallucinated over 34% of the time. General-purpose chatbots? Between 58% and 82% on legal queries.

These aren’t fringe tools. These are the industry standard for legal research.

As of late 2025, researchers tracked over 120 court cases worldwide involving AI-generated hallucinations. 91 in the US alone. 128 lawyers implicated. Sanctions ranging from $100 to $31,100.

The judicial message is consistent: if you submit machine-generated fiction under your name, it’s still your filing. The machine doesn’t face consequences. You do.

An Important Distinction

Not all AI works this way. This is specific to generative AI, the large language models powering ChatGPT, Claude, Gemini, and most of the business tools you’re adopting right now.

Predictive AI, classification systems, rule-based automation: these operate deterministically or with well-bounded probabilistic ranges. They’re different tools for different purposes.

The problem isn’t AI broadly. It’s deploying one specific type of AI while treating it like another. It’s expecting deterministic reliability from a probabilistic system because we never stopped to understand the difference.

What This Means for You

If you’re deploying generative AI in your business, three questions matter more than any feature comparison.

1. Where are you trusting outputs without verification?

Map every workflow where AI-generated content reaches a customer, a partner, or a decision without a human checking it. Those are your risk points. Not because AI is bad. Because probabilistic systems require verification by design.

2. Does your team understand what they’re using?

Not at a technical level. At a conceptual level. Do they know that the system estimates probable answers rather than looking up correct ones? That distinction changes behavior. People who understand it verify. People who don’t trust blindly.

3. Are you building on the right foundation?

Some use cases are excellent fits for generative AI. Drafting, brainstorming, summarizing, exploring ideas. Others need deterministic reliability. Reporting facts, citing sources, making claims. Matching the right type of AI to the right type of task is the difference between value and liability.

Rename the Problem, See It Clearly

Language shapes understanding. And “hallucination” has shaped ours in exactly the wrong direction.

It made a product limitation sound like a personality trait. It turned accountability into ambiguity. It let companies ship probabilistic systems into deterministic workflows without anyone asking the obvious question: should we trust output that the system itself can’t verify?

The next time someone tells you their AI “hallucinated,” try this reframe:

“The product generated false information and presented it as truth.”

See how different that feels? See how it changes the conversation?

That’s the point. The technology isn’t the problem. The technology is doing exactly what it was designed to do. The problem is the language that keeps us from seeing it clearly.

I help leaders understand what AI actually is before they decide what to do with it. If your team is building on AI without understanding its foundations, that gap will cost you. Mundaine offers Sprint workshops and Executive Sparring to close it.

Simple. Clear. Applicable.*

Sources

1. Farquhar et al. (2024). “Detecting hallucinations in large language models using semantic entropy.” *Nature*, Vol 630. Oxford University.(https://www.nature.com/articles/s41586-024-07421-0)

2. “Survey and analysis of hallucinations in large language models.” *Frontiers in AI* (2025). Japan Advanced Institute of Science and Technology.(https://www.frontiersin.org/journals/artificial-intelligence/articles/10.3389/frai.2025.1622292/full)

3. Magesh, Surani, Dahl et al. (2024). “AI on Trial: Legal Models Hallucinate in 1 out of 6 (or More) Benchmarking Queries.” Stanford HAI / RegLab.(https://hai.stanford.edu/news/ai-trial-legal-models-hallucinate-1-out-6-or-more-benchmarking-queries)

4. Kalai & Nachum (2025). “Why Language Models Hallucinate.” OpenAI.(https://openai.com/index/why-language-models-hallucinate/)

5. “AI Hallucination Statistics 2026.” All About AI.(https://www.allaboutai.com/resources/ai-statistics/ai-hallucinations/)

Your AI consultant is making you dumber.

Not on purpose. They’re probably quite smart. They’ve helped you save 40 hours a month. Your team generates reports in minutes instead of hours. The efficiency gains look great on the quarterly deck.

But here’s what they never asked you: “What will you do with those 40 hours?”

And that question is worth more than every hour you saved.

The Celebration Trap

I see this pattern constantly. Company implements AI. Time savings appear. Everyone celebrates. Then those saved hours quietly fill with more meetings, more email, more busywork. Six months later, nobody can point to what actually changed.

The efficiency gains evaporated. They got absorbed back into the noise.

This is the celebration trap. You measure inputs (time saved) instead of outputs (value created). You congratulate yourself for running faster without asking where you’re running to.

BCG surveyed over 1,000 executives across 59 countries. 74% struggle to achieve and scale value from AI. ServiceNow’s AI Maturity Index found that fewer than 1% of organizations even crack the midway point on their maturity scale. The average score dropped 9 points year-over-year.

Companies aren’t failing because they can’t save time. They’re failing because they don’t know what to do with it.

The Question Nobody Asks

Here’s the uncomfortable truth about most AI consulting engagements.

They focus on the wrong half of the equation.

The hard part isn’t finding where AI can save time. That’s the easy part. Any decent consultant can audit your processes and find automation opportunities. The hard part is the question that comes next:

”What will we do with the freed capacity?”

This is the leverage question. And almost nobody asks it.

I sat with a client last year who’d implemented AI across their customer service operations. They were saving 40 hours per month. I asked what they were doing with those hours.

Silence.

They hadn’t thought about it. The hours just... got absorbed. More tickets. More meetings. More of the same work that used to fill the day.

That’s not ROI. That’s just redistribution.

Savings vs. Leverage

Let me make this concrete.

Saving 10 hours a week on report generation is not valuable by itself. It’s only valuable if you convert those hours into something that moves the business forward.

The ROI of AI isn’t in the savings. It’s in what the savings enable.

Four conversion paths:

Growth: Those 10 hours become more client outreach. More sales conversations. More pipeline = revenue leverage.

Quality: Those 10 hours become deeper work on complex cases. Better outcomes. Fewer errors = excellence leverage.

Expansion: Those 10 hours become time to launch something new. A product. A service. A market = opportunity leverage.

Retention: Those 10 hours mean your best people stop working nights and weekends. They stay = human leverage.

Each path converts the same saved time into completely different outcomes. But you have to choose one. Deliberately. Before you start.

Why This Gets Missed

There’s a reason consultants don’t push the leverage question.

It’s hard.

Identifying efficiency gains is technical work. You audit processes, find bottlenecks, implement automation. It’s measurable. It’s defensible. It fits neatly into a project scope.

The leverage question is strategic work. It requires understanding the company’s direction, its constraints, its competitive position. It means asking executives uncomfortable questions about priorities. It means connecting AI initiatives to business outcomes that might be two or three steps removed from the automation itself.

Most consultants stay in their lane. They deliver the efficiency gains, declare victory, and move on.

Which is why 74% of companies struggle to see value.

The Maturity Illusion

Let’s have a look at what the data tells us.

90% of C-suite executives believe their people are ready to use AI effectively. Only 70% of employees agree. And when you dig deeper, only 8% of executives have sufficient AI literacy to actually guide these initiatives.

Organizations spend three times more of their AI budget on technology than on people.

This creates a dangerous illusion. Leadership thinks they’re further along than they are. They see the tools deployed. They see the time savings. They assume value is being created.

But value doesn’t come from deployment. Value comes from leverage.

The companies winning with AI aren’t the ones saving the most time. They’re the ones converting saved time into strategic advantage.

Connecting to Corporate Strategy

The leverage question forces alignment.

When you ask “What will we do with the freed capacity?” you’re really asking: “What does this company need most right now?”

Is it growth? Then saved hours become customer acquisition.

Is it profitability? Then saved hours become efficiency that drops to the bottom line.

Is it innovation? Then saved hours become R&D bandwidth.

Is it talent retention? Then saved hours become better work-life balance.

The answer depends on your strategy. And if your AI initiatives aren’t connected to your strategy, you’re just automating in circles.

This is why the first conversation shouldn’t be about AI capabilities. It should be about business priorities. What does the company need? Where is the competitive pressure? What would change the game?

Then work backward to AI.

Before You Start Your Next AI Initiative

Ask the leverage question first. Not after. Before.

Before you scope the project. Before you hire the consultant. Before you deploy the tool.

“If this works, what will we do with the freed capacity?”

Write down the answer. Make it specific. “We will use 15 reclaimed hours per week to increase outbound sales calls by 30%.” Or: “We will reallocate two FTEs to the product development team.” Or: “We will reduce average weekly hours from 50 to 45 without cutting output.”

If you can’t answer clearly, you’re not ready to start.

The time savings will evaporate. The efficiency gains will get absorbed. And six months from now, you’ll be in that 74% wondering why AI didn’t deliver the value everyone promised.

The Real Test

Here’s how you know if your AI adoption is working.

Not: “How many hours did we save?”

But: “What did we build with those hours?”

The winners aren’t the ones who saved the most time. They’re the ones who converted it into something that matters.

Speed without direction is just motion. Efficiency without leverage is just busyness with better tools.

Your AI consultant gave you hours back. The question is whether you’re investing those hours or wasting them.

That’s on you. Not them.

Ready to connect AI initiatives to actual business outcomes?

Let’s talk about a Sprint week or Executive Sparring session where we don’t just find efficiency gains. We build the leverage strategy that converts them.

Simple. Clear. Applicable.

Sources

1. BCG (October 2024). “AI Adoption in 2024: 74% of Companies Struggle to Achieve and Scale Value.” Survey of 1,000+ executives across 59 countries. [BCG Press Release](https://www.bcg.com/press/24october2024-ai-adoption-in-2024-74-of-companies-struggle-to-achieve-and-scale-value)

2. ServiceNow & Oxford Economics (2025). “Enterprise AI Maturity Index 2025.” Survey of 4,500 executives. Fewer than 1% scored over 50 on the 100-point maturity scale. Average scores declined 9 points year-over-year. [ServiceNow](https://www.servicenow.com/workflow/hyperautomation-low-code/enterprise-ai-maturity-index-2025.html)

3. Accenture (2025). Study cited in Fortune showing 90% of C-suite believe workers are AI-ready while only 70% of employees agree. Organizations spend 3x more AI budget on technology than people. [Fortune](https://fortune.com/2025/01/17/c-suite-leaders-believe-workers-ready-to-use-ai-employee-training-skills-gap/)

4. MIT Sloan Management Review (2024). Research finding only 8% of board-level executives have substantial AI literacy despite widespread confidence claims.

5. Faros AI (2025). “The AI Productivity Paradox.” 75%+ of developers use AI coding tools, but most organizations see no measurable performance gains. [Faros AI](https://www.faros.ai/blog/ai-software-engineering)

74% of companies struggle to achieve and scale value from AI.

That’s not my number. That’s BCG surveying 1,000 executives across 59 countries.

And here’s the uncomfortable part: Most of these companies aren’t failing because they’re doing AI wrong. They’re failing because they never actually started. They’re still “getting ready.” Still planning. Still in committee meetings about their AI strategy.

The world moved on.

The Mental Model That’s Killing You

This is a pattern I keep seeing repeating. Executives approach AI with the same mental model they used for IT projects in 2010.

Big upfront planning. Lengthy requirements phases. 12-month timelines before anything ships. Massive teams. Careful, slow, expensive. Or at least that’s the mindset they approach it.

That model made sense when technology was expensive to change. When getting it wrong meant costly rework. And seldomly a solution went live without rework in the clip. When deployment meant physical servers and permanent decisions.

But that’s not how it works anymore.

The technology has changed. Dramatically. The question is whether your mindset has caught up.

A Conversation in Spain

I’m in Spain this week, catching up with a friend who runs a startup.

In June last year, he was nowhere near AI. Not even on his radar. Then 2025 happened. A brutal year for him. Market pressure. A sophisticated cyber attack that nearly took his company down. The kind of year that forces you to rethink everything.

Yesterday, he told me he’s deploying two AI solutions tomorrow. Not “exploring.” Not “piloting.” Deploying. Into production. And he’s already planning the next experiments.

Then he asked me something that surprised me.

“You know, I struggle with having an overview over everything in AI. Can you help me?”

My answer: “I could, but you would lose focus. The way you’re doing it is exactly how it works. Just keep going like that. The only thing to be aware of is to keep evaluating the results and iterate where needed.”

He doesn’t need a comprehensive AI strategy document. He doesn’t need to understand the full landscape. He needs to keep doing what he’s doing: picking problems, building solutions, testing them, and iterating.

That’s the speed lane. And he’s on it.

Why IT Projects Used to Be Slow

Traditional IT projects were slow for legitimate reasons:

Waterfall methodology - You planned everything upfront because changes were expensive. Once you started building, deviations meant rework, delays, and budget overruns.

Fear of getting it wrong - Deploying meant committing. Rolling back was painful, sometimes impossible. Better to plan for 6 months than ship something broken.

Infrastructure constraints - Physical servers. Long procurement cycles. Dependencies that took weeks to provision.

Limited iteration capability - Testing required dedicated environments. Feedback loops measured in sprints, not hours.

These weren’t irrational fears. They were responses to real constraints.

But those constraints are mostly gone.

What Changed Everything

Three shifts collapsed the timeline:

1. AI-assisted development

GitHub’s 2024 data shows 92% of developers now use AI coding tools. Stack Overflow reports 76% save at least 30% of their time on routine programming tasks.

AI doesn’t just write code faster. It eliminates the bottleneck of translating ideas into implementation. You describe what you want. It builds the first version. You iterate.

2. Modular systems

Modern architecture means components snap together. APIs connect services. You’re not building from scratch every time. You’re assembling.

What took months of custom development now takes days of configuration and connection.

3. Iteration as default

Cloud deployment means you ship, test with real users, and improve. The feedback loop collapsed from months to hours. You don’t need to be right the first time. You need to be fast enough to learn.

McKinsey reports a 55% reduction in development time through AI-assisted coding. Y Combinator startups are delivering MVPs in 6 weeks that used to take 6 months.

What My Friend Actually Did

He didn’t hire an AI consultant to map out his strategy. He didn’t spend three months building an AI roadmap. He didn’t wait until he “understood AI” before starting.

He picked a problem. Built something. Tested it. Learned. Moved to the next one.

No lengthy requirements document. No architecture review committee. No 3-month planning phase.

Start. Build. Test. Ship. Learn.

If something breaks, fix it. Today. Not next quarter.

That’s not reckless. That’s the new standard.

The Competitive Math

Here’s the math that should worry you.

If your competitor ships and tests 4 ideas per month while you’re still in planning committees, they’re learning 12 times faster than you are per quarter.

Every week you spend “getting ready,” they’re shipping, testing, and iterating. Every month you spend in planning committees, they’ve built and discarded 5 approaches that didn’t work and found 3 that did.

Speed isn’t about being sloppy. Speed is about compressing the learning cycle. The companies that win aren’t the ones with the best strategy document. They’re the ones who figure out what works before everyone else does.

And the only way to figure out what works is to try things. Fast.

The Mindset Shift

Speed is possible now. But only if you update your mental operating system.

Stop treating AI like a 2-year IT project. Treat it like a series of small experiments. Ship something in a week. Learn what works. Build on it.

Stop waiting for perfect requirements. You can’t know the perfect requirements until you’ve seen what’s possible. Build something rough. Show it to users. Let reality refine your understanding.

Stop protecting your timeline. The timeline is the enemy. Every day you spend planning is a day your competitors spend learning.

My friend in Spain figured this out the hard way. After one of the toughest years of his business life, he stopped waiting and started building. Tomorrow, two AI solutions go live.

Speed is possible. But only if you know what to speed toward.

If you’ve been waiting to “get ready” for AI, consider this your wake-up call.

Speed isn’t sloppy. It’s the new standard. And the longer you wait to adopt it, the harder the gap becomes to close.

Ready to move faster?

Reach out about a Sprint week where we build working prototypes for your business.

Simple. Clear. Applicable.

Sources

1. BCG (October 2024). “AI Adoption in 2024: 74% of Companies Struggle to Achieve and Scale Value.” Survey of 1,000 executives across 59 countries. [BCG Press Release](https://www.bcg.com/press/24october2024-ai-adoption-in-2024-74-of-companies-struggle-to-achieve-and-scale-value)

2. GitHub (2024). Developer survey showing 92% of developers use AI coding tools. Via [Intersog](https://intersog.com/blog/strategy/ai-driven-software-development-accelerating-innovation-in-2025/)

3. Stack Overflow (2024). Survey reporting 76% of developers save at least 30% of time with AI assistants. Via [Intersog](https://intersog.com/blog/strategy/ai-driven-software-development-accelerating-innovation-in-2025/)

4. McKinsey (2024). Research showing 55% reduction in development time through AI-assisted coding. Via [Advancio](https://www.advancio.com/from-6-months-to-6-weeks-how-ai-is-speeding-up-software-development/)

5. Y Combinator (2024). Data on startups delivering MVPs in 6 weeks versus traditional 6-month timelines. Via [Advancio](https://www.advancio.com/from-6-months-to-6-weeks-how-ai-is-speeding-up-software-development/)

Everyone’s talking about AI agents.

Autonomous systems. Multi-step reasoning. The future of work.

And I get it. The demos are compelling. The vision is exciting.

But here’s what nobody’s saying: if you can’t prove value from a simple AI workflow in 7 days, building an agent isn’t going to save you.

It’s going to bury you.

The Experimentation Trap

I’ve watched this pattern repeat across dozens of companies:

A team gets excited about AI. They launch a “pilot.” Six months later, they still can’t tell you if it worked.

Not because the AI failed. Because they never defined what success looked like.

They weren’t running experiments. They were just trying things.

And here’s the uncomfortable truth: trying things isn’t the same as proving things.

Experimentation is a scientific word. Most companies aren’t using it scientifically.

What the Data Actually Shows

MIT just released a study that should terrify every executive investing in AI:

Only 5% of AI pilots achieve rapid revenue acceleration.

Think about that. Ninety-five percent are stalling out. Not because the technology doesn’t work, because companies can’t connect the activity to the outcome.

It gets worse:

- 46% of AI proof-of-concepts get scrapped before production (S&P Global Market Intelligence, 2025)

- 30% of GenAI projects will be abandoned after POC by end of 2025 (Gartner)

- Companies that do make it to production? It takes them an average of 8 months to get there (Gartner)

This isn’t a technology problem. It’s a methodology problem.

Companies are launching pilots in “safe sandboxes” with no clear path to deployment. The tech works in isolation, but when it’s time to go live, they hit a wall: integration, compliance, training, measurement.

Gartner calls it “pilot paralysis.”

I call it what happens when you skip the groundwork.

Experimentation vs. Trying Things

Here’s the difference:

Trying things looks like this:

- “Let’s give the sales team access to ChatGPT and see what happens.”

- “We’ll pilot this AI assistant for 3 months and evaluate.”

- “Let’s experiment with AI-generated content.”

Proving things looks like this:

- “We believe AI-assisted email drafts will reduce response time by 40%. We’ll measure current baseline (2.5 hours average), test for 7 days, and evaluate against our decision criteria: if response time drops below 1.5 hours, we deploy company-wide.”

See the difference?

One is hope. The other is science.

And science requires structure.

The 5 Questions That Turn Random Trying Into Real Experimentation

If you can’t answer these five questions before you start, you’re not experimenting—you’re just burning time:

1. HYPOTHESIS: What do you believe will improve?

Not “let’s see what happens.” What specifically do you think will get better?

- Faster report creation?

- Fewer customer support emails?

- Higher proposal win rates?

Name it. Make it concrete.

2. METRIC: How will you measure it?

“Productivity” isn’t a metric. “Time to first draft” is.

If you can’t measure it, you can’t prove it. And if you can’t prove it, you can’t scale it.

3. BASELINE: What’s the current state?

You can’t know if something improved if you don’t know where you started.

How long does the task take now? How many errors occur? What’s the current cost?

Measure it. Before you change anything.

4. TIMEFRAME: How long will you test?

Here’s the thing: 7 days beats 7 months.

Most AI experiments don’t need months. They need days. A focused week with clear measurement tells you everything you need to know.

If it doesn’t show value in 7 days, extending it to 90 won’t save it.

5. DECISION CRITERIA: What makes this a success?

This is where most pilots die. Nobody decides upfront what “good enough to deploy” actually means.

- 20% time savings? 40%? 60%?

- 90% accuracy? 95%?

- Positive user feedback from 70% of testers?

Set the threshold. Before you start. Then stick to it.

The PhD Trap: Why Overthinking Kills Momentum

I’ve seen teams spend 3 months designing the “perfect experiment.”

They debate variables. They map dependencies. They build elaborate measurement systems.

And by the time they’re ready to start, the business has moved on.

Here’s what they miss: you don’t need a perfect experiment. You need a clear one.

The 5 questions above? You can answer them in 30 minutes.

Then you run it. For a week. And you know.

Speed without sloppiness. That’s the balance.

Don’t overthink the experiment design. Just make sure you have one.

Why 7 Days Beats 7 Months

Every company I work with asks: “How long should we pilot this?”

My answer: As short as possible while still being valid.

For most AI workflows, that’s 7 days. Maybe 14 if you need statistical significance.

And this is why short timeframes work:

1. Urgency forces clarity

When you only have a week, you can’t afford vague goals. You have to define success upfront.

2. Feedback loops are faster

Problems surface immediately. You fix them in real-time instead of discovering them in month 5.

3. The opportunity cost is lower

If it doesn’t work, you’ve lost a week—not a quarter.

4. Momentum doesn’t die

Three-month pilots lose steam. People forget why they started. Priorities shift.

A week? Everyone stays focused.

The Real Cost of Skipping This

Let’s do the math:

- Average time from POC to production: 8 months (for projects that make it)

- Average percentage that make it: 54% (industry average)

- Cost of a failed AI pilot: $4M - $20M (Gartner)

Now imagine a different path:

- Week 1: Run structured 7-day experiment with 5-question framework

- Week 2: If it works, deploy. If it doesn’t, kill it or iterate.

- Week 3: Start the next one.

By the time a traditional pilot finishes planning, you’ve already run 12 experiments and deployed the 3 that worked.

That’s the power of structured speed.

What This Means for AI Agents (And Why You’re Not Ready)

Back to where we started: AI agents.

Agents are powerful. Autonomous. Multi-step. Exciting.

They’re also the hardest form of AI to deploy successfully.

If you can’t structure a simple experiment around a single AI task, like “draft email replies” or “summarize meeting notes”, you have no business building an agent.

Because agents require:

- Clear success criteria (you don’t have those yet)

- Reliable measurement systems (you haven’t built them)

- Failure recovery processes (you haven’t tested them)

- User trust (you haven’t earned it)

All of that comes from the groundwork: small, structured, proven experiments.

Master the basics. Then build the agents.

Not the other way around.

The Quick Win Protocol: From Random Trying to Structured Proving

I built a framework for this. It’s called the AI Quick Win Protocol.

One page. Five questions. The exact structure you need to turn random experimentation into provable value.

Here’s what it includes:

The 5 Core Questions:

1. Hypothesis (what will improve?)

2. Metric (how will you measure?)

3. Baseline (what’s the current state?)

4. Timeframe (how long will you test?)

5. Decision criteria (what defines success?)

Plus the Leverage Question:

“What will we do with the freed capacity?”

Because here’s the thing: AI doesn’t just save time. It creates space.

If you don’t plan what to do with that space, it’ll just get filled with more tasks.

And you’ll be back where you started—busier than ever, wondering why AI didn’t help.

How to Get It

Comment “QUICKWIN” and I’ll send you the framework.

Use it this week. Pick one AI workflow. Answer the 5 questions. Run the experiment.

Seven days from now, you’ll know if it works.

And if it does, you’ll have proof. Not hope. Not hype.

Proof.

That’s how you move from pilot paralysis to deployment velocity.

That’s how you end up in the 5%, not the 95%.

One More Thing: Know Your Baseline

Structured experimentation starts with knowing your baseline.

Not just for individual tasks—for your entire organization’s AI readiness.

Where are you actually starting from? What’s mature? What’s missing?

I teamed up with the AI Maturity Index, building a maturity check to answer exactly that.

It’s a 10-minute assessment that gives you a clear picture of where you are—and where the gaps are.

Because you can’t improve what you can’t measure.

And you can’t measure what you haven’t baselined.

Damian Nomura helps companies adopt AI through consulting, advisory, and hands-on implementation. His approach is human-centered, focusing on fast value creation while building sustainable leadership practices. If your AI pilots keep stalling—or you’re not sure where to start—let’s talk.

Simple. Clear. Applicable.

You hired consultants. Read whitepapers. Attended webinars. Built a task force.

Six months later, you’re no closer to actually moving.

You’re not alone. 74% of companies struggle to achieve and scale value from AI. And in 2025, 42% abandoned most of their AI initiatives—up from just 17% the year before.

The problem isn’t lack of effort.

It’s that you’re trying to understand everything before you do anything.

Let me explain.

The Expertise Trap

Most executives think they (or someone in the company) need to become AI experts before they can make good decisions. So they go deep. Really deep. Either they themselves or a designated person.

They hire consultants who teach them about transformer architectures. They learn the difference between supervised and unsupervised learning. They study use cases from seventeen different industries.

And then they get lost.

Because here’s the thing: You don’t need expertise. You need just enough to decide competently.

There’s a massive difference.

What “Just Enough” Actually Means

You need to know four things. Not four hundred.

1. The basics of what AI actually is

Not the technical details. The decision-making fundamentals:

• What’s automation? (Rules-based, repeatable tasks)

• What’s AI? (Pattern recognition, prediction)

• What’s agentic AI? (AI that can take actions based on goals)

• What’s an AI agent? (Autonomous systems that make decisions and act)

That’s it. One to two hours of clear explanation beats three months of technical deep-dives.

2. What AI can actually do for your business

Not theoretical possibilities. Real capabilities:

• Where can it save time without sacrificing quality?

• Where can it surface insights you’re currently missing?

• Where can it handle volume you can’t scale manually?

You don’t need to understand how it works. You need to know what it does.

3. Where to start without betting the company

Not a comprehensive roadmap. A first experiment:

• One workflow that’s painful today

• One metric you can measure

• One week to see if it actually helps

Speed beats perfection. Always.

4. How to tell if it’s working

Not ROI projections for 2027. Clear success criteria:

• Did the thing we hoped would improve actually improve?

• By how much?

• What do we do next based on what we learned?

That’s just enough. Everything else is noise. For now.

The Data Overwhelm Problem

Here’s the uncomfortable truth: 72% of business leaders admit that the sheer volume of data prevents them from making ANY decision.

Not just AI decisions. Any decision.

And what do consultants do when executives are drowning in information? They add more information.

More frameworks. More case studies. More technical specifications. More vendor comparisons.

It’s well-intentioned. But it’s paralyzing.

Because while you’re learning, your competitors are experimenting. While you’re planning the perfect strategy, they’re running messy pilots and learning what actually works.

The Confidence Gap

Here’s where it gets dangerous.

90% of C-suite executives say they’re confident making AI decisions.

Only 8% actually possess substantial knowledge of AI technologies.

That’s an 82-point gap between confidence and competence.

You know what that gap is filled with? Consultants selling certainty. Vendors selling sophistication. And executives making decisions based on buzzwords instead of understanding.

The ones who succeed aren’t the ones who know the most. They’re the ones who know just enough to start, and learn everything else by doing.

What Success Actually Looks Like

You don’t need to understand transformer architectures to deploy a customer service chatbot.

You don’t need a PhD in machine learning to automate your reporting workflows.

You don’t need to master prompt engineering to use AI for market research.

You need to know:

• What problem you’re solving

• How you’ll measure success

• What you’ll do if it works (or doesn’t)

That’s competent decision-making. And it’s enough.

The executives who are winning at AI adoption aren’t the ones with the most knowledge. They’re the ones with the clearest thinking.

They ask better questions:

• “What’s the smallest experiment we can run this week?”

• “How will we know if this is actually helping?”

• “What will we do with the time we save?”

Not:

• “What’s the optimal architecture for our use case?”

• “How does this compare to seventeen other solutions?”

• “What if we’re missing something?”

The Golden Cut

There is a simple, fast way to do AI right.

It’s not about going wide and deep before you start. It’s about going narrow and shallow, learning fast, and building from there.

Step 1: Know where you stand

Before anything else, benchmark yourself. Not against theoretical best practices. Against real companies doing real work.

Where are you actually strong? Where are you actually weak? What’s the gap between where you are and where you need to be?

The AI Maturity Index and mundaine have teamed up. Take the assessment for executives. Fifteen minutes. Free. Anonymous. Benchmarked against thousands of executives worldwide. Available in English and German.

Take the assessment →

Step 2: Pick one painful workflow

Not the most strategic. Not the highest ROI. The most painful.

The thing your team complains about. The bottleneck that slows everything down. The task that makes people groan.

That’s your starting point.

Step 3: Run a 7-day experiment

Not a 6-month pilot. Seven days.

• What do you believe will improve?

• How will you measure it?

• What does success look like?

One week. Real work. Real measurement.

Step 4: Decide and move

Success? Scale it.

Failure? Pivot or kill it.

Unclear? Run it one more week with better metrics.

But decide. And move.

The Real Cost of Waiting

Every day you spend “getting ready” for AI is a day you’re not learning what actually works in your business.

Your competitors aren’t waiting. The 26% who aren’t struggling to scale AI value? They started before they were ready. They learned by doing. They built competence through action, not study.

You don’t need to know everything.

You need to know just enough to start. And you need to start now.

Before you hire another high-profile consultant. Before you read another whitepaper. Before you build another task force.

Benchmark where you stand. Pick one experiment. Run it for seven days. Learn. Decide. Move.

That’s the golden cut.

Simple. Clear. Applicable.

Ready to stop learning and start doing?

Take the AI Maturity Index assessment. See where you actually stand. Then run your first experiment this week.

Benchmark yourself now →

Sources

• BCG Press Release (Oct 2024) - 74% of companies struggle to scale AI value

• BayTech Consulting - 42% abandoned AI initiatives in 2025

• Fast Company/MIT Sloan - 90% confident, 8% knowledgeable

• Oracle/Fortune - 72% paralyzed by data volume

The Agent Trap: Why Even AI Experts Can’t Answer “What Would I Use Agents For?”

If someone who’s built the world’s most advanced AI agent platform struggles with misuse, what chance does a budget-setting executive have?

I just got off a call with Philip Alm. He’s the co-founder and CEO of Incredible.one[1], a Swedish AI company that went straight to #1 on Product Hunt with what might be the most advanced AI agent platform I’ve ever seen. Winner of Sweden’s largest innovation award. Backed by serious investors. The real deal.

And yet, even with early access to his cutting-edge platform, I found myself sitting there asking: What would I actually use agents for?

This isn’t false modesty. I bring eight years of AI experience. I’ve built agentic systems, automated workflows, consulted on AI strategy for companies of all sizes. If anyone should know what to use agents for, it’s me.

But I paused. And that pause matters.

The 99% Problem

Here’s what Philip told me that stuck: ”Ninety-nine percent of the use cases people build aren’t actually agent use cases.”

Read that again.

The builder of one of the world’s most advanced agent platforms, the person with the clearest view of how people actually use his technology, says almost everyone is using it wrong. Sure, you can solve these problems with an agent. But should you? It’s like using a sledgehammer for a thumbtack.

Get me right. This isn’t a criticism of his users. It’s an observation about where we are in this adoption curve. People hear “agents” and think it’s the future. So they try to force everything into that box.

The result? Overcomplicated solutions to simple problems.

The research backs this up. Gartner predicts[2] that over 40% of agentic AI projects will be canceled by 2027- due to escalating costs, unclear business value, or inadequate risk controls. McKinsey’s latest findings[3] are even more sobering: some companies are already “retrenching”- rehiring people where agents have failed. Their conclusion? “Agents aren’t always the answer - in some contexts traditional automation is still the smarter choice.”

Meanwhile, vendors are making things worse. Gartner calls it “agent washing” - the rebranding of chatbots and RPA tools as “agents” without any real agentic capabilities. Of the thousands of vendors claiming to sell agents, Gartner estimates only about 130 are legitimate.

What Most People Miss: The Distinction

Let me provide some clarity around my understanding of agents, agentic systems and automations.

An agent, by classical AI definitions, possesses four core characteristics: autonomy (operating independently without constant human oversight), perception (gathering information from their environment), rational decision-making (analyzing options and choosing actions that maximize goal achievement), and goal-directed behavior (proactively pursuing objectives, not just reacting to prompts). Advanced agents add learning and adaptability—continuously improving through experience. The highest-tier agents even set their own goals and create tools as needed.

In practice, when we talk about true agents, we’re talking about specialized roles, sub-agents, supervisors, hierarchy. We’re talking about systems that decide *themselves* whether to go route A or B—not based on business logic I implemented, but based on judgment. We’re talking about actually replacing parts of people’s work.

An agentic system follows decision trees I built. It looks autonomous, but I defined the paths. It’s still automation at its core.

Automation is deterministic. Same input, same output. Every time.

(Side note: If you’ve encountered “agents” in Microsoft Copilot, you’ve met something that covers the ground between true agents and agentic systems—which makes this even more confusing. For many, Copilot will be their first touchpoint with something called an “agent.” No wonder the lines are blurry.)

Most “agent use cases” I see are really agentic systems. Many agentic systems would work better as simple automation. And some automation could be a spreadsheet.

The tool should match the problem. But we’ve got the shiny new hammer, so everything looks like a nail.

The Hype We Skipped

Here’s something we don’t talk about enough: we completely skipped the automation hype.

I was working in automation when that wave should have peaked. But it never did. It was too complicated for management to understand. The speed to value was too slow. So we jumped past it.

All those consultancy waves - big data, cloud, digitization - they all had their moment. Automation got skipped. Now we’re jumping to AI and agents without the groundwork:

- When do you need exact, deterministic results?

- When do you need less exact but more human, non-deterministic results?

- When is AI even needed at all?

Without answers to these questions, companies are making million-dollar decisions based on vibes and vendor pitches.

The Magnifier Problem

AI is a magnifier. It makes everything faster, louder, bigger.

Feed it chaos, and it amplifies chaos. Feed it broken processes, and it breaks them faster. Feed it messy data, and it produces messy outputs at scale.

Agents stir even faster.

Before asking for agents, you need to understand what you’re actually trying to solve. You need the groundwork. Most companies don’t have it. They’re trying to run before they can walk.

Philip’s experience confirms what I see in my day-to-day work: the technology isn’t the bottleneck. Understanding is.

The Management Upskilling Gap

If I bring eight years of AI experience and still have to pause at “what would I use agents for?” - how should decision-makers investing millions know? How should managers allocating resources know? How should workers wondering about their futures know?

They can’t. Not without upskilling first.

McKinsey’s State of AI 2025 report[4] puts numbers to this gap: 88% of organizations now report using AI, but only 6% are seeing real financial impact. Just 1% believe their AI adoption has reached maturity. Everyone’s doing something. Almost no one’s doing it well.

The earlier leadership teams build this understanding, the further ahead they are. But most are still struggling to differentiate between automation and AI. Between agentic and truly autonomous. Between what sounds impressive in a demo and what actually creates value.

Philip said it well in an interview: the key is “the ability to distinguish between technology demonstrations and genuine value.”

That’s the gap. And it’s widening every day.

What This Means for You

If you’re planning AI investments for the year ahead, start with these questions:

Before reaching for agents, ask:

- What problem am I actually solving?

- Does this need judgment, or does it need consistency?

- Have I automated the basics first?

- Would a simpler solution work?

Before approving the budget, ask:

- Can my team distinguish automation from AI from agents?

- Do we have the groundwork (clean processes, good data) to benefit from AI?

- Are we solving a real problem or chasing a demo?

The unsexy truth: most companies need automation, not agents. They need to fix their processes before they amplify them. They need management that understands the distinction before they invest in the technology.

The Question That Matters

I walked away from my conversation with Philip with a deeper appreciation for where we actually are. Not where the hype says we are. Where we actually are.

The agent era is coming. Philip and his team are building the infrastructure for it. But we’re not there yet. Not for most use cases. Not for most companies.

The question isn’t “what agent should I build?” The question is: “do I even need one?”

For ninety-nine percent of you reading this, the honest answer is probably no. Not yet.

Start with the groundwork. Understand the distinctions. Build the basics. Then, when you’re actually ready, the agents will be waiting.

References

[1] Incredible.one - https://www.incredible.one

[2] Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by 2027 - https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027

[3] McKinsey: One Year of Agentic AI: Six Lessons from the People Doing the Work - https://www.mckinsey.com/capabilities/quantumblack/our-insights/one-year-of-agentic-ai-six-lessons-from-the-people-doing-the-work

[4] McKinsey: The State of AI 2025 - https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai

If you’re a leader trying to figure out where AI actually fits in your business, my [AI Adoption Sprint](https://mundaine.ai) takes you from confused to confident in one week. We do the groundwork together—so you know exactly what you need before you invest in what you don’t.

And if you’d rather have someone build the right solution for you (often automation, not agents), reach out about our Done-for-You automation service (https://mundaine.ai). We’ll build what you actually need in 1-2 weeks.

Subscribe now

88% of enterprises are experimenting with AI, but 70% of those projects never move past the pilot stage.

Here’s what nobody’s saying: the barrier isn’t technology. It’s organizational weight. The same resources that helped large companies win for decades (big IT teams, governance frameworks, structured processes) are now anchoring them to the ocean floor while smaller companies sail past.

We’re witnessing an inversion of scale advantage. And most leaders haven’t realized it yet.

Let me explain.

The Four Eras

For thirty years, enterprise software followed a predictable pattern. You identified a need. You bought a massive platform. You used maybe 10% of its features. You paid for all of it.

This was the Big Systems Era. SAP. Oracle. Salesforce at enterprise scale. High cost, low utilization, but it made sense. Building custom software required massive capital and specialized teams.

Then came the Specialized SaaS Era. Instead of one monolithic platform, you bought focused tools. Project management here. CRM there. Analytics somewhere else. Less waste than before, but still paying for features you’d never touch. Still configuring workflows to fit the software instead of the other way around.

We’re currently living in the Composable Era. I call it the messy middle. You assemble best-of-breed tools and orchestrate them through integrations and APIs. It works. Kind of. Until you’re managing seventeen subscriptions, three integration platforms, and a full-time person just keeping the pipes flowing.

But look closer at what’s emerging beneath the surface.

We’re entering the On-Demand Creation Era. Not someday. Now.

You can already see this in the mainstream. Google just launched Disco, an experimental AI tool for the browser, powered by Gemini 3. Open a few tabs while researching a trip to Japan. Disco analyzes what you’re looking at and offers to build you a custom planning tool. Within a minute, it assembles a browser-based app with a map of Japan annotated with attractions, an itinerary builder, and links to all your sources.

No coding. No buying software. You describe what you need, and it builds it.

Google calls this feature “GenTabs.” You prompt the system with what you’re trying to accomplish, and it generates a custom interface with the information and tools you need. Studying a complex subject? It suggests building a visualization app. Comparing recipes? It offers to create a meal planner. The underlying AI handles all the logic and code generation.

This isn’t a developer tool hidden in some technical preview. It’s a consumer product from the world’s largest search company. The signal is clear: the era of describing what you need and having it built is no longer coming. It’s here.

What Changed

So what does the shift look like? We’re moving from buying functionality to describing functionality and having it built.

A team of three can now have custom software created for their exact workflow in days, not months. The economics have inverted. What used to require a $200,000 development project and six months of vendor management can now happen in a week with one technical person and AI assistance.

I’ve seen this firsthand. I have built an entire web application (front end, back end, deployment pipeline) in under a week. No external developers. No massive budget. Just describing what we needed and iterating with AI until it worked.

The research backs this up. According to analysis from Menlo Ventures, startups now hold 71% market share in product and engineering tools, including code generation, beating enterprise incumbents who had every structural advantage. Why? They shipped faster. They experimented more. They weren’t slowed down by governance committees.

Businesses implementing custom solutions report an average ROI of 55% over five years, compared to 42% for SaaS implementations, according to Gartner data.

The math is changing.

The Paradox Nobody Talks About

Here’s where it gets interesting: small companies now have the advantage.

I know. It sounds backwards.

Large companies have more resources. Bigger budgets. Established IT departments. Access to the best tools and platforms. They should be winning this race.

But they’re not.

Research from McKinsey found that while 88% of enterprises are using or experimenting with AI, only 33% have deployed it across their organizations. The gap between experimentation and deployment reveals a leadership challenge, not a technology one.

When you’re a company of thousands, every AI initiative needs governance frameworks. Cross-functional committees. Risk assessments. Compliance reviews. Security audits. Change management processes.

When you’re a team of eight, you just... build it.

Academic research on AI adoption in smaller firms points to the same conclusion: agility and willingness to take risks give startups a distinct advantage with disruptive technologies. While large firms leverage substantial R&D resources for incremental innovation, smaller firms lead with technologies like AI that reward speed over scale.

The same attributes that made large companies successful in the Big Systems Era (formal processes, structured decision-making, coordinated rollouts) are now liabilities. Your advantage doesn’t come from the tools themselves. It comes from your ability to move.

What This Actually Looks Like

Let’s get concrete.

A small recruiting firm needs a candidate tracking system. The SaaS options are either too simple or too complex. Too expensive or too limited. Nothing quite fits.

In 2020, they would have compromised. Bought the closest fit. Configured their workflows to match the software.

In 2025, they describe their exact process to an AI-assisted developer. Custom candidate pipeline. Automated follow-ups specific to their approach. Integration with their existing tools. Built in two weeks. Owned completely. Modified whenever they need.

A boutique consulting firm wants a proposal generation system that pulls from their IP library, adapts to client contexts, and maintains their voice. No SaaS tool does this.

They don’t need to find one anymore. They build it. Custom. Exact. Theirs.

The difference is speed of execution. Small companies decide on Monday and deploy on Friday. Large companies form committees.

The Trap Large Companies Are In

Here’s the paradox large companies face: organizations with comprehensive governance models struggle to move fast. Organizations without them can’t scale safely. Either way, they lose ground to smaller competitors who don’t face this tradeoff.

Large enterprises also face integration nightmares with legacy systems. Nearly 60% cite integrating with existing infrastructure as their primary barrier to AI adoption. Their data sits in incompatible formats across siloed departments. Custom development requires coordinating multiple teams, navigating bureaucracy, securing budget approvals.

Small companies don’t have legacy systems holding them back. They’re not coordinating seventeen stakeholders. They’re not managing vendor relationships or negotiating enterprise contracts. They’re building what they need and shipping it.

The research is clear: organizations without structured governance experience faster initial deployment but struggle to scale. Organizations with comprehensive governance move slowly but systematically. Both approaches have costs.

But in an era where technology capabilities double every eighteen months, speed matters more than perfection.

Now, what does that mean for leaders?

If you’re running a small company, you’re sitting on an advantage you might not realize you have.

The keys to the future are already in your hands. The only question is whether you recognize it.

You don’t need a massive IT budget. You don’t need governance frameworks designed for thousand-person organizations. You don’t need to compromise your workflows to fit off-the-shelf software.

You need three things:

1. A willingness to experiment. Not pilot programs and steering committees. Actual experimentation where someone on your team describes a problem and builds a solution. Fast feedback loops. Quick failures. Rapid iteration.

2. One technically-capable person. Not a full development team. One person who can work with AI tools to create custom functionality. This is becoming a core business skill, not a specialized technical role.

3. Permission to move faster than feels comfortable. The protective instinct to “wait until we have it figured out” is the same instinct that lets larger, slower competitors catch up. In 2025, building beats buying in speed, fit, and cost.

According to Salesforce’s SMB Trends Report, growing small and mid-sized businesses are the primary drivers of AI adoption. 83% are already experimenting. 78% plan to increase investments. The gap is widening between AI-native small companies and those waiting for the “right time.”

The Choice Point

We’re at an inflection point.

For the first time in modern business history, being small is a software advantage. You can build exactly what you need, faster than enterprises can evaluate what to buy.

But this window won’t stay open forever. As more small companies realize this advantage and act on it, competitive pressure increases. The companies moving now are building capabilities. The ones waiting are falling behind.

Large companies will eventually solve their governance challenges and integration problems. They’ll figure out how to move faster. But that takes time.

That’s your window.

You can keep shopping for SaaS tools that almost fit. Keep paying for features you’ll never use. Keep configuring your business to match software designed for someone else.

Or you can start describing what you actually need and building it.

The technology is here. The economics work. The only barrier is recognizing where you stand.

What To Do Next

If you’re a small company leader reading this, here’s your action plan:

This week: Identify one workflow where you’re compromising because existing software doesn’t quite fit. Not your biggest problem. Just one clear example.

Next week: Describe exactly how that workflow should work in your business. Not how the software makes you do it. How you would design it.

The week after: Find one technical person, internal or external, who can work with AI tools to build a prototype. Give them your description. Set a two-week timeline.

Don’t aim for perfect. Aim for working. You can iterate from there.

The companies that figure this out first will have an advantage measured in years, not months. They’ll have systems built exactly for their needs. Software that evolves with their business instead of constraining it. Competitive moats built on custom capabilities, not purchased platforms.

This is the shift. The era of buying software is ending. The era of building exactly what you need is beginning.

The question isn’t whether this is happening. It’s whether you’ll be early or late.

---

*If this resonates but you’re not sure where to start, that’s exactly what I help companies navigate. I run 5-day AI Adoption Sprints where teams go from “we should probably do something with AI” to deployed, working solutions. We don’t just talk about possibilities. We build them.*

*And for leaders who see the vision but need execution support, I offer Done-for-You Automation where we build your custom solutions in 1-2 weeks. You describe the need. We deliver the working system.*

*2025 is the year to stop buying software and start building it. Let’s make sure you’re not still shopping while your competitors are shipping.*

---

Research Sources:

- [Google Blog: Disco and GenTabs](https://blog.google/technology/google-labs/gentabs-gemini-3/)

- [TechCrunch: Google Debuts Disco](https://techcrunch.com/2025/12/11/google-debuts-disco-a-gemini-powered-tool-for-making-web-apps-from-browser-tabs/)

- [McKinsey: The State of AI in 2025](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai)

- [Menlo Ventures: 2025 State of Generative AI in the Enterprise](https://menlovc.com/perspective/2025-the-state-of-generative-ai-in-the-enterprise/)

- [Salesforce: SMB Trends Report](https://www.salesforce.com/resources/research-reports/smb-trends/)

- [Netguru: SaaS vs Custom Software Guide (Gartner data)](https://www.netguru.com/blog/saas-vs-custom-software)

- [Deloitte: AI Adoption Challenges and Trends](https://www.deloitte.com/us/en/services/consulting/blogs/ai-adoption-challenges-ai-trends.html)

I’ve been thinking about a strange experience I had recently.

I was working with three terminal windows open, running AI agents in parallel. Task one running. Task two in progress. Task three queued up. No waiting, no idle time. Just pure output. I built more in a single afternoon than I used to build in a week.

And by evening, I was completely wiped out.

Not tired in the normal “long day” sense. Something deeper. The kind of exhaustion that makes you question whether the speed was worth it.

I thought I was the only one feeling this way. Turns out, I’m not even close.

The Numbers That Should Worry You

A recent Upwork study surveyed 2,500 workers across the US, UK, Australia, and Canada. The findings are striking:

96% of C-suite executives expect AI tools to increase their company’s productivity.

77% of employees say AI has actually *decreased* their productivity.

That’s not a gap. That’s a chasm.

And here’s the part that really got my attention: workers who use AI frequently are 30% more likely to report burnout than those who never use it. 45% of frequent AI users are burned out, compared to 35% of non-users.

The tools that were supposed to give us our time back are somehow taking more of it.

What’s Really Happening

The core insight isn’t that AI doesn’t work. It’s that we’ve been deploying it without addressing what actually matters.

Nearly half of employees using AI don’t know how to achieve the productivity gains their employers expect. We handed people powerful tools and assumed they’d figure it out. They didn’t. Not because they’re incapable, but because nobody taught them how.

This is a skills gap masquerading as a technology problem.

Microsoft Research found something even more revealing: the more confident workers are in AI, the less critical thinking they apply. They trust the output, skip the verification, and end up with what researchers are now calling “workslop”: AI-generated work that looks productive but lacks the substance to actually move things forward.

41% of workers have encountered workslop. Think: AI-generated reports that sound impressive but say nothing actionable. Each instance costs about two hours to fix.

So much for the productivity gains.

The Efficiency Trap

Wharton researchers identified a pattern they call “the efficiency trap.”

Here’s how it works: Every productivity improvement becomes the new baseline. You complete a project in three days instead of five? Great. Now three days is the expectation. The time you saved doesn’t become free time. It becomes time for more work.

Workers report feeling:

”Simultaneously more productive and more overwhelmed.”

I recognize this feeling. That afternoon with three terminals running? I got an enormous amount done. And the next day, my brain expected that pace to continue. Anything less felt like slacking.

This isn’t a bug. It’s how we’ve designed our relationship with productivity tools. We optimize for output and assume the humans will adapt.

They are adapting. They’re burning out.

We’ve Seen This Before

In 1987, Nobel Prize-winning economist Robert Solow made an observation that became famous: “You can see the computer age everywhere but in the productivity statistics.”

Companies were spending 25% more on technology year over year. Productivity was actually declining.

Sound familiar?

We’re living through the same pattern with AI. Massive investment. Underwhelming results. Not because the technology doesn’t work, but because meaningful gains require more than just tools.

The NBER puts it clearly: “Meaningful productivity gains from transformative technologies require extensive complementary investments in new processes, business models, and human capital.”

Human capital. That’s the part we keep skipping.

The Burden Shift Nobody Talks About

There’s another dynamic I keep seeing in my work with companies.

AI makes it easy to generate output. Documents, code, proposals, analysis. The person using the AI saves time. But someone still has to review that output. Verify it. Fix the errors. Edit out the verbose parts.

Research on developer teams found exactly this: “While authors may save time by pasting in AI outputs, reviewers inherit the burden of checking quality, correcting errors, and editing down verbosity.”

The work didn’t disappear. It shifted. And it shifted to the people whose time is often already stretched thin.

If you’re a leader rolling out AI tools, ask yourself: who’s doing the quality control? Because if no one is, you’re not getting productivity gains. You’re getting “workslop” at scale.

What This Means for Leaders

This isn’t a technology problem. It’s a leadership problem.

The companies I work with that are actually seeing results from AI aren’t the ones with the best tools. They’re the ones that took time to answer three questions:

1. Who needs to learn what?

Not everyone needs the same skills. Some people need to learn how to prompt effectively. Others need to learn how to evaluate AI output critically. Some need both. Generic “AI training” doesn’t cut it.

2. What are the new expectations, really?

If AI makes certain tasks faster, does that mean more tasks? Or does it mean different work? Your team is guessing at the answer. Make it explicit.

3. Who owns quality control?

When output gets easier to produce, the bottleneck shifts to review. If you haven’t adjusted for this, you’ve just moved the burnout from one person to another.

These aren’t easy questions to answer alone. And they’re exactly the kind of questions I work through with executives who are navigating this transition.

The Takeaway

The AI productivity paradox isn’t about the technology being overhyped.

It’s about the gap between what we expect AI to do for us and what we’ve actually prepared people to do with it.

96% of executives believe AI will boost productivity. But belief isn’t a strategy.

The leaders who will actually capture those gains are the ones who recognize that tools alone don’t change outcomes. Skills do. Expectations do. The way you communicate why this matters and what it means for each person on your team does.

That’s the work that makes the difference. And right now, most companies aren’t doing it.

If you’re navigating this right now and want a thought partner, I’m always happy to talk.

Sources

- Upwork Research Institute: [From Burnout to Balance (2024)](https://www.upwork.com/research/ai-enhanced-work-models)

- Wharton: [The AI Efficiency Trap](https://knowledge.wharton.upenn.edu/article/the-ai-efficiency-trap-when-productivity-tools-create-perpetual-pressure/)

- Microsoft Research: [AI and Critical Thinking (CHI 2025)](https://www.microsoft.com/en-us/research/publication/the-impact-of-generative-ai-on-critical-thinking-self-reported-reductions-in-cognitive-effort-and-confidence-effects-from-a-survey-of-knowledge-workers/)

- Harvard Business Review: [AI-Generated Workslop (2025)](https://hbr.org/2025/09/ai-generated-workslop-is-destroying-productivity)

- NBER: [AI and the Modern Productivity Paradox](https://www.nber.org/papers/w24001)

They’ve done the pilots. They’ve proven the concept. The AI champions are building use cases at speed. Ten a week sometimes. The executive team is bought in. Everyone at the top knows the value.

And yet nothing seems to stick.

If this sounds familiar, you might be about to hit a wall you don’t see coming. Because there are two kinds of “stuck” in AI adoption. And most people confuse them.

The Two Phases of Stuck

Phase 1: The Easy Kind

This is where daily business gets in the way. AI initiatives get deprioritized. Everything slows down. Other fires demand attention. The roadmap stretches.

But be aware: this is still the easy part.

In this phase, one motivated AI champion can build ten use cases a week. With ease. The technology works. The value is clear. It’s just about carving out time and focus.

If you’re stuck here, we can accelerate through it quickly. It’s mostly a matter of commitment and structure.

Phase 2: The Real Wall

But there’s another kind of stuck. And it’s the one that catches leaders off guard.

This is where your use cases exist but don’t touch the ground.

The executive team knows the value. You might even have a team of AI champions who are enthusiastic, building constantly, experimenting, tinkering. They’re eager to take this to the business.

But the layers beneath stall.

Middle management feels squeezed. Pressure from above to make AI happen. Resistance from below that doesn’t want to change how things work. And the people who actually need to use these tools? They’re not moving.

The Echo Chamber Problem

Here’s what I’ve noticed in these situations: the people driving AI adoption often don’t realize they’re in an echo chamber.

You believe in this. Your AI champions believe in this. The executives who sponsored the initiative believe in this. You’ve been building and experimenting together. You’ve seen what’s possible. You’re speaking the same language.

And then you try to roll out to the broader organization.

That’s when you hit the outside world.

The people on the receiving end haven’t been on this journey with you. They haven’t seen the experiments. They haven’t felt the wins. They’ve been doing their jobs the way they’ve always done them.

And now someone is asking them to change.

The Question Nobody’s Answering

The question that’s missing in most AI rollouts is simple: “What’s in it for me?”

Not “what’s in it for the company.” Not “what’s in it for productivity.” Not “what’s in it for the bottom line.”

What’s in it for the person who has to actually change how they work?

When that question gets answered, people roll along intrinsically. They want to adopt because they see personal value. They’re not being pushed. They’re pulling.

When that question stays unanswered, you get compliance at best. And quiet resistance at worst. The rollout stalls. The use cases sit unused. The AI champions get frustrated. The executives wonder why things aren’t moving.

Why This Happens

The Curse of Enthusiasm

The people driving AI adoption are usually excited about the technology. They’ve seen what it can do. They believe in the potential. This enthusiasm is what got the initiatives started in the first place.

But enthusiasm doesn’t translate automatically. What feels obviously valuable to someone who’s been experimenting for months isn’t obvious to someone who just sees another tool they need to learn.

The Communication Gap

Most AI rollouts fail at communication, not technology.

The message that lands with the executive team is not the message that lands with middle management. And neither is the message that lands with the people doing the work.

Executives care about strategic value and competitive positioning. Middle managers care about not disrupting what’s already working and not creating more problems to manage. Individual contributors care about whether this makes their day better or worse.

Same initiative. Three completely different conversations needed.

The Change Fatigue Factor

Your AI initiative isn’t happening in isolation. People have been through system changes, process changes, restructurings. They’ve heard “this will make things better” before.

If your message sounds like every other change initiative they’ve lived through, they’ll treat it the same way: nod along and wait for it to blow over.

What Actually Works

Start with the Individual

Before you can scale AI adoption, you need to be able to answer one question for every role that will be affected: how does this make their specific work better?

Not “better for productivity.” Better for them.

Less tedious work. Fewer interruptions. More time for the parts of their job they actually like. Less stress in specific situations they deal with regularly.

And even beyond that: What can we provide them, that they can take away into their private lives. This is where you have an opportunity to build that true identification. That true intrinsic motivation.

If you can’t articulate this for a specific role, you’re not ready to roll out to that role.

Make It Concrete

Abstract benefits don’t drive adoption. Concrete examples do.

“AI can help with customer service” means nothing. “When a customer asks about X, instead of searching through three systems, you can ask this tool and get the answer in 10 seconds” means something.

Get specific. Use real scenarios. Show the before and after in terms people can immediately recognize.

Let People See Themselves

The most effective AI rollouts I’ve seen let people discover value for themselves.

Not a presentation. Not a training session where someone demonstrates capabilities. An opportunity to play with a tool in the context of their own work and find their own wins. Bonus: This is where you collect feedback for further improvement.

When someone discovers for themselves that this thing can help them, they become advocates. When someone is told this thing will help them, they become skeptics.

What This Means for You

If you’re leading AI adoption in your organization, ask yourself honestly: are you stuck in Phase 1 or Phase 2?

If it’s Phase 1, you need the right approach, focus and commitment. The solutions are tactical.

If it’s Phase 2, you have a communication challenge. And that’s harder to solve, because it requires understanding perspectives very different from your own.

The technology isn’t the bottleneck. The message is.

This is exactly what I mostly work on with leaders in my Executive Sparring program. Not the AI strategy. Not the use case development. The communication. How to craft messages that land differently with different audiences. How to answer “what’s in it for me?” in ways that create intrinsic buy-in rather than forced compliance.

Because once people genuinely see the value for themselves, they don’t need to be pushed. They pull.

The Takeaway

Your AI pilots succeeded because you and your champions believed. Scaling requires something different: helping others believe too.

That doesn’t happen through better presentations or more training sessions. It happens through answering the question nobody’s asking out loud but everyone’s thinking: “What’s in it for me?”

Get that answer right, and the wall becomes a door.

This is the sacred cow of product development. Every business school, every startup accelerator, every innovation consultant preaches it. Start with customer pain. Validate the problem exists. Only then build something.

It makes perfect sense. Except when it doesn’t.

When OpenAI released ChatGPT in late 2022, they violated this principle spectacularly. They didn’t launch a product that solved a clear problem. They released a fascinating technology and said: “Here. Play with it.”

And we did.

I still remember when one of my employees showed it to me. He had written an entire story in seconds. We were completely fascinated—not because we needed AI-generated stories, but because of what it implied. What else could this thing do?

Within weeks, we were chaining tools together. MidJourney for images (bad by today’s standards, but magical then). A lip-sync app. Text-to-speech. We created talking pictures telling their own stories. It was amazing—far from a final product, but we built it by playing around.

We still didn’t have a solution for an existing problem. But we had created so much.

This wasn’t traditional product development. This was something else entirely.

The Inversion

What happened with ChatGPT inverted everything we’re taught about innovation. Instead of problem-first, solution-second, we got:

Solution first. Problems emerge through play.

This isn’t how it’s supposed to work. And yet it did. Spectacularly.

The pattern I’m seeing is what I call Solution-First Innovation:

1. Encounter - Meet the technology with curiosity, not requirements

2. Experiment - Play without pressure, chain things together

3. Emerge - Problems reveal themselves through use

4. Extract - Pull out the actual value created

5. Execute - Now build the “proper” solution

This flips the traditional sequence (Research → Problem → Solution → Build) on its head. And for AI, I’m convinced it’s the only approach that works.

The Language Test Tutor

Here’s a story that captures this perfectly.

A woman was preparing for a language diploma exam. She needed practice tests to prepare, but she ran out of sample materials. So she did what any resourceful person would do - she fed existing tests and requirements into an LLM and asked it to generate new practice tests.

Simple problem. Simple solution. But here’s where it gets interesting.

She started using the AI to grade her answers too. She’d compare its ratings to the official guidelines. And she discovered something surprising: the AI graded with the exact same accuracy as a human examiner. Same scores. Same feedback quality.

She had set out to generate practice tests. What she accidentally built was a personal language tutor that could both test and grade her work.

She found a problem, test prep scarcity, through experimentation, not market research. And in the process, discovered a much bigger problem she could solve: the entire test preparation and grading workflow.

She passed her exam and moved on. But here’s my provocation: she could have productized this right now. A language learning AI that generates personalized tests and provides human-level grading. And at the same time she could have started to take over the testing space, by providing a solution for language test-centers. By the way, the tests she used for herself were hand-written.

If you’re reading this, you might steal this idea and build it right now.

What This Means for Your Company

I work with companies at the beginning of their AI journey. The most common thing I hear is: “We know we need to do something with AI, but we don’t know where to start.”

My response often surprises them: Stop looking for the perfect use case. Start playing.

The companies I see winning with AI aren’t the ones with the best strategy documents. They’re the ones where people have permission to experiment. Where someone can spend an afternoon chaining tools together without a mandatory business case tied to it.

What I can tell you from years of tinkering: the problems will find you. The more you create and play, the more you’ll discover what AI is actually a solution for. And what not.

But this requires something most organizations struggle with: giving people permission to play without knowing the outcome. That’s not how business usually works. We want ROI projections. Use case validation. Analysis phases.

While I still believe that those three are important in the business world, I like to deliver on them fast, to create space for experimentation.

Because the most valuable AI applications I’ve seen weren’t discovered through analysis. They were stumbled upon by someone who was curious enough to experiment and lucky enough to work somewhere that let them.

The Real Challenge

The technical part of AI adoption has become shockingly simple. I’ve taken companies from zero to a working AI pilot in five days. The tools are ready. The capabilities are there.

The hard part isn’t technology. It’s culture.

It’s getting leaders comfortable with “try things and see what happens” as a legitimate strategy. It’s creating space for experimentation without requiring justification. It’s accepting that the best AI use cases in your company probably haven’t been discovered yet—and won’t be discovered by consultants running workshops, but by employees playing around.

The language test story didn’t come from a strategy session. It came from someone who ran out of practice materials and thought, “I wonder if...”

That “I wonder if...” is worth more than a hundred use case workshops.

The Question

So here’s what I’m thinking about:

Are you waiting for the perfect problem before you let your people play with AI? Are you demanding business cases before experimentation? Are you running analysis phases when you should be running experiments?

The companies winning at AI aren’t the ones with the best strategies. They’re the ones experimenting fastest. They’re the ones where someone can discover an accidental tutor while just trying to pass a language test.

Traditional product development says: find a problem, build a solution.

AI adoption says: find some curiosity, and let the problems find you.

What have you discovered by playing that you never intended to build?

Damian helps mid-sized companies adopt AI with a human-centered approach—from zero to working pilots in days, not months. If you’re stuck waiting for the perfect use case, let’s talk about what experimentation could look like for your team.