Faster Paths to Wrong Destinations
Why most AI transformations fail, and how 'outcome-first' thinking prevents you from automating the wrong work faster.
Most AI transformations are expensive ways to make broken processes run faster. The technology works. The implementations don't. And the reason has nothing to do with models, compute, or talent.
BCG found that 60% of organizations investing in AI generate no material value from it. McKinsey's data tells a similar story: 88% of companies are using AI somewhere, but only 7% have fully scaled it.
The problem isn't the technology. It's what we're pointing it at.
Across industries, organizations are rushing to implement AI that replicates how they already work, silos, handoffs, workarounds and all. They're building faster paths to the wrong destinations. And they're discovering, usually after significant investment, that automating a broken process just gets you to broken faster.
The missing ingredient isn't a better model or a more capable agent. It's knowing what success means before coding begins.
Solutioning Without a Destination
Here's the pattern: a leadership team sees a competitor announce an AI initiative, or a board member forwards an article about agentic workflows, and suddenly there's urgency. A team gets spun up. Vendors get called. The focus becomes what can we build rather than what problem are we solving and how will we know we've solved it.
Tony Ulwick, who developed Outcome-Driven Innovation, has spent decades studying why products fail. His conclusion is blunt: companies fall in love with solutions before they understand the job the customer is trying to get done. They skip the hard work of defining success in measurable terms and then wonder why the thing they built doesn't move the needle.
Teresa Torres, whose continuous discovery framework has shaped how modern product teams operate, puts it differently. The biggest risk isn't that you'll fail to build something. It's that you'll successfully build the wrong thing. When organizations rush to AI implementation without rigorous discovery, they're often just adding speed to that mistake.
I saw this play out recently at a large telecom provider. The team came in with a proposal to optimize truck rolls, the dispatching of field technicians using AI. Sounded reasonable. But when we dug in, the actual business problem was that installation times for business services were too slow. The truck rolls weren't the job to be done; they were a symptom of a fragmented process nobody had mapped end-to-end. Technicians were still being dispatched too frequently, for the wrong service types, because the upstream logic was broken. Optimizing the dispatch algorithm just meant getting to the business faster for the wrong thing.
Had the team started with the outcome to speed up business service installations and mapped every step required to achieve that at a durable, system-agnostic level, they'd have seen that truck roll optimization was one small piece, and maybe not even the highest-leverage one.
This isn't a technology problem. It's a clarity problem. And no amount of model capability fixes unclear intent.
When Outcome Alignment Doesn't Hold
A different organization within that same telco learned an equally painful lesson about what happens when outcome alignment doesn't hold.
The initiative started with real ambition for a genuine digital transformation, not just a point solution. Early on, the teams did the work: mapping jobs to be done, identifying how roles would shift, building a case for retiring systems that had been around since the dawn of time. There was energy. There was alignment. There were lollipops and macaroni salads, as one colleague put it.
Then the project expanded beyond the core team. New stakeholders arrived the drive-by contributors from business units and IT groups who hadn't been through the discovery process. They couldn't envision changing their existing workflows, and they had enough organizational weight to make demands. The mandate shifted: the new system had to do everything better and support everything the legacy system currently did.
Scope tripled. Timelines followed. Leadership started questioning whether to finish the work at all.
The project survived, but only after painful compromises. The lesson stuck: technical transformation without sustained outcome alignment is a setup for scope explosion. When you don't have a clear definition of done rooted in business outcomes, not feature lists every stakeholder becomes a scope vector.
The Shift: From Agents to Agentic Workflows
There's a reason the conversation in AI circles is shifting from "agents" to "agentic workflows." The distinction matters more than it might seem.
The early promise of AI agents was autonomy systems that could reason, decide, and act without human intervention. In demos, this looks magical. In production, it often looks like a liability. Unpredictable behavior, unclear decision chains, and no good answer when someone asks, "why did the system do that?"
Cobus Greyling captured the shift well in a recent piece:
"Agentic workflows solve this by introducing connected, purpose-built agents operating through conditional logic and human-in-the-loop checkpoints. Each agent has a clear role, its own prompt and tools, and contributes to a transparent, traceable process. This is not a retreat from autonomy; it is autonomy that works in production."
This framing matters because it puts design back at the center. An agentic workflow isn't just a collection of AI capabilities it's an orchestrated system where each component has a defined job, clear inputs and outputs, and accountability built in. The Nielsen Norman Group has been making a version of this argument for years in their work on human-AI interaction: trust in AI systems comes from appropriate transparency and user control, not from raw capability.
If you're building agentic solutions without first mapping the workflow - who does what, when, with what handoffs and checkpoints you're not building a system. You're just turning capabilities loose and hoping it all works out.
Foundations That Actually Work: ODI + LEAN + Design Thinking
What does doing this correctly look like? In our experience, it starts with combining a few frameworks that weren't designed for AI but turn out to be essential for it.
Outcome-Driven Innovation, Ulwick's methodology, gives you a way to define success that's durable and measurable. Instead of asking "what features should we build," you ask "what is the customer trying to accomplish, and how will they measure whether they've accomplished it?" This produces job statements and desired outcomes that don't change every time the technology shifts. When you're designing agentic workflows, this matters a lot, the AI needs context to reason against, and vague goals produce vague results.
Design thinking keeps humans at the center. Jared Spool has a line that's stuck with me: "Design is the rendering of intent." You can't render intent you haven't defined—and you can't define it without understanding the people who'll use the system, the context they're operating in, and what success feels like from their perspective. This is where journey mapping and experience mapping prove their value, especially when you're redesigning work rather than just digitizing it.
Here's how these connect: ODI and design thinking are how humans orchestrate the work by defining outcomes, mapping jobs, understanding context. That clarity is what allows development teams to organize and deliver using LEAN practices and modern code generation tools. Eric Ries made build-measure-learn the foundation of the Lean Startup movement for a reason: tight feedback loops only work if you know what you're testing and why. Jeff Gothelf extended this into Lean UX, arguing that cross-functional teams need shared outcomes and not just shared backlogs to avoid building features nobody needs. Without the upstream thinking, LEAN just helps you iterate faster on the wrong thing. With it, you can build small, test quickly with synthetic data, and get in front of real users before you've over-invested. When your outcomes are clear, tools that generate code in near real-time become force multipliers instead of chaos engines.
None of these frameworks are new. But combined, they give you something AI implementations desperately need: a foundation that outlasts the next model announcement.
What This Looks Like in Practice
In practice, this means smaller teams working in tighter loops than most enterprise organizations are used to.
You start with outcome mapping and not a feature list, but a clear articulation of the jobs to be done and how you'll measure success. Everything else builds on this. Then you map current state: not to replicate it, but to understand where the real friction lives and what can be eliminated entirely.
Getting the details right on job step mapping matters more than most teams realize. When you break down each step required to complete a job and define how success gets measured at each point, you end up with sharper metrics for the overall solution. Precise definitions give you something you can validate against and market value becomes the key factor for that validation. If the outcome you're delivering doesn't translate to value your customers recognize and will pay for, you haven't found the right outcome yet.
From there, the work becomes iterative. Small groups, frequent check-ins, designers and developers working together toward a known outcome. We've found that when you hand end users a blank canvas and ask them to describe what they want, they'll draw you a picture of what they already have. If the current system is a loveseat, they'll describe a loveseat when what they actually needed was a place for one person to sit in a living room. Maybe that's a chair. Maybe it's something else entirely. Outcome-first thinking gets you to the real need instead of a shinier version of the status quo.
The agentic components, the AI that reasons, acts, and hands off get designed into workflows with explicit checkpoints and clear accountability. Each agent has a job. Each job ties back to an outcome. Humans can see what's happening and step in when needed.
This isn't slower. It's faster since you avoid creating unnecessary work before clarifying the actual problem.
If you're starting a new initiative or trying to rescue one that's gone sideways, here's where to begin:
Start with one job, not a platform. Pick a single job your customer is trying to get done and map it end-to-end before you scope any technology. Document how things work today, but don't let that become the blueprint, remember the goal is to understand friction, not replicate it. If you can't articulate the outcome in one sentence, you're not ready to build.
Define success metrics before selecting tools. If you can't measure whether the outcome improved, you won't know if the AI helped or just added complexity.
The Vegetables You Have to Eat
None of this is glamorous work. Tasks like setting outcomes, outlining steps, and managing stakeholder requests are necessary groundwork before tackling the more engaging work.
But it's the difference between AI that demos well and AI that actually works in production.
The shift from autonomous agents to agentic workflows is already happening. And there's a next evolution coming into view: moving beyond workflows to skills and discrete collections of tasks that are even more portable and composable. When you've done the hard work of mapping jobs at a granular level, those task definitions become building blocks that can be reassembled across systems, products, and contexts. Think of a "verify customer identity" skill that works the same way whether it's triggered by a chatbot, a service agent, or an automated workflow. The organizations doing outcome-first work now are laying the foundation for that future.
The technology will keep advancing. New models will drop every few months. The foundations: clear outcomes, mapped workflows, validated market value will outlast all of it.
That's the work. It's not as exciting as announcing an AI initiative. But it's what separates transformation theater from actual transformation.
