Does the right answer already exist on paper, but nobody's running it?

You need Execute, not another round of planning.

Insights

Diagnose, Advise, Build, Execute: a way of working on difficult business problems

Eleven 186 · September 2, 2026

Key takeaways

Diagnose, advise, build, execute is a four-stage way of working through a difficult business problem, each stage with its own distinct output.
Diagnose establishes what is actually happening before anyone recommends anything.
Advise decides what should be done, with rejected alternatives stated openly.
Build creates whatever the advice determined was missing, handed to the people who will run it.
Execute runs the implementation until the change is actually happening, not just planned.

Diagnose, advise, build, execute is a way of working through a difficult business problem in four separate stages, each with its own output, rather than folding the whole thing into one open-ended engagement. Diagnose establishes what's actually happening, Advise decides what to do about it, Build creates whatever is missing, and Execute makes it happen. Keeping the four apart is the part most engagements skip, and skipping it is usually why they fail.

Almost nobody has written down a clear definition of this as a working model, and that isn't because the idea is new. Diagnosis before treatment, and a decision before a build, are old ideas in medicine and in engineering. Business advice just tends to jump straight to a recommendation, or straight to a build, without saying which stage it's actually in.

The four stages, defined

Diagnose: Establishing ground truth before recommending anything. It usually means interviews, a look at the actual numbers, and watching how the work really happens rather than how an org chart says it happens. The output is a written problem statement and a named constraint, and no recommendation yet.
Advise: Deciding what should be done, with the alternatives that were considered and rejected written down openly. Where money is involved the economics get modeled with the assumptions left visible instead of buried inside a single number. The output is a decision the client can make, not one made for them.
Build: Creating whatever the advice said was missing: a process, a piece of software, a data pipeline, a documented procedure, a commercial system. The output is something that exists and works, handed to the people who'll run it, rather than a prototype that needs another six months.
Execute: Running the implementation until the thing is actually happening: partners signed, roles filled, a rollout live, a pipeline producing leads. The output is the change itself, not a plan for it.

The stages are not always sequential

A client can come in at any stage. Most start at Diagnose, because most don't yet know which stage they need. Some already have a clear diagnosis and just want the decision tested against evidence. Others know exactly what to build and only need Execute, because the plan has sat on a shelf for a year and nobody is running it. The four stages describe what kind of work is happening, not a mandatory order every engagement has to walk through from the beginning.

Why the stages get collapsed, and why that causes problems

The most common failure in business advice is starting the recommendation before the diagnosis is finished. A consultant hears the first plausible explanation, usually the one the loudest person in the room believes, and goes straight to a plan built on it. That plan can be executed perfectly and still solve the wrong problem, because nobody separated what was assumed from what was verified.

The second most common failure is the opposite: an organization diagnoses the same problem over and over, in report after report, and never reaches a decision, because nobody was accountable for turning the diagnosis into a choice. Keeping Advise as its own stage, with a decision as its output, forces that choice to actually get made instead of endlessly re-examined.

A third failure shows up once a decision has been made. A team agrees on what should be built and then treats the build itself as detail to be worked out later by whoever happens to be available. Build has to be its own stage with its own output, a working system handed to the people who'll run it, or the decision quietly reverts to whatever was easiest to code first. Execute fails for a related reason: a rollout with no defined end state drifts into an open-ended retainer that never closes, because nobody separated running the implementation from managing it forever.

What keeps this honest is that each stage has a distinct, checkable output: a diagnosis you can hand to a skeptical colleague and have them agree with, a decision with the rejected alternatives written down next to it, a system that works without the person who built it standing over it, and a result that's actually happening rather than a plan that says it will. When a stage can't produce its named output, that's usually a sign it got skipped rather than done.

A worked example

Take a company that makes a specialized industrial component. Revenue had grown for three years running and then flattened, even though the sales team was reporting a full pipeline. The owner suspected a demand problem and was ready to fund a marketing plan.

Diagnose looked at the actual pipeline data rather than what the sales team was reporting, and traced most of the flatline to a six-week gap between a customer asking for a quote and getting a follow-up call, not to a shortage of leads. Advise weighed three options, hiring an inside sales coordinator, buying a quoting tool, or restructuring how quotes routed through engineering approval, and recommended the third, because the bottleneck was an approval step rather than a headcount problem. Build produced a simplified quote-routing workflow with one approval gate instead of four. And Execute ran the rollout with the sales and engineering teams over six weeks, then handed off the new process with documentation the team could maintain without outside help.

Nobody would have found that by starting with a marketing plan. Separating diagnosis from advice from build surfaced the real constraint before anyone spent money fixing the wrong thing. A marketing plan built on the original assumption would have poured more leads into the same six-week gap, made the pipeline reports look busier, and left revenue flat for another year.

How to tell which stage you need

Can you state, in one sentence, what's actually wrong, and would your team agree with that sentence? If not, you need Diagnose.
Do you already know the problem but have more than one plausible way to solve it, with real tradeoffs between the options? You need Advise.
Do you know what should happen, but the thing that needs to exist doesn't exist yet? You need Build.
Does the right answer already exist on paper, but nobody's running it? You need Execute, not another round of planning.

When to get help

Not every business problem needs an outside firm for all four stages. A team with the time and the internal trust to run its own diagnosis often should, and plenty of companies do it well without hiring anyone. Outside help tends to earn its cost in two situations: when the internal team can't get a straight answer because everyone involved has a stake in a particular explanation, or when the four stages keep collapsing into one meeting where the decision gets made before the diagnosis is finished. If neither is true for you, this works perfectly well run internally, with or without us.