The Company Wants AI Everywhere. Where Should It Actually Go First?

The Difficult Problem

AI activity is expanding across teams without a common decision rule. Pilots multiply, vendors overlap, and leaders cannot distinguish useful operating change from demonstrations that never become dependable work.

Executive problems rarely arrive as clean questions. They arrive as missed targets, competing explanations, urgent requests, and partial information. A useful diagnosis must distinguish the visible symptom from the mechanism creating it. It must also identify what is not yet known, because confident action based on a weak premise can make the situation harder to reverse.

The purpose of this framework is not to replace the knowledge of people inside the organization. It is to create a disciplined way to combine that knowledge, expose conflicts, and decide what deserves scarce executive attention. The output should be a small number of owned actions and measures, not another presentation that describes the problem without changing it.

The first operating question is what must remain true while the problem is being solved. That may be liquidity, customer continuity, safety, a regulatory obligation, critical talent, or the ability to reverse a decision. Naming those constraints prevents a fast intervention from destroying the capacity needed for recovery.

The second question is where authority and information meet. A person cannot own an outcome if the essential information arrives late or another function controls every meaningful choice. A useful problem map therefore shows decisions, handoffs, dependencies, measures, and escalation thresholds, not only reporting lines.

Finally, the team needs a learning loop. The initial diagnosis is a working explanation, not a performance of certainty. Each action should produce evidence. Leaders should decide in advance what result would support the explanation, what result would weaken it, and when they will reconsider the plan. That discipline makes speed compatible with intellectual honesty.

What Leaders Usually Get Wrong

• Starting with a model or vendor instead of a bounded workflow
• Choosing the most visible use case rather than a consequential and measurable one
• Ignoring data quality, exception handling, accountability, and the cost of human review

These errors are understandable because each offers the appearance of movement. The test is whether the action changes the mechanism sustaining the problem, preserves necessary options, and creates evidence that the diagnosis is correct.

How I Would Diagnose It

Inventory decisions and workflows, not proposed tools.

For each workflow, define volume, delay, error cost, variability, required judgment, available evidence, and current owner.

Separate work that benefits from drafting or retrieval from work that requires dependable professional reasoning.

Identify a bounded workflow where inputs, acceptable outputs, escalation rules, and a baseline performance measure are available.

Before recommending a larger change, I would run a short operating review with the people closest to the work. The purpose is to compare the formal process with what actually happens, identify exceptions and workarounds, and locate the decision where delay or rework first appears. I would record disagreements rather than average them away, because a disagreement often reveals that teams are optimizing different outcomes. The resulting map should make clear which observation is verified, which is an inference, which assumption needs a test, and what decision can safely be made now.

I would then ask what evidence could disprove the leading explanation. That question protects the team from building a confident plan around the most convenient story. The diagnosis should state assumptions, missing information, and triggers that would change the recommended course.

Simple Action Framework

1. 1. Choose one workflow with a real owner
2. 2. Define the failure that matters
3. 3. Establish the human baseline
4. 4. Test with representative and adversarial cases
5. 5. Deploy with escalation, measurement, and a stop rule

Each action needs an owner, a near-term decision date, and a measure that reveals whether the intervention is working. Measures should describe the outcome or bottleneck, not simply report that meetings occurred or tasks were completed.

The first AI project should create a reusable operating discipline, not merely an impressive demo.

Related work

Watch and read Daily Difficult Problems for short examples of the same diagnostic approach.

Related book · Research and scholarship