Discovery starts with the system people actually use

Discovery sounds like the simple part. Ask a few questions, map the workflow, collect the requirements, and decide what to build. In applied intelligence work, I am starting to think discovery is the hardest part.

Not because the questions are complex. Because the documented workflow is rarely the whole workflow.

The system people describe first is usually the formal one. The system they actually use includes side channels, memory, exceptions, informal judgment, and repeated manual synthesis that never makes it into any diagram.

The first version of the system is usually too clean

When you ask how work happens, people often describe the official process. Lead comes in. Ticket is created. Student is enrolled. Report is generated. Manager reviews the dashboard. Coordinator follows up.

That version matters. It is also incomplete.

The real process includes the message sent outside the system because it was faster. The spreadsheet copied from the dashboard because the dashboard answers the wrong question. The note only one person understands but everyone trusts. The recurring exception that everyone has learned to handle without documenting. The judgment call made before escalation. The weekly meeting where the real meaning of the numbers is finally assembled.

Discovery has to slow down enough to see this second layer.

Look for where people leave the system

This is the part of discovery I have found most useful. One clear signal is where people stop using the official system and move somewhere else.

They export to Excel because the dashboard shows the wrong cut of the data. They send screenshots in WhatsApp because the system does not carry enough context to make the situation make sense. They maintain a private tracker because the official status field is not trusted. They ask a senior person before acting because the report does not explain what the number means. They wait for the weekly meeting because no one feels confident enough to act from the dashboard alone.

These are not failures. They are evidence.

Each one shows where the formal system stops short of interpretation. Where it hands people data without giving them meaning. Discovery is where we find the interpretation gap, the difference between what the system records and what someone needs to understand before making a call.

Discovery is not only about data

It is easy to spend discovery asking what data exists. That matters. But it is not enough.

Useful discovery also asks who reads the data. What they compare it with. What they distrust and why. What they ignore. What they check before making a call. What makes someone say “something is off” before they can articulate why. What they wish they knew before the meeting, before the call, before the review started.

These are not documentation questions. They are questions about how people actually build their understanding of a situation before they act on it.

The intelligence layer that ends up being useful is often shaped by these reading habits, not just by database tables and API schemas. If discovery only maps the data sources, it misses the mental model that sits above them.

What this looks like in practice

An online academy is a pattern I keep returning to. After a year or two of operation, it typically has quite a bit: an LMS, attendance records, class recordings, assessment results, fee status, batches, instructor schedules, curriculum progress.

On paper, discovery could stop there. The data sources are identified.

But that is not enough.

The real discovery starts when you ask, how does the coordinator know a student is disengaging? Is it attendance? Late submissions? Camera always off? No replies in the class chat? Payment delays? A teacher’s comment after class? A change in tone across three weeks of short responses?

Maybe each of those signals exists somewhere across the systems. Maybe some do not get captured at all. Maybe the experienced coordinator is quietly combining five weak signals before deciding to pick up the phone.

The synthesis a person makes from incomplete, distributed data before acting, is what the intelligence layer needs to understand. Not replace. Understand.

The value is not that AI sees something no one could see. The value is that the system can begin to preserve and prepare what experienced people are already trying to notice.

This is what discovery has to surface. Not “what data do you have,” but “what are people already doing with it, and what does that synthesis look like.”

What discovery should produce

Discovery should not only produce a requirements list. That is a narrow output for a stage that asks a broad question.

At the end of a real discovery phase, we should have a clearer picture of the formal workflow and the real one. Where people assemble meaning manually. Which decision points recur. What data exists and where it lives. What context lives outside the system, in calls, email threads, shared documents, or people’s heads. Where the risks of automating too early are high. And what the smallest useful output would be worth testing.

A good discovery phase may also conclude that AI is not the right first step. The problem may turn out to be data quality, the signals exist but they are stale or inconsistent. It may be process ownership, nobody is clear who should act on the output. It may be something simpler, a better report, a redesigned dashboard, a workflow that needs one decision made about responsibility before any intelligence layer would be useful.

That restraint matters. Discovery that always concludes with “we need an AI layer” is not doing the hard work. It is confirming a predetermined answer.

The output is a sharper question

The purpose of discovery is not to walk away with “we need an agent.” The purpose is to walk away with a scenario clear enough to test.

Can we produce a weekly briefing that helps coordinators identify students who need attention before the weekly call? Can we summarise recurring support exceptions before the operations review? Can we prepare a lead context note before a recruiter responds? Can we surface what changed across three systems before a manager opens the dashboard?

These are better starting points than broad AI ambitions because they are specific, observable, and testable. Working or not working is visible. The scope is narrow enough that someone can tell the difference.

That is why discovery matters. It is not the paperwork before the real work. It is where the real work starts. If we do not understand how people are already interpreting the system, we are not ready to build an intelligence layer above it.