Why an advisory report is not capability

An advisory report tells you what to do. It does not tell you how, and once the consultants leave, you are on your own. That is not a criticism of advisory firms as a profession, it is an observation about what a report can and cannot be.

We are not neutral here, and we do not want to hide that: this is exactly why Radical does not write advisory reports and instead builds alongside you. This piece explains why that difference matters, not just for us but for the outcome you get.

What a report does well

A thorough advisory report is not useless. It brings structure to a chaotic problem, it forces a company to name priorities out loud, and it gives leadership a document to circulate and discuss internally. For that function a report is a fine instrument.

Where it goes wrong is when the report gets presented as the endpoint instead of the starting point. A hundred-page analysis ending in "implement AI in customer service" has done the easy part. The hard part, how you actually pull that off with the people and systems you have, is not in it.

A stack of papers on a table. The hard part is not in the document.

Why "what" is easier than "how"

It is no coincidence that reports often stop at "what". The "what" is generic: every company in a sector has roughly the same opportunities, and those can be named fine with some market research. The "how" is specific to your company: which systems you have, who will resist, which data turns out not to hold up once you look at it.

You do not discover that specific "how" by thinking about the company. You discover it by actually starting, and that is precisely the part a report by definition skips, because a report is written before anything is built.

What happens when a report sits on the shelf

This is the pattern we run into most often at companies that went through an advisory process before. The report was well received, everyone agreed with the conclusions, and six months later it sits in a drawer, because nobody ever answered who would execute it and with what time.

That is not a failure of the report itself. It is a failure of the assumption that a report produces execution on its own. See also our pieces on why AI pilots run aground and why an AI scan is not an IT project: in both cases the problem is not the analysis phase, it is the gap between analysis and execution.

A conversation at the table. Building together leaves knowledge with you, not with the adviser.

A recognisable example

A mid-sized company has an advisory firm write a report on AI opportunities in customer service. The report is thorough: thirty pages, a SWOT analysis, three scenarios with expected return. Everyone on the management team is impressed.

Six months later it turns out nobody started. Not because the report was bad, but because there was no answer to who would execute it, with what time, and what the first concrete step was. The report described a destination without a route. That is exactly the pattern RAND documents under a different name: fading ownership, only here before the project even properly began.

The difference between advice and capability

Advice produces knowledge at the adviser. Capability produces knowledge at you. That is the whole difference, and it decides what remains once the project is done.

After an advisory process you have a document and an invoice. After a process where you helped build it yourself, you have people who know why a system does what it does, who can adjust it, and who can build the next application faster and cheaper because they lived through the first one. See also building capacity without your own AI team for what that knowledge transfer looks like in practice.

That difference is exactly why we always end a scan in a roadmap you can execute yourself, and why the next step, the Capability Sprint, is about building together with your people at the table, not building something for you and throwing it over the fence.

Four questions to tell advice from capability

Who executes it once the external party is gone? A good answer names someone on your side. A bad answer names nobody, or points back to the party that wrote the report.

Is there a concrete first step named, or only a direction? "Invest in AI for customer service" is a direction. "Build this specific application with these two people this quarter" is a step.

Does building start during the project, or only after? A project where the first working application appears during the project itself produces proof. A project ending in recommendations produces a promise.

Does the knowledge stay with you or with the adviser? Ask explicitly what happens to what was learned. A good answer describes how your people take it over. An answer that stays vague usually means it stays with the adviser.

What to do with this

Before starting an advisory process, ask for answers to the four questions above. A party that cannot answer them is selling you a report. A party that can is building alongside you.

About this page

This piece describes our own position and approach, based on what we see happen at companies that went through an advisory process before. It is not a criticism of individual advisory firms, but of the model where a report is the endpoint instead of the starting point. This is the state of play on 27 August 2026.