The bottleneck is rarely where anyone thinks it is. Here is how to find it before you build.
The process they automate is almost never the one that was costing them the most. They automate the visible one. The loudest one. The one someone mentioned in a meeting.
The real bottleneck is quieter. Usually managed by someone competent who built a workaround so effective that nobody above them knows the original process is broken.
That workaround is invisible to management. It shows up in observation.
In almost every engagement, the actual bottleneck is managed by the most capable person on the operational team. Not because they are particularly good at managing bottlenecks. Because they had no choice. The process broke, they built a workaround, and they have been maintaining it quietly ever since.
The workaround is often elegant. A spreadsheet that reconciles two systems that do not talk to each other. A Slack message that serves as the trigger for a process that should have an automated trigger. A morning ritual of copying data from one screen to another because the integration was never built.
From management's perspective, the process runs fine. From the desk, it runs fine because someone is absorbing the friction every day.
At the actual desk. Notebook only, no laptop. Not watching the process as it was designed to run. Watching what actually happens: the workarounds, the copy-paste between systems, the spreadsheet someone rebuilt three years ago because the original broke and nobody had time to fix it.
The Shadow is not an interview. It is observation. People narrate their work differently than they do it. In an interview, they describe the designed process. In observation, what shows up is what is real.
Two hours is usually enough. The patterns appear quickly: where the hands move between systems, where the pause is before the next step, where the workaround lives.
The workaround the team built, and the assumption underneath it that nobody questioned. A data pull that happens manually because the API was never set up. A summary email that one person writes every morning because the dashboard nobody agreed on was never built.
The approval step added during a crisis that was never removed. An extra sign-off that was added during a compliance review eighteen months ago. The compliance issue was resolved. The approval step remained.
The copy-paste that transfers information between two systems that do not communicate. Usually the highest-volume friction point. Usually invisible from above because the person doing it has become fast.
The human who acts as a router between systems that should be connected. One person who receives output from system A, formats it, and enters it into system B. Every working day. Has been doing this for two years. Nobody above them knows this step exists because it has never failed.
The workaround is where the build starts. Not where the manager thought. Not where the vendor wanted to sell.
At the end of The Shadow, ask one question: "If you could delete one part of this, what would it be?"
Most people pause. Some apologise for having an answer, as if admitting friction is admitting failure. It is not. It is the most accurate signal of where the real bottleneck is.
The answer is almost always different from what management identified as the priority.
In one engagement, management had identified a reporting process as the bottleneck. Three people spent significant time on it each week. The team member asked this question pointed immediately to a data entry step that preceded the report, a step that was not on any process map because it had been built informally and never documented. That step was taking 40 minutes per person per day.
When the build starts from the real bottleneck rather than the assumed one, the scope is smaller. The result is faster. The team's response to the first version is different, not polite, but visceral. The thing they hated is gone.
When the build starts from the assumed bottleneck, the automation is technically correct. It just does not change how anyone feels about their work. The team uses it. They do not believe in it. At the first failure, they go back to the old way.
The difference between those two outcomes is two hours of observation before the build begins.
In Indian MSMEs, family businesses, and export houses, the real bottleneck is almost always in communication, not in the process itself.
The production process is usually efficient. The logistics are usually managed. The bottleneck is in what flows around those things: the approval that requires the founder's personal sign-off, the follow-up to an overseas buyer that never gets sent because nobody owns that step, the internal status update that requires a phone call because no shared system was ever built.
Export houses lose time not in production or logistics, but in the follow-up communication with overseas buyers. A product ships. The buyer asks for an update. The update requires calling the factory, calling the freight company, and assembling a reply. That reply takes 45 minutes. It happens six times a day. It is never on a process map because it feels like just answering emails.
For solopreneurs running their own operations, the bottleneck is almost always the founder themselves: the approval that only they can give, the email that only they can write, the decision that only they can make. The bottleneck is structural, not operational. Automation does not fix it. Delegation architecture does, with automation supporting the handoff.
Finding any of this requires sitting at the desk. Not asking in a meeting. Not reading a process document. Watching.
Before any tool is shortlisted, before any vendor is contacted, before any automation is scoped:
Spend two hours at the desk of the person who runs the process. Watch what actually happens. Ask the one question at the end. Start the build from that answer.
The tool choice comes after. The workflow design comes after. The build comes after. The scope, what actually gets built, comes from what was found in those two hours.
The full audit methodology, including The Shadow, The Leak Finder, and The Kill List, is in the implementation guide.
This article is part of a series on AI implementation methodology. The canonical guide, covering the full audit, build, and handover phases, is at What AI Implementation Actually Looks Like.
Priyankka Wadhwa is an AI implementation practitioner working across organisations in the United States and India. She works at desk level, with solopreneurs, founders, family businesses, and export houses, building AI workflows that change how work actually happens, not how it was designed to happen.
A two-hour diagnostic maps what is actually happening before anything is built. Available for organisations in India and the United States.
Book a Diagnostic →