Tales & Co.

Istanbul — San Francisco

Notes

Diagnosis

7 min read

What Is a Business Diagnostic

The term gets used loosely enough that it has stopped meaning anything specific. It has one job: to describe the business accurately before anyone is paid to change it.

A business diagnostic is a description, not a recommendation.

The phrase shows up in two very different documents. In one, it is the name for a short, structured exercise that produces a written account of what is actually happening inside a business, built from evidence rather than from the opinions already in the room. In the other, it is a label a proposal wears on its cover page while the pages inside argue for a specific fix. Only the first one is a diagnostic.

A diagnostic answers what is true, not what should be done about it. That distinction sounds small until it is missing. A document that opens with findings and closes with a recommended solution has already made the second decision inside the first one, and the reader has no way to tell which sentences were evidence and which were advocacy dressed as evidence.

The confusion is not accidental. A diagnosis that stays neutral is harder to sell, because it does not arrive with an answer attached. A diagnosis that quietly points toward the diagnostician's own service is much easier to commission, because the buyer gets the reassurance of a document and the vendor gets a foregone conclusion. Most of what circulates under the name is the second kind.

The test is simple to apply and rarely applied: read the document and ask whether the recommendation could have come out differently if the findings had come out differently. If the answer is no — if the same three-phase engagement would have been proposed regardless of what the evidence showed — the findings were decoration on a decision made before the diagnostic began.

It answers a narrower question than the one that starts it.

A diagnostic is usually requested because something is visibly wrong: churn is up, a launch underperformed, a function feels permanently understaffed, growth has stalled after two good years. The person requesting it wants to know why. That is not, in fact, the question a diagnostic answers first.

The presenting complaint and the scoped question

The presenting complaint is almost always a symptom stated at the wrong altitude — too broad to investigate directly, and too shaped by whoever is describing it to be trusted as the full picture. The first work of a diagnostic is converting "why is churn up" into a question that can actually be checked against records: which cohort, over what window, compared to what baseline, and against which of several plausible causes that a leadership team has not yet separated from each other.

That narrowing is not evasion. A question broad enough to explain everything is usually too broad to be tested against anything, and a diagnostic that never narrows its question ends up confirming whatever the sponsor already believed, because there was no sharper claim available to disprove it.

This is also where a diagnostic and a consulting sales process most visibly diverge. A sales process wants the broad question kept broad, because the broad question is what justifies a broad, expensive engagement. A diagnostic wants the question narrow, because a narrow question is the only kind that produces a finding instead of a restatement.

Narrowing also forces a choice that most companies avoid making explicitly: which of the plausible explanations gets tested first. Churn being up could mean the product degraded, the sales team changed who it sold to, a competitor repriced, or the support queue got slower without anyone tracking it. A diagnostic that tries to hold all four open at once produces a report that hedges on every page. One that picks the most testable explanation, tests it against the record, and either confirms or rules it out before moving to the next produces an actual answer, even when that answer is only "not this one."

The output looks unglamorous, and that is by design.

A finished diagnostic is not a strategy document. It rarely contains a single slide with a memorable framework on it. What it contains is closer to a case file: a reconstructed timeline of what actually happened, a set of interview notes checked against records rather than taken at face value, and a short list of where the account people give of the business and the account the business's own data gives of itself stop agreeing with each other.

Those discrepancies are the product. Not the interviews themselves, not the data pull, not the org chart — the specific points where what people say and what the numbers show diverge, because that divergence is usually where the real problem is hiding, several layers under the one that got named out loud.

A useful diagnostic typically produces:

  • A written account of what happened, reconstructed from records, not memory alone.
  • A short list of named discrepancies between the stated problem and what the evidence shows.
  • One or more working explanations for the divergence, stated so they could be wrong.
  • An explicit boundary: what the diagnostic did not have enough evidence to settle.

That last item is easy to skip and does the most work. A diagnostic that claims certainty everywhere is usually one that stopped asking questions before it ran out of evidence, not after.

It is not an audit, and it is not the first week of an engagement.

The nearest neighbor to a diagnostic is an audit, and the difference is worth being precise about. An audit checks a business against a fixed external standard — an accounting framework, a compliance regime, a security control set — and its finding is a gap between what exists and what the standard requires. A diagnostic has no external standard to check against. Its comparison is internal: what the organization believes about itself versus what its own evidence shows. An audit can be run by a checklist. A diagnostic cannot, because the questions worth asking are not known in advance.

Sold-in-advance work wears the same name

The other neighbor is more common and harder to spot: a "diagnostic phase" positioned as the opening week of a consulting engagement that has already been sold. In that structure, the diagnostic is not an independent instrument, it is a warm-up act for a solution the firm already intends to propose, because the firm's commercial interest is in the engagement continuing, not in the diagnosis landing somewhere inconvenient for that continuation.

That does not make every vendor-run diagnostic dishonest. It does mean the reader has to ask who benefits if the finding turns out to be smaller, cheaper, or entirely different than the engagement that was pitched alongside it. A diagnostic worth trusting is one whose finding was allowed to be inconvenient before anyone knew what it would say. The proposal that wins the engagement is usually where this gets decided, months before the diagnostic itself is staffed.

One practical marker separates the two. An independent diagnostic can end with "there is no problem here worth the cost of solving," or "the problem is smaller than the one you named, and the fix is a policy change, not an engagement." A pre-sold diagnostic almost never ends that way, because that ending has no next step for the firm that wrote it. If a diagnostic has never once told a client the expensive answer was unnecessary, that is worth noticing.

Company size changes what a diagnostic can see.

The same word covers very different exercises depending on scale. In a small or early-stage company, most of what a diagnostic needs is conversational — the founders and the first few hires hold most of the institutional memory in their heads, and the discrepancies show up quickly because there are few layers between the complaint and its cause. In a larger organization, the same exercise runs into something structural: the people closest to the symptom rarely have visibility into the decision that produced it, and the people who made that decision are several conversations removed from the symptom itself.

That gap is why a diagnostic in a larger business leans harder on documents than on interviews — minutes, tickets, revenue and cost data, prior post-mortems — and treats what people say as one input to check against the record, not the record itself. Which method to lean on for a given question is not incidental; the four methods available to a diagnosis answer different questions, and picking the wrong one is how a diagnosis ends up with an answer to a question nobody was actually asking. It is also why a diagnostic that only interviews leadership, without reading anything the organization produced before the diagnostic began, tends to reproduce leadership's existing account rather than test it.

None of this changes the definition. It changes how much evidence-gathering the definition requires before a finding is safe to write down.

Where the description becomes the brief.

The practical use of a diagnostic is that it produces a brief a company can act on, or shop, on its own terms — before it has committed to who does the acting. A description written before a vendor is chosen belongs to the company. A description written by the vendor who is about to be hired belongs, at least in part, to that vendor's interest in the outcome.

The description has to exist before the proposal, or the proposal is the only description anyone ever sees.

This is the shape of the diagnostic work described elsewhere on this site: run before a shortlist is built, evidenced against records rather than the loudest account in the room, and honest about where it ran out of certainty. Companies that run this step before commissioning consulting work are buying a service on a scope they defined, rather than a scope the service provider defined for them.