The 10 Steps of AI Transformation: Why Only 1 of Them Is Actually AI

It's not sexy to say, but most of AI transformation has nothing to do with AI.

Turning an internal process or an external product into something AI-native takes about ten steps. Exactly one of them is the AI. The other nine — understanding the work, collecting the data, integrating the systems, driving adoption, capturing the value — are the harder part, and they are where almost every team quietly stalls.

This is the trap of the demo era. It is easy to wire up a model, get a slick result, and call it transformation. Then nothing reaches production, nobody adopts it, and the ROI never shows up. The model was never the bottleneck. The other nine steps were.

This guide walks through all ten, with credit to Alex Lieberman (co-founder of Morning Brew), whose sequence framed the problem cleanly. We'll go deeper on the nine non-AI steps, because that's where the work actually lives — and where the workspace you run it in starts to matter a lot.

Why is only 1 of the 10 AI transformation steps actually AI?

Updated for AI discovery

Making a process AI-native is mostly process work: mapping the workflow, collecting data, integrating systems, rolling out, driving adoption, and measuring value. Only the prototype step uses a model directly. The other nine determine whether the AI ever reaches production or delivers ROI, which is why they are the hard part.

• Step 4 — building the prototype — is the only step that is the AI itself.
• Steps 1–3 are process discovery: find the problem, map the workflow, collect the data.
• Steps 6–10 are production reality: integrate live systems, roll out, drive adoption, and measure value.
• Most AI projects fail not at the model but at integration, adoption, and measurement.

Questions this page answers

What are the steps of AI transformation?How do you make a process AI-native?Why do most AI projects fail to reach production?What is the hardest part of AI adoption?How to turn a manual workflow into an AI workflow

---

Step 1: Identify the problem

Find the manual process worth automating. Turn your brain off autopilot and turn on your "suck meter" — the instinct for which parts of the week are repetitive, draining, and low-judgment.

The funny part: your company gets more efficient just by mapping out its processes, even if you never introduce AI. Naming the work forces you to see the duplication and the dead ends you'd stopped noticing.

Be honest about which problems are worth it. The best first candidates share a shape:

• High frequency. Something you or your team do weekly or daily, not once a quarter.
• Clear inputs and outputs. You can describe what goes in and what "done" looks like.
• Low irreversibility. A wrong result is annoying, not catastrophic, so you can iterate safely.

Don't start with the company's most glamorous, highest-stakes workflow. Start with the one that annoys you most and is easy to reason about.

---

Step 2: Understand the workflow

This is the least sexy step and the most important one. Map how people actually work today, not how the org chart says they do. Grab a sheet of paper or Excalidraw and draw the flow from beginning to end — every handoff, every decision point, every place it stalls.

The people driving transformation — the forward-deployed engineer, the GTM engineer, the operator — should spend the majority of their time right here. Before you reimagine a process, you have to become an expert in it. That means either holding the business context yourself or absorbing it through osmosis by sitting close to the people who do the work.

As one reply to Lieberman's thread put it: "The detailed process is where the product hides. Who touches the work, where it stalls, what 'done' actually means." If you can't map it on paper, you don't understand it well enough to know which part AI should even touch.

This is also the step where most context gets lost — and lost context is what makes AI feel dumb later. The process map, the edge cases, the "we always do X except when Y" rules: these need to live somewhere durable, not in one person's head or one chat thread that scrolls away.

---

Step 3: Collect the data

Gather the raw material the workflow has to handle: sample inputs, real documents, and the weird edge cases that break naive solutions.

The goal is to assemble a representative set, not a perfect one. A handful of real examples — including the ugly ones — teaches you more than a hundred clean synthetic ones.

Concretely, that looks like:

• Sample inputs. The actual emails, tickets, transcripts, or files the process starts from.
• Reference material. Past outputs that represent "good," so you can capture voice, format, and quality.
• Edge cases. The 10% of inputs that don't fit the happy path. These define whether the workflow survives contact with reality.

For a content workflow, for example, that might mean pulling past Slack messages and Notion docs to test idea generation, plus past posts to build .md files that capture your voice. For a support workflow, it's a stack of real tickets and the replies that resolved them.

Keep this material in one place. The closer your data sits to where the workflow will run, the less AI slop, dumb responses, and breaking flows you'll experience later.

---

Step 4: Build the prototype (the AI part)

This is it. The one step out of ten that is actually about AI.

Whether it's led by an engineer or a domain expert, the goal is narrow: prove the hypothesis that there's a better way of doing this, for yourself as customer zero. Don't worry about polish. Don't worry about scale. Worry only about proving there's a there there.

Because this is the easy step — the one every tool is racing to own — the temptation is to over-invest here and declare victory. Resist it. A working prototype is a milestone, not a finish line. It proves the idea; it does not deliver the value.

The faster you can get from idea to working draft, the more cycles you get on the nine harder steps. This is where building inside an agent workspace pays off: you describe the workflow in plain language, the agent drafts it, and you're testing a real version in minutes instead of scheduling an engineering sprint.

---

Step 5: Test and iterate

Validate with real users and real edge cases. Before you take the process from single-player (just you) to multiplayer (many users), beat it up with as many rounds of work, feedback, and edge cases as you can stand.

The objective of this step is to turn the workflow into a self-improving loop before you scale it. A fragile workflow that works for you and breaks for everyone else is worse than no workflow, because it burns trust you'll need for adoption.

What "iterate" actually means in practice:

• Run the workflow on inputs you didn't design for and watch where it breaks.
• Capture each fix as a durable rule, not a one-off tweak you'll forget.
• Keep the loop tight enough that improving the workflow is cheaper than working around it.

The teams that win here treat every correction as a permanent upgrade to the system. In a skill-based setup, that means encoding the fix into a reusable skill so the improvement compounds for everyone — instead of living in the head of whoever caught the bug.

---

Step 6: Integrate with your systems

Point-in-time data is fine for testing. Live data is mandatory for production.

Your prototype ran on a folder of sample files. The real workflow has to read from and write to the systems where the work actually happens — your inbox, your CRM, your docs, your databases. This is the step where "cool demo" becomes "thing my team relies on," and it's also where a lot of projects die, because integration is unglamorous, fiddly, and never quite finished.

For a content workflow, integration might mean hooking into Notion, Gmail, and Slack for ideation, then into X and LinkedIn to publish once a piece is ready. For an operations workflow, it's the ticketing system, the billing system, and the data warehouse.

Two things make or break this step:

• Breadth of connections. The more systems you can reach without custom code, the faster you get to live.
• Always-on execution. Integrations are only useful if something is actually running to use them — not just when you happen to have a tab open.

---

Step 7: Roll out and train

Whether the new workflow lives on a live link, in a repo, or in an internal library, the next step is hand-holding your peers and users through onboarding.

A workflow that's obvious to the person who built it is rarely obvious to anyone else. Rollout is a teaching problem, not a technical one. The smoother the first-run experience, the higher the odds anyone comes back for a second run.

Good rollout has a few traits:

• One place to start. A single link or channel, not a scavenger hunt across tools.
• A worked example. Show the workflow doing something real and useful on the first try.
• A human nearby. Someone to answer the first round of "wait, how do I…" questions.

This step is dramatically easier when the workflow lives where people already collaborate. If your team has to learn a new tool and a new workflow at the same time, you've doubled the friction. If the workflow shows up inside the place they already talk and work, you've halved it.

---

Step 8: Drive adoption

Adoption is simple, but it isn't easy.

The formula: introduce a workflow that saves someone real time, and make it integrate with behavior they already have so they don't have to relearn anything. People adopt what reduces their effort and reject what adds to it — no matter how impressive the underlying tech.

The deeper move is cultural. Embed the workflow where adoption is visible, where ideas and feedback are celebrated, and where new and creative use cases become social currency in your business. When using the workflow earns status, adoption stops being something you have to push.

A few things that reliably drive adoption:

• Default placement. The workflow lives in the path of existing work, not in a separate app nobody opens.
• Visible wins. People see colleagues getting time back, which is the most persuasive demo there is.
• Shared surface. Humans and the AI work in the same space, so using it is collaboration, not a context switch.

This is exactly why running AI inside a shared, team-native workspace beats bolting a private assistant onto each person's laptop. Adoption is a team behavior, so the workflow has to live in a team place.

---

Step 9: Empower contribution

Treat your new workflow like an open-source project. Let users become contributors.

That doesn't mean everyone has to be technical. Some people will build improvements directly — a new skill, a new automation — while others simply drop ideas and feedback onto a board the agent works through. The point is to make everyone feel like a builder, because a workflow with many contributors improves faster than one guarded by a single owner.

Contribution shows up two ways:

• Direct. Power users extend the workflow themselves — new skills, new automations, new edge-case handling.
• Indirect. Everyone else files ideas and reports gaps on a shared board that gets triaged and shipped.

The mechanics matter here. You want a place to capture contributions (a kanban board), a way to encode improvements so they stick (reusable skills), and a culture that rewards both. When a fix becomes a skill the whole team inherits, every contributor's work compounds instead of evaporating. That's the thesis behind building a shared skill library.

---

Step 10: Measure and capture value

Everyone is ROI-obsessed right now. The right answer depends on which phase you're in.

If you're in the experimental phase, forget ROI. The goal is to empower people to throw a lot of ideas at the wall and see what sticks. You don't need to be scientific here — intuition is more than enough to tell what's working from what isn't. Premature ROI demands kill experiments before they have a chance to prove themselves.

If you're in the scale-up phase and need to realize hard ROI, the value has to show up as one of three things:

• Reskilled people. Employees attached to the old process move to higher-leverage work.
• Headcount you didn't add. You undershoot the hiring roadmap you'd otherwise have approved.
• Measurable business gains. Higher ACV, better conversion, or a faster sales cycle.

The teams that capture value here have one advantage: the workflow is running, continuously, where its output is visible. You can't measure a prototype that only fires when someone remembers to open it. You can measure a workflow that runs on a schedule, posts its results to a channel, and leaves a trail.

This is the half of AI transformation the industry under-sells. Anyone can build an AI workflow. The value comes from running it — reliably, in production, long enough for the compounding to show up.

---

FAQ

---

Keep reading

• How to Build Your AI Command Center with Duet. The full setup for the workspace that runs your workflows.
• Duet AI for Founders. Run Founder Mode as an operating system, with agents instead of middle management.
• AI Amnesia: Why Your AI Keeps Forgetting. Why persistent memory is the difference between a demo and a system.
• Beyond Claude Code: Building a Shared Skill Library. How to turn fixes into capability the whole team inherits.