How to Run Discovery That Tells You What Not to Build

A chief executive asked me last month how many people we would need to talk to. I said ten to fifteen. Leadership, plus the managers who actually run the work.

He was surprised it was that many, and more surprised that we wanted the managers rather than just his executive team. Then he made a generous offer: "I can tell you what our problems are, it will save you a week."

He could tell me what his problems felt like from where he sits. That is genuinely useful, and it is a different thing.

What executives can and cannot see

An executive knows the shape. Orders are slow. Reporting is late. The team is stretched. Those are real and they are where the money is.

What they cannot see is the mechanism, because the mechanism is made of small accommodations that nobody escalates. The spreadsheet somebody maintains on the side because the system's export is wrong. The fifteen minutes every morning of reconciling one screen against another. The report that is always late because it waits on one person in a different time zone.

None of that reaches an executive, because none of it is worth a meeting on its own. It only becomes visible when you sit with the person doing it and ask them to walk you through a real one, today, on their screen.

The most common thing I hear in those interviews is a person telling me a number about their own job that surprises them as they say it.

Sizing, in hours and dollars, on every workflow

Every workflow we map gets two figures against it. How many hours a year it consumes, and what those hours cost.

This sounds obvious. It is skipped constantly, because it means saying uncomfortable things out loud, like the fact that a process everyone is proud of costs ninety thousand dollars a year in salary to run.

The sizing does two things. It sorts the list, so we build the expensive thing first instead of the interesting thing first. And it gives you the baseline for free, because the number you measured before the build is the number you will compare against afterwards.

If nobody measured before, you will spend the following year arguing about whether the project worked. I have watched that argument. Nobody wins it.

The list nobody asks for

Here is the part I care most about. Discovery produces a written list of what we recommend you do not automate, with the reason for each.

Things land on that list for four reasons.

The volume is not there. A painful task done four times a year is a bad candidate no matter how much people hate it. Hatred is not frequency.

The process is about to change anyway. More than one client has been six months from a new operations platform. Automating on top of a system you are replacing is paying twice for one outcome.

The judgment is the job. Some work looks repetitive from outside and is not. If the person doing it is quietly weighing five things they have never written down, taking it away produces a worse result and an angry expert.

The data is not good enough yet. If the number is wrong in three systems, automating it publishes the wrong number faster and with more authority. Reconcile first.

That list is where a firm proves it is not just selling you the next thing. Anyone can produce a hundred-page deck of opportunities. Telling a client in writing, with reasons, that four of their eleven ideas are not worth building, at the end of a discovery they paid for, is a different kind of document.

Everything ends in a scope

Discovery ends with a written scope: the team by name, the delivery lanes, the acceptance date, the numbers. A scope, not a range or a proposal.

And the honest ending has to be available. Every engagement starts with discovery, and if nothing is worth building, it ends there. That has to be a real outcome or the whole exercise is theater and the client can tell.

Most of the time there is plenty worth building. But the client should be able to see, from the shape of the process, that "nothing here" was something we could have said.