Discovery Is the Project

I blocked twenty minutes for the scoping call. One question on the agenda: list your ventures. Six hours later I was still going, and I had a whiteboard that looked less like a business structure and more like a family tree with secrets in it.

The client is a business owner in the Gulf running what he described, on our first call, as "a few companies." That description was not wrong. It was just useless as a foundation for anything. By the time we finished, we had surfaced multiple registered entities across two jurisdictions and three different legal forms, plus ten active email addresses spanning three distinct working lives — one personal, two commercial, each with its own counterparties who had no idea the others existed.

None of that was on the agenda. All of it was the project.

what actually happened

The engagement was supposed to be straightforward: build him a personal AI chief-of-staff. Something that reads his inbox, tracks commitments across his businesses, drafts replies, keeps a live picture of what he owes to whom. The kind of system that sounds like a two-week build until you try to specify it — I wrote about that lesson separately in What Running an AI Chief of Staff Taught Me About Enterprise AI Adoption.

Because to route an email correctly, the system has to know which business it belongs to. To know that, it needs a model of the businesses. And the model has to be his model — not a plausible one, not a tidy one, but the one that matches how money and obligation actually move.

So I built a venture taxonomy. It was wrong.

I rebuilt it. That one was wrong too. Halfway through the second pass, an entity surfaced that I had been treating as an operating business and which turned out to be a management company — it employed people, it held contracts, it invoiced the others, but it produced nothing for an external customer. Peer in the org chart. Not a peer in the taxonomy. Then another one, which I had modelled as its own venture, turned out to be a single revenue line inside a larger holding structure and belonged as a sub-folder rather than a sibling.

Three restructurings. Live, on the call, with the owner watching me drag things around and saying "no, that one sits under the other one." That is not a failure mode. That is the work.

the fix — write the map down, with an exit

The taxonomy stabilised on the fourth version. What I did next is the part that matters more than the structure itself.

I wrote it up as an architecture decision record — a short, dated document that says: here is the structure we chose, here is what we considered and rejected, here is why, and here is exactly what we would do to reverse it. That last clause is not decoration. It reads something like: if entity X later needs to become a top-level venture, these are the four things that have to be renamed, these are the two routing rules that break, this is roughly how long it takes.

Naming the cost of reversal changes the decision. It is why I now treat "we might be wrong about this" as a design input rather than an admission. When reversal is documented and cheap, you stop needing to be right on the first pass — which is fortunate, because on structural questions I am rarely right on the first pass, and neither is the owner. He has lived inside these entities for years. He still needed three attempts to describe them in a form a machine could route against.

There is a second half to this. Later in the same engagement, we had a meeting transcript that needed to become roughly 25 project entries in the system. Obvious move: let the system parse the transcript and batch-create all 25. Fast, clean, done in ninety seconds.

He refused. He wanted them one at a time, each one shown to him, each one explicitly approved before the next.

It took about forty minutes instead of ninety seconds. And it caught things — items that were really the same project described twice, one that belonged to a venture we had just restructured, two that were not projects at all but someone else's action items. Batch creation would have produced 25 perfectly-formed wrong records. The automation would have worked flawlessly against a map that was still settling. That is exactly the pattern behind Automation That Survives Contact With Reality.

That is the thing about a wrong model. It fails silently. The system does not throw an error when it files an invoice under the wrong company — it files it, confidently, forever.

four questions to answer before you commission any AI work

Everyone budgets for build time. Almost nobody budgets for discovery, and discovery is not a preamble to the project. It is phase one of the project, and on a system like this it is comfortably 40% of the effort.

Before you sign anything, answer these yourself, in writing:

1. What do I actually own, and in what legal form? Not "a few companies." Every registered entity, its jurisdiction, its form, and its relationship to every other one. If two entities invoice each other, say so. If one exists purely to hold or manage, say so. This list is almost always longer than the owner's mental version.

2. Which of these are real businesses, and which are containers? A management company, a holding vehicle, and an operating business look identical on a licence certificate and behave completely differently in a workflow. Containers route; businesses transact. Getting this backwards is the single most common structural error I see.

3. How many identities do I operate under, and who knows about which? Count the email addresses. Count the phone numbers, the signing names, the personas you use with different counterparties. Ten addresses across three lives is not unusual for an owner-operator in this region. Every one of them is a routing rule someone has to write.

4. What am I willing to have a machine do without asking me? Draw the line before the build, not after the first bad outcome. Reading, summarising, and drafting are usually safe. Creating records, sending anything, and touching money usually are not. My default is one-at-a-time approval on anything that writes, until the owner has watched it be right for a few weeks.

If you cannot answer these, no vendor can build you anything better than a confident guess.

why this bites harder here

In a large Western corporate, this discovery is half-done before anyone shows up. There is an org chart, a chart of accounts, a CRM with an entity hierarchy, a compliance function that has already been forced to write it all down. The map exists. Someone was paid to maintain it.

In the Gulf, and specifically in the lean owner-operator businesses that make up most of the real economy here, that map lives in one person's head. A locally registered entity here, an offshore holding structure there, a partnership from a deal in 2019 that never quite got wound down. Six people, four companies, one founder holding all of it together by memory. It works — genuinely, it works, and it is fast — right up until you try to hand it to a system.

And the incentive runs the wrong way. The lean team is exactly the team that most needs the automation and has the least patience for a discovery phase. "Just build it, I'll tell you if it's wrong." You will not. You will notice in month four, when a client email has been quietly filing itself under the wrong business the whole time.

Same reason the region is a good place to do this well, by the way. The structures are complicated, the teams are small, and the upside from a system that genuinely understands the shape of the business is enormous — much bigger than in a company that already has forty people doing the routing manually.

what I do now

I run structured discovery as a paid, scoped first phase in every engagement — never bundled in, never treated as pre-sales. It ends with two deliverables: a written model of the business, and a set of decision records with explicit reversal clauses for every structural call we made. The build starts after that, against a map both sides have signed.

I have not yet had a discovery phase where the first version of the structure survived. Not one. I have stopped treating that as a problem to solve and started treating it as the thing being paid for. It is also why The Real Cost of AI Projects is usually higher than the proposal in front of you suggests — the discovery line that got left out does not disappear; it gets paid for anyway.

If you are looking at an AI project and the proposal in front of you goes straight to build — no discovery line item, no mention of what happens when the model of your business turns out to be wrong — that is worth a second conversation before you sign it. I did exactly that mapping work for this client, and the six hours we spent on it is the reason the system actually works. If you're running a business in the Gulf or anywhere else and no vendor has asked about your structure yet, a consulting day with me starts with exactly that map: what you own, how it connects, and what the system is allowed to do without asking. Book a consulting day or send me an inquiry first if you'd rather talk before booking.