There is a five step sequence that runs on every process at the companies that actually operate well with AI. Question the requirements. Delete. Simplify. Speed up. Automate.
The sequence is old, well documented, and almost never followed in order. The reason is not laziness. It is that step five is the only step with an obvious output. You can see an automation ship. You cannot see a requirement being deleted, so deleting looks like doing nothing.
That asymmetry is now a serious liability, because AI has made step five roughly ten times cheaper than it used to be. When automation was expensive, you had a natural forcing function: nobody bothered to automate a process that did not survive scrutiny, because the effort was not worth it. That brake is gone.
Question the requirement
Before you improve a process, establish whether it needs to exist. Not whether it works well. Whether the requirement behind it is real or inherited.
Most processes in most companies exist because something needed to happen once, four years ago, and nobody revisited it. The quarterly report that three people assemble exists because a board member asked for it in 2022. The approval step exists because of an incident that has since been resolved by a different control.
The question to ask is not “how do we do this better.” It is “who asked for this, when, and do they still need it.” That question is uncomfortable because the honest answer is often a person who would rather not be told their report is unnecessary.
Delete, which is the hardest step by far
If the requirement does not hold, delete the process. Not deprecate it, not put it on a quarterly review, not add a flag to disable it. Delete it and see whether anyone notices.
This is the step that separates teams that compound from teams that accumulate. Deleting is the only step that makes everything after it cheaper, and it produces nothing to show in a status update. There is no dashboard for “we stopped doing three things this month,” which is why it does not happen.
The practical test: remove it, say nothing, and wait thirty days. If nobody complains, it was dead weight and you have just bought back permanent capacity. If somebody does complain, you have learned who actually depends on it, which is information you did not have before.
Simplify what survives
Whatever you could not delete, strip down. Fewer steps, fewer approvals, fewer handoffs, fewer fields. Every step you remove is a step that does not need to be automated later and cannot break in production.
Simplification is where most teams accidentally do their best work, because the constraint of removing steps forces a genuine redesign rather than a faster version of the same mess. A process that went through four signatures to two did not get faster. It got better.
A useful discipline: for every step, ask what would break if we removed it. If the answer is nothing you can name specifically, remove it.
Speed it up, then automate it last
Only now do you make it faster, and only after it is fast do you automate it. The order here is not arbitrary. Automating a slow process locks in the slowness permanently, because once the automation exists, nobody revisits the design.
Speed first also gives you a measurement. A process that went from four days to four hours tells you exactly what automation is worth. Automating first gives you no baseline, so you cannot tell whether the automation helped or just hid a bottleneck.
Automation is the reward for doing the first four steps correctly. It should be the least interesting part of the work, because by the time you reach it, the problem has already mostly been solved.
Who asked for this, when, and do they still need it? If you cannot name a person and a reason, keep digging.
Remove it and say nothing for thirty days. Silence is the proof.
Cut steps, approvals, handoffs, and fields until removing one more would break something you can name.
Make the simplified version fast. Record the new baseline number, because that is what automation has to beat.
Only now. And only the version that survived the first four steps.
The half-life of a good process is short right now. New capabilities arrive monthly, which means the correct design last quarter may be wrong this quarter, and a workflow optimized in March can be obsolete by June. Running the sequence once is a project. Running it weekly is a practice. The teams getting compounding returns are not the ones with better automation. They are the ones re-asking the requirement question on a schedule, before the accumulated weight of unnecessary process becomes invisible again.
Spend your AI budget on the right step
Everybody wants to build the agent. Almost nobody wants to delete the report. But the deletion is worth more, and it is worth more permanently, because capacity you buy back does not need maintenance.
Take your least favorite recurring process this week and run the five questions in order. You will probably find that steps one and two solve it, and that you never needed to automate anything at all.