Your Process Documentation Is Lying to You

The most expensive mistake in product development doesn't happen during engineering. It doesn't happen during QA. It happens on day one, when a team takes a document at face value and starts building.

I just wrapped a three-day discovery workshop with a client. We sat with their Finance, IT, and SAP teams, went deep on their invoice processing workflow, and came out the other side with something I've now seen on every single engagement I've run.

Every company has three versions of their process.

The one in the SOP. The one in the system. The one in people's heads.

They are never the same.

The SOP Is Aspirational

Standard Operating Procedures are written to describe how things should work. They're written in a moment of clarity, usually after a project, during an audit, or when someone new joins and asks "where's the documentation?"

The problem is, SOPs don't update themselves. A workaround gets introduced in March. Someone leaves in June and takes their tribal knowledge with them. The system gets upgraded in September, but the SOP still references the old screen.

By the time you're reading it, the SOP is already a historical document pretending to be a current one.

The System Is Historical

The system - the ERP, the CRM, the ticketing tool - tells you what actually happened. Which fields got filled in. Which steps got skipped. Which exceptions got forced through.

It's a record of behavior, not intent.

And behavior is messy. People find the fastest path through a system, not the intended one. They learn which validations can be bypassed, which fields are never actually checked, which statuses mean something different in practice than in theory.

The system shows you the truth. But only if you know how to read it.

The People Are Patching the Gap

Here's the part nobody documents: the gap between the SOP and the system is being managed, manually, by the people doing the work.

Every day.

Someone is running a side spreadsheet to track the cases the system can't handle. Someone else has a folder on their desktop that acts as a buffer queue between two processes that were never properly integrated. A third person has memorised an exception rule that exists nowhere in writing because "we just always do it this way."

These aren't failures. They're adaptations. They're how work actually gets done in organisations that have been operating for years.

But if you're building software against the SOP and ignoring the people, you're building for a process that no longer exists.

What a Good Discovery Session Actually Does

Most discovery sessions produce documentation. Requirements, user stories, process maps. Outputs that look thorough and feel productive.

But the real job of discovery isn't documentation. It's contradiction-finding.

Where does the SOP say one thing and the system show another? Where does the team say "well, technically we're supposed to do X, but what we actually do is Y"? Where are the three versions fighting each other?

Those contradictions are not edge cases. They are the product.

Every exception, every workaround, every undocumented rule. That's where your AI will break in production if you don't surface it first. That's where the previous software failed. That's where the next implementation will fail too, if you don't go looking.

Three days of uncomfortable questions in a room with the right people beats six months of debugging in production. Every time.

How to Find the Contradictions

The technique is simple, even if the conversations aren't always comfortable:

Ask the same question three times. First, ask for the documented process. Then ask to see it in the system. Then ask someone who does it every day to walk you through what they actually do. The gaps between those three answers are your discovery.

Follow exceptions. Every time someone says "except when..." or "unless...", stop and go deep. Exceptions reveal the true shape of a process faster than any SOP.

Find the spreadsheets. If someone has a spreadsheet that isn't in the official system, it exists for a reason. It's filling a gap. Find the gap.

Ask who has the unwritten rules. There's always someone who's been there longest. The person who trained everyone else. The one people call when something unusual happens. Talk to them early.

The Real Cost of Skipping This

When you build against the SOP without running this kind of discovery, you're building for a world that doesn't exist.

The software goes live. The happy path works fine. But the first exception hits and there's no rule for it. The first edge case surfaces and the system doesn't know what to do. The team falls back to their old workarounds, except now they have to work around your software too.

The project doesn't fail dramatically. It fails slowly. Adoption drops. Trust erodes. Someone says "the old way was easier."

It didn't have to go that way.

Why the Workshop Is Still the Wrong Answer

Everything I've described works. I run it, it finds the contradictions, and the resulting software survives contact with production.

It's also a patch, not a fix.

Three days in a room gets you a snapshot of a process that starts drifting the week after you leave. Someone invents a new workaround in March and nobody tells you. The document you produced begins its slow decay into the same aspirational fiction as the SOP it replaced. You've just built a better version of the thing that was already broken.

And it only works if you can get the access to run it in the first place. Increasingly, you can't. Watching someone work means their inbox, their screen, their side spreadsheets. That's exactly what a security review exists to prevent, and both sides of that conversation are correct.

Where I Think This Actually Goes

The version I want to build doesn't ask anyone to describe their process at all.

People keep doing their jobs. No workshop, no interview, no form. Underneath the work sits an intelligent layer that learns from what's actually happening: what gets opened and in what order, which fields get overridden, where someone stops and asks a colleague, which exception gets handled the same unwritten way every single time.

Over time that layer assembles the real process. Not the documented one. And then it writes it down.

Flip the direction of the arrow. Today the SOP is an input that someone maintains badly on the side, and the software is built against it. In this version the SOP is an output of the work, generated from observed behavior and updated continuously. A memory layer instead of a document. When the workaround changes in March, the layer sees the change. The process description improves as the process drifts, rather than decaying away from it.

That's the version where automation stops being a project with a start and end date and becomes a property of the system. The system gets better at your process because it never stopped watching it.

I'll be honest about the open problem, because it's the same one I just described. This needs access. Watching someone work is watching someone work, whether it's a consultant with a notepad or a model with a log. The bet is that continuous, narrowly-scoped observation is easier to get approved than a one-time request for someone's mailbox, because you can bound what it sees and show exactly what it stored. That's a bet. It isn't solved.

But the prize is worth the work. The SOP is aspirational. The system is historical. The people are patching the gap. Right now, closing that gap is a consulting exercise you repeat forever.

It should be something the software does by itself.

Related reading

• Anthropic Didn't Build Dispatch to Win. They Built It to Last.. Why the access problem is the real bottleneck in enterprise automation, and what sandboxing has to do with it.

• Your AI Roadmap Is Built Backwards. The same problem one level up: building against the wrong question.

• Building AI for Finance Teams - Why It's Harder Than It Looks. What discovery gaps look like when the domain is finance ops.