Imagine two companies approving the same proposal: “Deploy a generative AI sales copilot.” The wording is identical. In the first company, account managers lose hours assembling scattered product, contract and service information before client meetings. In the second, the information is already present and the actual problem is that managers are rewarded for renewing easy accounts rather than developing difficult ones. The first company may need better retrieval and synthesis. The second needs different incentives and portfolio governance. One AI use case describes two unrelated strategic situations.

The confusion begins when a technology label is allowed to do the work of a diagnosis. “Copilot”, “agent”, “personalisation” and “predictive maintenance” sound concrete because they suggest a product. Yet none says which business outcome is impaired, what currently prevents improvement, why that constraint matters more than competing constraints, or what would count as a better result. A use case can be technically specific and strategically empty.

The central claim of this paper is that the strategic unit before an AI use case is a falsifiable constraint-to-outcome hypothesis. It connects a material outcome gap to a binding constraint, identifies the recurring decision or action through which that constraint operates, and predicts how an intervention would change verified results. AI enters only after this chain is credible. This order is not procedural hygiene. It determines what gets built, how value is measured, where authority sits, and when the work should stop.

Part IWhy a strategic problem must come first

Strategy is concerned with choice under constraint. Michael Porter’s account of strategy centres on a distinctive position supported by trade-offs and a fitted system of activities. Richard Rumelt’s strategy kernel begins with diagnosis before guiding policy and coherent action. Nickerson and Zenger go further by treating the problem as a unit of analysis: the complexity and structure of a problem affect how solution search should be organised. These views differ in emphasis, but they converge on a useful warning. A list of desired actions does not substitute for an explanation of the challenge.

An AI use case sits on the action side of that divide. It tells us where a capability might be applied. It does not tell us whether the intended outcome matters enough, whether the proposed task controls that outcome, or whether intelligence is scarce at that point. This is why organisations can assemble hundreds of plausible ideas while remaining unable to explain what would become structurally different if any of them succeeded.

A goal is not yet a problem

“Increase revenue”, “reduce cost”, “improve experience” and “manage risk” are goals. They become useful only when joined to a present mechanism. A regional distributor may want fewer stock-outs. The strategic problem might be that daily replenishment decisions use weekly demand signals, that field reports arrive too late, that minimum order quantities are economically wrong, or that depot managers override recommendations without recording why. Each diagnosis points to a different change.

A good strategic problem has six clauses. It names the material outcome gap, the binding constraint, the consequential decision or action, the change mechanism, the trade-off that keeps the choice honest, and the falsifier that would weaken the diagnosis. Written in one sentence:

Because constraint C distorts or delays decision D, outcome O remains below an agreed threshold; changing mechanism M should improve O within boundary B, unless observation F shows that another constraint dominates.

This sentence is intentionally technology-neutral. If it cannot be written without naming an AI product, the team probably knows its preferred answer better than it knows the problem. That is a discovery signal, not a drafting inconvenience.

Thought experiment: unlimited intelligence, unchanged institution

Suppose every employee receives a flawless reasoning assistant at zero cost. It reads all permitted documents, predicts likely consequences and explains its reasoning. Nothing else changes: incentives, approval limits, data rights, operating capacity, queue priorities and legal duties remain as they are. Which outcomes improve?

Where missing analysis is the constraint, performance should move. Where a manager already knows the right action but lacks authority, no amount of reasoning changes the decision. Where a warehouse lacks physical capacity, better forecasts may simply describe the shortage earlier. Where customers do not trust the use of their data, more capable personalisation can increase resistance. The thought experiment removes model capability as a scarcity and exposes the remaining structure.

This matters because AI performance is uneven across tasks. In the field experiment that introduced the “jagged technological frontier”, consultants using GPT-4 performed substantially better on tasks inside the tested frontier, but people who used it on a task outside that frontier were more likely to give the wrong answer. In a separate field study of customer-support workers, access to a generative assistant increased issues resolved per hour on average, with larger gains among less experienced workers. Neither result licenses a general claim that AI raises productivity everywhere. Together they show that effect depends on task, worker, workflow and boundary.

Part IIFind the constraint that actually governs the outcome

A binding constraint is the condition whose relaxation would materially change the target outcome, given the rest of the system. It is not necessarily the most visible irritation. Teams often select document drafting, search or summarisation because these activities are easy to demonstrate. Yet a visible task can be non-binding. Saving fifteen minutes on a memo has little strategic value if the application then waits six days for an approval committee.

The practical test is counterfactual: if this constraint disappeared tomorrow, would the outcome move enough to matter? If the honest answer is “we do not know”, the next investment is a diagnostic experiment. If the answer is “no”, the use case should not proceed merely because a model can perform the task.

Six constraint families

Most early AI proposals can be tested against six families. Information constraints concern missing, late, fragmented or inaccessible evidence. Judgement constraints concern prediction, interpretation or choice under uncertainty. Coordination constraints concern hand-offs, incompatible goals or work crossing organisational boundaries. Incentive constraints concern what people are rewarded, punished or permitted to do. Capacity constraints concern labour, time, capital, physical assets or throughput. Legitimacy constraints concern trust, rights, explainability, fairness, law or social permission.

These families interact. A credit officer may face poor information and high workload, while the organisation also requires accountable human judgement. The purpose of classification is not to force one label. It is to prevent the information-shaped solution from swallowing every other cause.

How to establish a constraint without manufacturing certainty

Begin with cases, not opinions about the average process. Select a small but deliberately varied sample: routine and exceptional cases, successful and failed outcomes, different teams, different times of day, and cases where experienced staff disagree. Reconstruct the sequence of evidence, decisions, waits, reversals and hand-offs for each one. The trace should distinguish work time from queue time, error creation from error discovery, and formal procedure from the path people actually use. Twenty well-chosen traces often reveal more about a constraint than a large survey of preferred solutions.

Next, build an error and delay taxonomy. An error attributed to “poor quality” may arise from missing evidence, a mistaken judgement, an ambiguous policy, a rushed reviewer or a downstream system that cannot represent the chosen action. Treating all five as model-quality failures creates a false aggregate. Code the proximate failure, the upstream condition and the point where recovery became possible. Preserve disagreements between reviewers instead of forcing premature consensus. Disagreement can reveal that the decision standard itself is unstable.

Then look for variation that can separate rival explanations. If one depot receives promotion data six hours earlier than another, compare the resulting replenishment errors while holding assortment as steady as practicable. If two underwriting teams use the same evidence but different approval thresholds, compare rework and delay. If a temporary staffing increase removes the queue without changing judgement quality, capacity becomes a stronger explanation. These are not automatically controlled experiments, but they produce sharper questions than a capability demonstration.

Finally, run a small constraint-relaxation test. Supply the missing information manually, temporarily change an authority threshold, simplify one hand-off, or reserve extra capacity for a bounded sample. The test asks whether relaxing the suspected condition moves the target outcome. It need not contain AI. In fact, a manual intervention is often preferable at this stage because it isolates the mechanism from model errors and integration work. If the outcome moves, the team has earned the right to ask how the change can be made reliable and economical. If it does not, the diagnosis must change.

The constraint-substitution test

Before specifying AI, compare it with the strongest non-AI intervention. This is the constraint-substitution test. If a process rule, data repair, queue redesign, training change or authority shift could remove the same constraint more cheaply and safely, AI has not yet earned priority. The comparison is not hostile to AI. It protects AI investment from being burdened with problems it cannot solve.

Worked example: replenishment at a regional food distributor

Consider a synthetic distributor supplying 1,200 stores from four depots. Managers propose a demand-forecasting model because stock-outs average 7.8 per cent in the fastest-moving lines. The initial diagnosis appears straightforward: better predictions should reduce missed sales. A two-week trace of 240 replenishment decisions, however, shows that forecasts are already directionally adequate. The larger losses occur after the forecast. Field promotions arrive through email, depot constraints are updated once daily, and planners manually translate case quantities into pallet orders. Forty-three per cent of avoidable stock-outs in the sample follow a late promotion signal or a preventable order-conversion delay; only seventeen per cent align with large forecast error. These numbers are illustrative, not observed company facts.

The binding constraint is coordination latency. The first intervention is a shared event schema, earlier promotion cut-off and deterministic case-to-pallet conversion. A lightweight model may later classify unstructured promotion messages or flag anomalous demand, but it is not the strategic centre. If the company had begun with forecasting accuracy, it could have improved an upstream metric while leaving the commercial outcome almost unchanged.

Part IIITurn diagnosis into a designable problem

A strategic problem is not complete when it merely sounds plausible. It must be precise enough to allocate attention, set boundaries and design evidence. The following six questions convert the diagnosis into an investable problem brief.

The six questions

What outcome is materially below potential? Use an operational result rather than an activity count. “Shorter time to responsible credit decision” is stronger than “more generated credit memos”. The outcome should have an owner, a baseline and a time horizon.

Which recurring decision or action controls that outcome? Locate the point where information becomes commitment. This could be an underwriter setting conditions, a planner releasing stock, an adviser choosing the next action, or a maintenance engineer scheduling intervention. The decision locus tells the team whose work, authority and evidence must change.

What is the binding constraint? Record observations that support it and a competing explanation. A bottleneck map, queue trace, error taxonomy, diary study or controlled sample is often more valuable here than a broad ideation workshop.

Why is this problem strategic? A problem is strategic when it affects a material outcome, interacts with a scarce or differentiating capability, requires a consequential trade-off, or changes the organisation’s position. Routine efficiency can still be worthwhile, but it should not borrow the language of strategy.

What must be refused? Strategy needs a boundary. The team might refuse autonomous decline decisions, broad rollout before causal evidence, use of unverified external data, or optimisation of speed at the expense of customer recourse. A boundary reveals the actual choice.

What observation would change our mind? The falsifier could be a queue analysis showing that approval capacity dominates judgement quality, an experiment showing no outcome lift from better information, or evidence that users bypass the workflow. A diagnosis that survives every result is an identity, not a hypothesis.

Worked example: the commercial-credit problem brief

Take a synthetic bank that wants an “AI credit-memo generator”. A closer trace shows three delays: analysts rekey financial data, specialists wait for sector evidence, and exception cases circulate between credit and relationship teams. The memo itself takes ninety minutes in a process lasting twelve business days. Automating prose could improve analyst experience while barely moving the customer outcome.

A stronger problem brief reads: “Because sector evidence and exception rationales are assembled inconsistently across three teams, medium-complexity credit decisions exceed the eight-day service threshold and require avoidable rework. A governed evidence workspace with traceable retrieval and structured exception reasoning should reduce rework and time to decision without shifting approval authority or weakening adverse-decision explanation. The diagnosis fails if queue analysis shows that committee capacity accounts for most delay.”

Now AI has a defined job. Retrieval can gather permitted evidence, language models can propose structured rationales, and validation can test citation fidelity and exception handling. The intervention excludes approval authority. Its outcome is time to a responsible decision, not words generated. Its falsifier protects the team from automating the memo when the real bottleneck is the committee calendar.

This is also where risk context becomes part of strategy. NIST’s AI Risk Management Framework makes context mapping prior to measurement and management. Its Map function asks organisations to document intended purpose, deployment setting, benefits, costs, risk tolerance, tasks, knowledge limits and human oversight. It explicitly supports an initial decision that an AI solution may be inappropriate. That is not a compliance appendix. It is a disciplined form of problem definition.

Current adoption figures make this separation more important, not less. Eurostat reports that 19.95 per cent of EU enterprises with at least ten employees used an AI technology in 2025, rising to 55.03 per cent among large enterprises. Diffusion shows that access is widening; it does not show that a particular deployment changes a strategic outcome. The OECD’s 2026 digital-government analysis identifies weak processes for measuring financial and non-financial impact as a core barrier to informed investment. The lesson for firms is direct: adoption is an activity measure, while strategy requires an outcome mechanism and an evidence system.

The strongest rival: experiment first, strategy later

The strongest objection is that AI is moving too quickly for extended diagnosis. Cheap prototypes can reveal possibilities that executives cannot specify in advance. A firm that insists on a complete strategic problem before touching the technology may miss emergent uses, underestimate capability and learn more slowly than competitors.

This objection is partly right. Search can precede full diagnosis when the problem itself is uncertain. The error is to confuse a bounded learning probe with an investment thesis. A two-week prototype may test whether a model can classify customer intent or whether users find a new interaction valuable. It should carry a learning question, a small exposure boundary and a stopping rule. The prototype earns expansion only when its evidence connects capability to a material outcome.

Exploration and strategy therefore use different contracts. Exploration asks, “What might this capability make possible?” Strategy asks, “Which consequential constraint should we commit to changing, and what are we willing to forgo?” The first expands options. The second concentrates resources. Organisations need both, but trouble begins when exploratory demos inherit production budgets without crossing the diagnostic gate.

Thought experiment: delete AI from the investment paper

Take a proposed AI programme and remove every reference to models, agents, prompts, vendors and automation. Leave the target outcome, affected decisions, operating constraints, trade-offs, evidence plan and recovery path. What remains?

If the paper collapses into phrases such as “improve productivity” or “enhance customer experience”, technology was carrying the argument. The team cannot yet explain the problem independently of its preferred capability. If a coherent case remains, replace AI with the strongest feasible alternative. Could a policy change, better interface, additional specialist, deterministic rule or simpler integration produce the same outcome? If any substitute appears equally credible, design a comparison rather than granting AI an assumed advantage.

Now reverse the deletion. Keep the AI component but remove the firm-specific data, workflow position, authority, human expertise and outcome feedback. If value disappears, those complements are doing much of the strategic work. The model may still be necessary, but it is not sufficient. This observation changes the investment map: fund the rights, evidence and operating changes that make the capability effective, not only the inference layer.

The deletion test can also expose a legitimate technology-led option. Suppose a new multimodal model permits a field engineer to diagnose equipment from sound and video where no affordable alternative existed. Removing the model destroys the mechanism even after the problem remains clear. The use case now has a stronger claim, provided a bounded test confirms accuracy, safety and economic value. The thought experiment does not presume that AI is incidental. It makes the claim prove itself.

Counterexample: when the use case can reasonably come first

In a young product category, customer behaviour may be too fluid for a stable problem statement. A small team might release a reversible AI interaction to observe what users attempt, treating usage as discovery. Here the use case is an instrument for finding the problem. The boundary matters: exposure is limited, harm is low, rollback is easy, and the team does not claim strategic value before evidence arrives. The counterexample weakens any rigid rule that diagnosis must always be complete. It does not justify unbounded deployment.

Part IVUse an evidence gate before solution design

The operational artefact below turns the paper’s argument into a decision record. It avoids a composite score because weak evidence should not be hidden by arithmetic. A proposal passes only when each load-bearing element is supported. “Unknown” routes the team to discovery. A credible non-AI substitute routes it to comparison. A missing outcome, constraint or decision locus stops AI framing.

The instrument returns four possible postures. Ready for bounded AI design means the problem, mechanism and boundary are specific enough to design an experiment. Run diagnostic discovery means one or more causal elements remain unknown. Compare the non-AI intervention first means a simpler change may remove the constraint. Stop solution framing means the proposal lacks a material outcome, decision locus or constraint.

A positive result from the gate does not prove that the AI intervention works. It permits a better experiment. The experiment still needs a baseline, representative cases, quality and risk measures, adoption observation, cost boundaries, and a comparison against current practice. The gate protects problem quality; it is not a substitute for technical evaluation or causal inference.

Who owns the strategic problem?

Ownership should follow the outcome, not the technology budget. The executive who controls the target result owns the problem hypothesis and trade-off. The operational decision-maker owns workflow truth and must be able to reject an unusable design. Finance tests the value boundary. Risk and legal define obligations, affected parties and unacceptable exposure. Data and engineering establish feasibility, controls and recovery. The AI team owns the capability evidence, not the business outcome by declaration.

This division prevents a common failure in which everyone advises and nobody can stop the work. Before an experiment begins, name the person who may authorise exposure, the person who may halt it, the person accountable for downstream load, and the person who will judge whether the outcome moved. A steering committee can coordinate these rights, but collective discussion should not obscure individual authority.

Failure boundary: local optimisation can worsen the system

The most dangerous success is a use case that improves its local metric while damaging the end outcome. Faster draft generation can enlarge a review queue. More fraud alerts can reduce investigator attention per case. More personalised offers can increase short-term conversion while eroding trust. Better forecast accuracy can be economically irrelevant when replenishment rules cannot act on it.

The defence is to measure across the causal spine. Pair the local capability metric with the operational outcome, downstream load, error distribution, human overrides, affected-party experience and recovery cost. If the intervention shifts rather than removes work, the design must include that transfer. If affected people cannot challenge a consequential output, speed should not be counted as unqualified value.

A 30-day problem-first operating rhythm

During the first week, select one material outcome and collect direct traces of the work that produces it. Observe decisions, waits, overrides, error categories and information arrival. Do not ask participants only where AI might help; ask what prevents a better outcome and what they do when the standard path fails.

During the second week, formulate two competing constraint hypotheses. For each, identify the strongest non-AI intervention and the smallest observation that could discriminate between explanations. This is where disagreement is useful. Finance, operations, technology, risk and affected users often see different parts of the system.

During the third week, run the cheapest informative test. Rearrange a queue, supply missing evidence manually, simulate a rule change, or conduct an offline model comparison. The aim is not to impress a steering group. It is to learn whether changing the suspected mechanism moves the outcome.

During the fourth week, write the problem brief and take it through the gate. If AI remains justified, define the system boundary, human authority, permitted context, evaluation cases, outcome measures, risk tolerances and rollback path. If another intervention wins, fund it. The organisation’s objective is not to maximise the number of AI deployments. It is to improve important outcomes with the least fragile mechanism that works.

{
  "outcome": {"name": "", "baseline": "", "threshold": "", "owner": ""},
  "decision_locus": {"decision": "", "actor": "", "frequency": ""},
  "constraint_hypothesis": {"family": "", "evidence": [], "rival": ""},
  "change_mechanism": {"intervention": "", "ai_role": "", "non_ai_substitute": ""},
  "boundary": {"included": [], "excluded": [], "authority_retained_by": ""},
  "test": {"falsifier": "", "kill_condition": "", "recovery": ""}
}

Glossary

Use case: a bounded description of how a capability is applied in a context. Strategic problem: a consequential outcome gap explained by a constraint and a choice about how to address it. Binding constraint: the condition whose relaxation would materially change the outcome, given the rest of the system. Decision locus: the recurring point where evidence becomes commitment or action. Falsifier: an observable result that would weaken the diagnosis. Negative control: a case or intervention expected not to produce the claimed effect, used to detect mistaken attribution.

Sources

1. Porter, M. E. (1996). What Is Strategy? Harvard Business Review. The paper’s account of choice, trade-offs and activity fit grounds the distinction between strategy and an action list.
2. Rumelt, R. P. (2011). Good Strategy/Bad Strategy: The Difference and Why It Matters. Crown Business. Diagnosis, guiding policy and coherent action are used as an established strategy kernel.
3. Nickerson, J. A., & Zenger, T. R. (2004). A knowledge-based theory of the firm: The problem-solving perspective. Organization Science, 15(6), 617–632.
4. Dell’Acqua, F., et al. (2026). Navigating the jagged technological frontier: Field experimental evidence of the effects of artificial intelligence on knowledge worker productivity and quality. Organization Science, 37(2), 403–423.
5. Brynjolfsson, E., Li, D., & Raymond, L. R. (2025). Generative AI at work. The Quarterly Journal of Economics, 140(2), 889–942.
6. Noy, S., & Zhang, W. (2023). Experimental evidence on the productivity effects of generative artificial intelligence. Science, 381(6654), 187–192.
7. National Institute of Standards and Technology. (2023). Artificial Intelligence Risk Management Framework 1.0.
8. NIST AI Resource Center. AI RMF Core: Map. The Map function establishes context, intended purpose, business value, risk tolerance, tasks, limits and the initial go/no-go decision.
9. OECD. (2025). The Adoption of Artificial Intelligence in Firms. OECD Publishing.
10. OECD. (2026). Adopting and governing AI in government. Digital Government Outlook 2026.
11. Eurostat. (2026). Use of artificial intelligence in enterprises. Official EU statistics for 2025 adoption by firm size and business purpose.
12. European Banking Authority. (2020). Guidelines on loan origination and monitoring. Used to bound the synthetic credit example; no empirical result is attributed to a bank.

ConclusionName the constraint before naming the capability

The question before an AI use case is not “Where can we apply AI?” It is “Which material outcome is held back by which constraint, through which decision, and what evidence would show that we are wrong?” That question may still lead to a model, agent or intelligent workflow. It may lead instead to cleaner data, different authority, simpler rules, more capacity or a decision not to intervene.

This discipline does not slow useful innovation. It shortens the distance between experimentation and a result worth having. It gives technical teams a real mechanism to design for, executives a trade-off to own, risk teams a boundary to govern, and operators an outcome they can verify. Most importantly, it permits the strategically mature answer that an AI use case is premature.

Begin with the outcome gap. Trace the decision. Test the constraint. Compare the substitute. State the falsifier. Only then name the capability.