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.

The SOP is aspirational. The system is historical. The people are patching the gap.

Your job — before a single line of code gets written — is to find where those three versions disagree.

That's where the real product decisions live.