Hey folks 👋
There’s been an increasing amount of research in the last year which attempts to measure how much value (i.e. speed and quality gains) people are getting from AI when they use it at work. One pattern I see emerging from that research is this: the people getting the most value from AI aren’t the ones using it most, or the ones with the most advanced technical skills: they’re the ones who redesigned their day to day workflows around AI’s capabilities.
This is a surprisingly consistent finding. In the most recent and striking study to date, teams who were shown how to redesign work around AI went on to win more paying customers and bring in roughly twice the revenue of otherwise identical peers who had exactly the same tools and training (Kim, Kim & Koning, 2026).
On paper, this looks like an AI hack that everyone who uses AI at work should benefit from. But there’s a problem, and I hear it from lots of folks on the ground: nobody ever explains what “redesign your workflow” actually means in enough detail to try it. In this week’s post I want to try to fix that by sharing the three-step workflow redesign method I created for The AI Bootcamp for L&D. The examples are from L&D, because that’s where I built it, but the method works for any wokflow.
Let’s dive in! 🚀
“Bolting On” vs “Redesigning”: The 101
There’s an increasing amount of talk about two different ways we can use AI: “bolting AI on” and “redesigning the workflow”. What does this actually mean? Here’s the 101.
Bolting on means keeping the workflow you already have — the same tasks, in the same order, owned by the same people, with the same handoffs and checks — and giving people an AI tool to use inside it. The shape of the work doesn’t change. Individual tasks get faster.
Redesigning means changing the shape of the work, so that the list of tasks, who does them, and where the checks sit all look different afterwards. Some work disappears from a person’s plate entirely. Runs of production work that used to pass through several hands become one AI-enabled chain. Work that never happened because there was no time gets added. And the points where a person has to decide are designed in, with a written standard to decide against, rather than happening wherever someone notices the AI might be wrong.
Put another way: if you explain your AI use by saying it made X faster or cheaper, you’re bolting on. If you need a new workflow diagram to explain what happens, what’s gone, what’s been added and where people now decide, you’ve redesigned.
What the Research Says About “Bolting On”
Bolting AI onto existing workflows is what almost everyone does, and for good reason; it’s quick, cheap, reversible and low-risk. You keep the process you already have, give people access to AI, and let them use it where they think it helps them get more “productive”.
The research says this approach works, sometimes impressively, but only under a very specific set of conditions. Here are the headlines:
The average productivity gain is real, but it isn’t evenly spread. Brynjolfsson, Li & Raymond (2025) studied the rollout of a generative AI assistant to over 5,000 customer-support agents. Productivity, measured as issues resolved per hour, rose by around 15% on average. But the least experienced agents improved by around 34%, while the most experienced saw little productivity benefit and, on some quality measures, small declines. In effect, the AI was handing the tacit knowledge of the best agents to the newest ones. Useful, but it didn’t change what the job involved.
Speed and quality both improve when the task suits the model, and reverse when it doesn’t. Dell’Acqua et al. (2026) gave 758 BCG consultants realistic tasks with and without GPT-4. On tasks inside the model’s capabilities, consultants using AI completed 12% more tasks, worked around 25% faster and produced work rated over 30% higher in quality. On a task deliberately chosen to sit outside those capabilities, the AI group was 19 percentage points less likely to reach the right answer, because they trusted output that looked convincing and was wrong. The authors call this the “jagged technological frontier”. The consultants couldn’t tell which side of it they were on.
People can’t feel whether AI is making them faster. In a 2025 randomised trial, METR studied 16 experienced open-source developers completing 246 real issues in codebases they knew well. With AI tools allowed, developers took 19% longer, while believing afterwards that AI had made them around 20% faster (Becker et al., 2025). The study measured time, not code quality, and captured one group of experts using early-2025 tools, so don’t generalise it to all coding. But the perception gap is the finding that travels: asking people whether AI helped is not the same as measuring whether it did.
Human + AI is not automatically better than either alone. Vaccaro, Almaatouq & Malone (2024) pooled 106 experiments on human–AI collaboration and found that, on average, the combination performed worse than whichever of the human or the AI was better alone. Creation tasks were the exception; on decision tasks, adding AI to a human process was more likely to make the outcome worse.
Taken together, I think the bolt-on research tells us three things:
The gains of just “using AI at work” are real, but they go mostly to the least experienced. Task-level AI assistance helps most where there’s the most tacit knowledge to fill in.
The gains depend significantly on the task, and reverse when the model is out of its depth. And the person using it can’t reliably tell when that is.
People checking AI output miss the errors. When it looks polished, reviewers can’t tell when to override it, and on decision tasks human review did worse than the AI alone. A reviewer isn’t a safety net; they’re where the error gets waved through.
What the Research Says About Workflow Redesign
The evidence on workflow redesign around AI is thinner, and contains more surveys, case studies and observed patterns than controlled comparisons. Given this, we should be careful about claims that redesign has been “proven” to deliver a particular return, but the direction of traffic is clear.
The strongest direct evidence so far is Kim, Kim & Koning’s 2026 field experiment, Mapping AI into Production. The researchers followed 515 companies over three-months. Every firm got the same API credits, the same access to frontier models and the same weekly hands-on technical training. The only difference was this: one group was also shown case studies of companies that had redesigned their workflows around AI, with before-and-after workflow diagrams showing steps being merged, changed or removed as a result of AI’s capabilities.
The examples the test group saw weren’t, “here’s where this company used ChatGPT”. They showed a different way of thinking about the work, e.g. an accounts-receivable process where eight steps alternating between clerks and software became one automated chain; a product process where AI generated and tested several variants at once instead of moving one option through the usual queue of specialists.
The firms shown the redesigned workflow examples went on to:
🚀 Find 44% more uses for AI, concentrated in strategy rather than admin
🚀 Complete 12% more tasks
🚀 Become 18% more likely to win paying customers
🚀 Generates 1.9x the revenue of the comparison group
There are limits to what this tells us. First of all, it’s a working paper which hasn’t yet been peer reviewed. Also, the firms were small (median team of four), start ups (so, culturally agile and open to change) and were observed for only three months. So this is not conclusive evidence that redesigning your workflow will double your revenue.
But what it does show is this: AI capability isn’t only a property of the person or the tool. It’s also a property of how the work is organised. Give people the same AI tool and the same training, and you still get very different outcomes depending on whether they look for isolated tasks to speed up or rethink the work and process itself.
McKinsey’s State of AI surveys point the same way. In 2025, they reported that only around 21% of organisations using generative AI reported fundamentally redesigning any workflow, but of roughly 25 practices tested, redesign had the strongest relationship with reported bottom-line impact. Their 2026 survey shows that the gap is widening: nearly three-quarters of AI top performers now report fundamentally redesigning their workflows, up from 55% a year earlier.
Two other findings help explain what the workflow redesign has to contain. In a BCG experiment back in 2023, Dell'Acqua et al. noticed that the consultants who got the most vale from AI fell into two camps: "centaurs", who split the task and handed clearly bounded pieces to the AI, and "cyborgs", who wove it through the whole task. What the two had in common was that they'd decided, in advance, which parts of the work were theirs and which weren't. The consultants who got burned were the ones who hadn't.
More recently, Anthropic's (2026) analysis of roughly 400,000 Claude Code sessions found the same thing at the individual level. Verified success more than doubled for some users. What set them apart wasn't technical background but two habits: they specified what they wanted before the AI started, and they judged what came back against that specification. In other words, they'd done the redesign work for a single task —written the standard, then checked the output against it — before opening the chat.
None of this proves that workflow redesign = 2X value from AI. But together this research give us a clear direction of travel and a principle: the question isn’t whether we use AI at work, it’s how the work is divided between the human and the AI.
Which brings us to the how.
How to Redesign a Workflow in Three Steps
In my bootcamp we use a task-mapping process that distils workflow redesign down to three steps: map the work, tag each task by the impact you want AI to have, then validate whether what you want is possible.
Three steps get you to a plan: two or three tasks worth building, each with a written standard. Turning that plan into a redesign takes two more moves, which I’ll cover after the steps. I’m flagging that now because the moves are the bit most people skip, and they’re where the redesign actually happens.
Here’s a how to for each step:
Step 1: Map Every Task in the Workflow
Start with one real workflow, broken into a manageable phase, and write down what happens in the order it happens. “Instructional design” is too broad. “Turning a training request into an approved design” is about right.
The level of detail matters. Work at to-do-list size: “write the learning objectives” is a task; “check that each objective has an observable verb” is a step inside it. If you end up with dozens of tasks, you need to split the phase.
Then, and critically, add a second list underneath your exitsing workflow: the tasks you know would improve the work but rarely happen, because there’s never the time, the budget or the people. Think:
👻 Interviewing five learners before you write a single objective
👻 Checking the evidence before the design is finalised
👻 Generating several different solutions rather than one
👻 Going back to the performance data 90 days after launch
I call these the ghosts: the things that should be there but usually aren’t. They matter because redesigning around AI isn’t only about doing existing work faster. Some of the biggest opportunities come from making unaffordable work affordable.
Step 2: Tag Each Task
Now go back through every task and decide what impact you wish AI would have on it. Use four tags:
🐒 Take it off me
Boring, repetitive work that eats hours but adds not much substantive value. Think: logging training requests, summarising interviews, formatting documents, chasing people for replies, setting up a course in the LMS. It has to be done, but nobody’s career ever improved by doing it.
The opportunity: AI might be able to do the whole task, to a standard you’ve written down, and you only spot check the output quality periodically. This is the tag that makes work disappear from your plate.
⚡ Make it faster
Work you’re good at and still need to do, but which starts from a blank page every time. Think: turning notes into a storyboard, generating video scripts, grouping survey answers into themes. You know what good looks like and how to do the task well; it’s just slow to produce.
The opportunity: AI gives you a rough first version in minutes and you finish it. The task takes half the time, and you still own the result. One warning: if every task you’ve tagged is a ⚡, you’ve sped up the old workflow without changing it. That’s bolting on.
💎 Help me do it better
The decisions that matter most and get the least time. Think: asking “Is this really a training problem?” when a request lands; defining the optimal instructional strategy for every training request; getting feedback from learners before anything is built. These are the calls that decide whether the work succeeds, and they’re usually made quickly, alone, on instinct, and nobody finds out they were wrong until months later.
The opportunity: AI becomes the second opinion you never had time for. It argues the other side, checks your decision against a standard you wrote when you weren’t under pressure, and makes you say out loud why you’re choosing what you’re choosing. The decision stays yours. It just stops being made alone.
👻 Make it possible
The things everyone agrees would make the work optimal, but nobody ever does, because there’s never any time and/or it takes expertise you don’t have. Think: running semantic analyses on learner comms; analysing years of quantitative data for patterns in performance or building a working prototype to test with learners. You know these matter, but they still happen zero times.
The opportunity: AI drops the cost of the task far enough that it can happen every time instead of never. Not perfectly. But a rough learner test that actually happens beats a perfect one that doesn’t.
At the end of Step 2 you have something more useful than a list of AI ideas. You have a map of the existing work, plus an explicit view of what should disappear (🐒), what should get faster (⚡), where judgement needs strengthening (💎), and what new work should become possible (👻). If that sounds familiar, it’s because those are the four things I said a redesign changes back in the 101.
But that’s a plan, not a redesign.
Step 3: Surface the Most Valuable Tasks, and Validate that AI Can Do Them
You’ve now got a tagged map with somewhere between ten and twenty tasks on it. You won’t build tools for all of them, and you shouldn’t try. This step narrows it to two or three.
First, score every task for value. Don’t pick the most interesting task — pick the one that would change your week most. Give each task a score of 1 to 3 on three questions:
How often does it happen, or should it? Once a year = 1. Every project = 2. Every week = 3.
How much time or pain does it cost? An hour and a shrug = 1. A day = 2. A day you dread, or a day that comes back with corrections = 3.
Would anyone else notice if it were better or faster? Only you = 1. Your SME or stakeholder = 2. Learners (or whoever your work is ultimately for) = 3.
Add them up. Anything scoring 7 or more is a candidate. Two things I’ve learned from running this with a few hundred people:
Nobody picks the 🐒 tasks, because they’re boring, and they’re often the best place to start.
A 👻 can score high, because you score it on how often it should happen.
Then, check AI can do what you want it to. Take your top two or three and ask three questions. Each one exists because of a specific way AI fails when it’s missing.
1. Could you name whose expertise this task needs, and how they’d approach it?
Not “an instructional designer” but “an assessment designer who works backwards from the objective, writes the task that would prove it, and treats a recall quiz as a last resort.”
Why we ask: Left to itself, AI defaults to the average of everything it’s read, and the average instructional designer writes recall quizzes. Naming the expert, and how they think, is what pulls the output away from the average and towards the way a good practitioner would do it. If you can’t say whose judgement you’re trying to reproduce, you’ll get generic work and no way to tell it’s generic.
2. Could you write down how you do it, as steps a new starter could follow, including how you avoid the common mistakes?
Why we ask: AI follows instructions; it doesn’t infer the ones you didn’t write. If your process lives in your head as “I just know”, the tool will skip the steps you skip without noticing and make the mistakes you’ve learned not to make. Writing the steps down is the test of whether you understand the task well enough to hand it over. If you can’t, the problem isn’t the AI.
3. Could you show someone an example done well, and one done badly?
Why we ask: One good example does more than a page of adjectives. “Clear, measurable objectives” means nothing to a model; five objectives that each start with an observable verb and carry a condition and a standard means everything. The bad example matters as much, because it’s how you’ll check the output later: if you can’t say what wrong looks like, you can’t spot it when it comes back.
Three yeses and you have a task AI can take on. Two or fewer and it can’t do this yet, not because the model isn’t capable, but because you haven’t yet made the task explicit enough to delegate. That’s useful to know. Go back to your map and try another task, and come back to this one when you can answer all three.
Between them, the three answers are the quality standard for the task, written before anything is built: who’s judging, what the steps are, and what good and bad look like. That standard is what the AI works to, what you score its output against, and what you use when you decide whether to accept the work.
Now turn it into a one sentence hypothesis that you can test. This is the output of Step 3, and everything that follows is built to test it:
I'm going to prototype an AI tool that [does X, e.g. turns a design brief into one observable objective per performance gap], to [change Y, e.g. cut the two rounds of SME rework I go through on every project], and I'll know it worked if [signal Z, e.g. the SME passes four of five objectives without a rewrite].
Concluding Thoughts
Put the two halves of the evidence together and you get two pictures: how most people use AI, and how the few who get the most from it use it differently.
Most of us bolt AI onto the work we already do. At the organisational level, McKinsey’s 2026 survey found that 80% of people say AI has improved their own productivity, yet the share of organisations reporting any bottom-line impact hasn’t moved in a year, and three-quarters still haven’t redesigned a single workflow. At the team level, the control group in Kim et al.’s experiment had exactly the same tools and training as the treated group, and used them for the obvious things: a summary here, a faster draft there. And at the individual level, Anthropic’s data shows the gap between novice and expert sessions is about specification and judgement, not tooling: most people hand AI a task, take what comes back, and move on.
The minority who get the outsized gains from AI do something different, and it’s the same thing at the individual and organisational level.
As individuals, they don’t use AI more or in more advanced ways. They decide in advance what they want AI to do and what they’ll keep: they specify the work precisely, they judge what comes back against a standard they’ve already written, and they treat the AI as something to argue with on the decisions that matter. Dell’Acqua et al. saw it in the consultants who deliberately allocated work between themselves and the model. Anthropic saw it in the experts whose verified success was double that of novices with the same tools.
As organisations, they redraw the work rather than accelerating it. They ask which tasks should disappear, which runs of production can collapse into one, which neglected work can now happen, and where a person still has to stop and decide. That’s what the treated firms in Kim et al. did with the same technology as the control group, and it’s what McKinsey’s high performers report doing while everyone else adds copilots.
None of this is technically hard. What’s hard is the mindset. One thing I’ve learned from the L&D teams I work with is that shelving is often the toughest shift in the whole process. People will happily map, tag and build; asking them to bin a tool they’ve built after two misses is where it stalls. I think this tells us something: workflow redesign is a cultural challenge as much as a structural one. The structure is a map and a standard. The culture is being willing to let the standard win.
Which is why I think this is ours to own. Workflow redesign is a design task, not a training outcome, and in most organisations nobody yet owns it. But the cultural half, helping people specify, judge, and let go, is exactly the work L&D already knows how to do. That seems to me like an opportunity for us.
Happy innovating!
Phil 👋
PS: If you want to redesign your workflow with help from me and a community of people like you, apply for a place on The AI Bootcamp for L&D.
Step 3 is my favorite part. If I can't name the expert, write the steps for a new starter, and show you one done well and one done badly, I never understood the task. I just knew how to do it, which is different.
Knowledge you can't transfer is knowledge you can't inspect. It's people forced, finally, to understand their own work.
The specification is the education.