Suppose a Product team is asked to add AI to supplier onboarding.
The current process is slow and everyone knows it. A supplier sends documents. Someone re-enters information into an internal system. Compliance checks a subset of the data. A merchandising or business team reviews the item. A manager approves the packet. Exceptions move into email. A spreadsheet keeps track of cases that do not fit the normal path.
AI can help almost everywhere. It can extract the documents, classify the risk, fill fields, summarize the case, draft the follow-up, and route the exception. That sounds like a good automation project. It may be. But before Product turns every box in the flowchart into an AI task, there is a more basic question: which of those boxes should still exist?
The current workflow is evidence, not the specification
Product people already know this move when somebody asks for a feature. The request is evidence about a need, not automatically the correct solution. An inherited workflow deserves the same treatment.
The manager approval may exist because years ago somebody made an expensive mistake and the business added a control. The duplicate data entry may exist because two systems were never integrated. The compliance step may be legally or financially important. The spreadsheet may exist because the formal process has no useful exception path. The business review may be a real judgment call—or a rubber stamp that almost never changes the outcome.
Those are not equivalent steps just because the flowchart gives each one a rectangle. If Product accepts the current process as requirements, the team can build an elegant automation for a system nobody would design that way today.
Automation makes old assumptions harder to ignore
The temptation is especially strong with AI because the demo can look so good.
A document that took fifteen minutes to review is summarized in seconds. The supplier packet routes automatically. The manager receives a beautifully drafted approval note. The process moves faster.
But faster is not the same as better. If the supplier entered the same information twice because the systems could not share data, using AI to copy it faster preserves the duplication. If a low-risk item passes through three approvals that almost never change the decision, automating all three approvals gives the old policy better infrastructure. If the business review exists only because nobody trusts the data upstream, the higher-leverage move may be fixing the trust problem rather than accelerating the review. The Product question is not how many steps the technology can perform. It is which work still earns a place in the future state.
People are often carrying the missing process in their heads
The official workflow can also look cleaner than the real one because experienced people know how to make it work.
They know which supplier document is usually incomplete. They know the manager approval is effectively automatic once a certain compliance check passes. They know which exception needs Legal and which one can be resolved by the business team. They know that a field in the system is technically required but operationally meaningless.
None of that may be written down. I think of that as workflow debt. The formal process says one thing; the real process depends on accumulated human judgment around it.
Automation exposes the debt because the system now has to do something with the ambiguity. Can it infer the missing information? How confident does it need to be? Which action is reversible? When does it escalate? Who owns the exception? What evidence has to be retained?
The answer does not have to be a deterministic rule for everything. AI is useful precisely because some work is ambiguous. But production still needs an intentional way to handle uncertainty instead of depending on the person who “just knows what to do.”
Redesign from the outcome backward
Before deciding where AI belongs, start with the outcome supplier onboarding is supposed to create. The business wants a qualified supplier or item ready to operate safely, compliantly, and quickly enough to create value. Now walk the real process and ask what each step contributes to that outcome.
Some steps should disappear. Some can be combined. Some should become ordinary software rules. Some are strong candidates for AI because they involve messy documents, classification, or synthesis. Some should stay human because the consequence requires judgment and accountability. Some controls should remain intentionally slow because the downside of getting them wrong is larger than the benefit of speed.
That is a much more useful design conversation than asking whether an agent can complete all twelve boxes.
Keep the friction that is doing a real job
Process redesign can become shallow in the other direction too. “Remove friction” sounds smart until the friction is protecting money, safety, customer trust, security, or regulatory obligations. The goal is not a workflow with the fewest possible steps. It is a workflow where each remaining step has an intentional reason to exist.
If a manager approval protects a consequential exception, keep the control and make the threshold clear. If the approval is a historical rubber stamp, remove it. If Legal review is only required for a small class of suppliers, route those cases deliberately instead of making everyone wait. If the system can enforce a policy safely, the guardrail may belong in the product rather than in another meeting.
Speed is one design variable. Risk and accountability are others.
Implementation can teach you what the workflow hides
None of this means the process has to be perfect before a team experiments with AI. A small implementation can expose exactly where the workflow is ambiguous. It can show which exceptions dominate, where data quality breaks, which approval adds no value, and what humans are doing that nobody documented. That learning is useful. The mistake is treating the current workflow as sacred while the team learns.
Use the implementation to challenge the process, not merely encode it faster.
Automate work worth scaling
A good automation project should leave you with more than a faster version of the old diagram.
It should leave you able to explain why the future workflow has the steps it has. Which work disappeared because it no longer earned a place? Which control remained because it protects something important? Which judgment moved into the product? Which exception became explicit? Where does AI help, and where is simpler software or human accountability the better answer?
That is the Product discipline underneath automation. The current process tells you how the organization learned to survive yesterday. Treat that as evidence. Then design the work you actually want to scale tomorrow. Only after that should the machine inherit the process.