AI Strategy 1 - Outcomes and objectives

This series of articles is for people who run businesses and make decisions, rather than for people who build models. It is deliberately non-technical, so that it remains relevant as the technology evolves. It aims to help you develop a good AI strategy and it is based on precisely how we approach all our client engagements, and indeed devise our own internal AI strategies.

Most AI work in a business starts with the technology, which is the wrong place. A decision is made to implement AI, a tool is chosen - typically Microsoft 365 Copilot, ChatGPT Enterprise (OpenAI), or Claude for Work (Anthropic) - then a use is found for it. The question of what the business was trying to achieve arrives afterwards, if at all.

We begin with what the business wants, then with what it currently has, and only then much later do we decide whether AI can be of use, and in what format. Our process has four parts:

1. a ladder from raw facts (data) up to a decision (judgement);
2. the human competencies required for climbing that ladder with technology;
3. technological capabilities and limitations, available tools, and what changes when technology acts on its own; and
4. the recording of consequences and how they feed back in a loop.

We open with the three O’s: Outcome, Objectives and Observability - the one thing the business is trying to bring about, the discrete steps that realise it, and everything that is actually there to be seen. This chapter covers the first two.

Where the chapters say the “business”, read it as whatever unit has been chosen. That can be the entire business if it is small enough, a division, a single role, or even a single outcome. The method is the same at each scale. An outcome, a role or a division can be observed, mapped, and determined on its own terms then assembled with the others to produce a business-wide strategy. We actually prefer the bottom-up approach because of other benefits of working with AI in this disciplined fashion. This should become apparent by the time you have finished the complete series.

The outcome is what the business genuinely wants to bring about. There is one of it. It states the condition the business wants to be in, and that is all it states: not what will be done, not by when, and not how anyone would establish that it had arrived. “Growth” is an outcome unless it is defined by a particular measure, in which case it is an objective. The absence of a measure is not a defect in it. An outcome is the thing everything downstream is set to serve and is judged against, and something that was rewritten whenever the circumstances underneath it changed could not do that job.

The objectives are the discrete steps that together realise the outcome. An objective is a specific thing the business is trying to achieve. “Increase revenue by 25% by the end of the year” is an objective. “Open and trade from a second office by the end of the year” is another. In twelve months, someone should be able to answer definitively whether each objective has been achieved. Every objective has to be contributing to that one outcome. The route to achieving them is a strategy and that strategy is necessarily a hypothesis.

Since an objective is a time-bound proposition about what must be achieved, it reflects the best judgement available when it is set, and therefore depends on assumptions about the market, competitors and the business’s constraints. Those assumptions may cease to hold, subsequently making the objective inappropriate, even though the desired outcome has not changed.

In one of our engagements, with our guidance, the client first described what they wanted the business to achieve - “to create a valuable, measurable and transferable business that delivers reliably for clients, rewards its people fairly, and does not depend on its founder.” That was the desired outcome. They then set out five concrete objectives to realise it:

1. a client-facing view showing the full scope of the work being delivered;
2. a way to quantify the value produced for clients;
3. a basis for incentivising staff according to that value;
4. a lower administrative load; and
5. a business that could be sold within one year without the founder’s involvement.

Each objective was specific enough to test, and every recommendation in the document that followed was tied to the objective it served.

A business can hit every objective it has set and still miss what it actually wanted to achieve. You can complete every step and not reach the outcome, and then the whole thing has failed, whatever the reports say.

This is not a rare occurrence, and it does not feel like failure while it is happening. It feels like progress, because progress is exactly what is being reported. The administrative load falls. The client-facing view is built and used by clients. The value delivered becomes measurable. Every target on the list is met, in sequence and on schedule. Yet, at the end of it, the business is no more valuable, the owner is no less tied to it, or the thing the business actually wanted has otherwise failed to materialise. One or more of the objectives was a guess about a causal link, and that link did not hold.

The objectives themselves cannot detect this. They were each defined so that they could be answered definitively, and each answer is affirmative. The test has to come from above the objectives - from the outcome, together with evidence that it is actually being brought about.

So the outcome is not a vapid statement at the top of a strategy document. It is the standard against which objectives are judged. It is what the business returns to when an objective turns out to have been the wrong guess, so that it can work out what objective (or what strategy) might be right instead. Without it, there is nothing to refer to. A business may achieve all its stated targets yet realise that those targets have not moved it towards what it genuinely wanted. If it has defined success only in terms of the targets, it lacks the language or framework needed to recognise and describe that failure.

The practical consequence is that objectives move, while the desired outcome is comparatively stable. Objectives are supposed to move. They are responses to circumstances, and circumstances change. Rewriting an objective in the light of what has been learned is the system working. Rewriting the outcome every time suggests that it never was an outcome, but only a longer-dated incorrectly classified objective!

We work the same way well below the level of a business. When we build a delegated agent, or write a development task, we set one outcome and let everything follow from it. Beyond the clarity, a single outcome narrows what the agent has to be able to do, and a narrower set of capabilities is a smaller risk, which is a point we return to in the chapters on delegation and on what runs autonomously.

The outcome is the only thing in this series that is chosen rather than discovered. Everything else is derived. The data a business holds is a matter of fact, discoverable through investigation. The information it produces from that data, the knowledge it has interpreted, the decisions it makes and the record it keeps of them all already exist in some state, and the work of the chapters that follow is to observe them accurately.

The outcome, on the other hand, comes from whoever owns the scope of work. In a business, that is the owner or the directors. In a division it is whoever is accountable for it. It has to be stated by a person who has the authority and then it has to be written down, because everything downstream is going to be tested against it.

The objectives at each level (outcome, role, division, business) may not always align. The division may be optimising something the business would trade away. The business may be pursuing something the division only experiences as a cost.

This is normal and it is not automatically a fault. What is a fault is leaving it undeclared, because then the audits that follow will find contradictions and have no way of telling a genuine defect from a legitimate difference of level. This also makes it easier to reconcile the top-down strategy from the bottom-up agglomeration.

In another of our engagements, the notes of an introduction call with a division head recorded the scope of work against outcomes that were critical to the business rather than against their own isolated departmental wins. The focus was deliberately moved from separate implementations of AI to a transformation project across the whole business as the overall framework, without losing the autonomy of the division in the process. When this is considered early and stated explicitly, both desired outcomes can be achieved.

The chapter that follows this one - Observability - maps the business: every person, every process, every handover between them. Done without bounds, that work expands without limit. Everything gets mapped to the same depth, including the parts that could not possibly matter, and what comes out the other end is a document that is complete, accurate, and impossible to act on.

The objectives are what stop that happening. They state which parts of the business matter for what is being attempted, and therefore where the mapping should focus. An audit bounded by objectives produces findings that already know their intended purpose.

This is the argument for articulating the desired outcome first and specifying objectives second as the focus of the audit process. Get the objectives wrong and the audit serves no purpose. Get the outcome wrong, or never state it, and the business can subsequently execute the whole programme faultlessly without achieving anything valuable.