Why Your AI Strategy Should Evolve as You Build

In From Experiments to Advantage: A CTO Lens on AI Strategy, we argued that AI experimentation should support a longer-term strategy, not become the strategy itself. Organizations need to know what they are building toward, what outcomes matter, and how successful ideas will move beyond the pilot stage.

That still holds. But there is another side to the argument: you cannot discover every part of an effective AI strategy in a conference room.

Some decisions should be made before the first line of code is written. Others become clear only when AI meets the reality of the business: its data, systems, workflows, people, and economics. A promising idea may expose a data problem. A successful prototype may reveal that the workflow surrounding it needs to change. A pilot may prove the technology works while challenging the way the organization originally planned to measure value.

That is why good AI strategy and good AI delivery increasingly happen together. Building the plan while you build the thing does not mean improvising. It means starting with enough strategic direction to build deliberately, then using evidence from the work to sharpen what comes next.

Before an AI initiative begins, there should be agreement on the business problem and why it matters. The organization should understand the outcome it hopes to improve, the people and processes likely to be affected, and the boundaries that cannot be crossed.

What it does not need is a fully resolved answer to every question the project might uncover.

A useful starting point should establish:

• The business outcome: What needs to improve, and what baseline are we measuring against? This will provide the metric to measure success in business value and ROI.
• The hypothesis: Where do we believe AI can change the economics, quality, or experience of the work? Answering this question will provide the foundational north star guidance as you build.
• The boundaries: What security, compliance, human-review, or operational requirements already apply? The answer here will support doing no harm, potentially lead to new standards and understanding the impact of ongoing support.
• The learning agenda: What do we need this implementation to teach us before we make the next investment decision? After a pilot is delivered, you’ll be able to answer should you continue and how much investment you should make.

That last point changes the role of an early AI initiative. A pilot is not simply a smaller version of the finished product. Done well, it is a mechanism for reducing uncertainty.

Effective, practical guides to AI pilots make a similar distinction: early AI work should help organizations determine not only whether an idea can work, but whether it creates enough value to justify further investment. Success criteria should be defined early, then tested with real users, representative data, and real operating conditions.  That is where strategy begins to become more concrete.

Consider a composite example drawn from a common enterprise challenge. An operations team handles a high volume of complex customer requests. Employees receive emails and documents, look up account information, search internal policies, review previous cases, determine what applies, draft a response, and update the appropriate system.

Leadership sees an opportunity for AI. If an intelligent assistant could assemble the relevant context, summarize the request, and prepare a recommended response, employees could spend less time gathering information and more time handling cases that genuinely require their expertise.

The strategic objective is clear: reduce the time and effort required to handle each request without sacrificing quality, trust, or accountability. That is enough direction to start. Then the team begins building, and reality starts adding detail to the strategy.

The original concept assumes the assistant can retrieve the information employees need from internal knowledge sources.

Once the team gets into the work, however, "internal knowledge" proves to be less orderly than anyone expected. Some policies are well maintained and clearly authoritative. Others have multiple versions across repositories. Important information sits inside PDFs, free-form notes, and older systems. Experienced employees know which sources to trust because they have accumulated that knowledge over years, but the organization has never formally encoded those judgments.

The question is no longer simply whether the model can generate a good answer. It becomes whether the organization can reliably give the model the right information, with the right permissions, at the right moment. The build has exposed a strategic dependency.

Now the organization has decisions to make about source authority, content ownership, access, data quality, and governance. It may not need to solve every enterprise data problem before moving forward, but it has learned which ones matter for this use case and which patterns are likely to matter again.

That is the practical side of becoming AI-ready. AI scales on trustworthy, consistent, accessible data, but organizations do not necessarily need to prepare every dataset in advance. They can start with the data required for priority use cases and expand the foundation deliberately.

The strategy has already become more precise than it was at kickoff.

Once enough of the data problem is resolved, the team puts an early version in front of employees.

The assistant works. It retrieves relevant information, organizes the request, and produces a useful draft considerably faster than an employee could assemble everything manually. But observing people use it reveals something the prototype could not.

Employees do not treat every part of the AI output equally. They may be comfortable accepting factual summaries when they can see the supporting source, but they scrutinize recommendations that require judgment. Straightforward cases might no longer appear to require the same approval path, while complex cases need more context before employees are willing to act.

At this point, the question changes from “How do we add AI to this workflow?” to “How should this workflow operate now that AI is part of it?”

Maybe lower-risk requests can follow a faster path. Perhaps the assistant should present options rather than one recommended action when judgment matters. Certain work may remain human-led, while other activities become AI-assisted or automated within defined boundaries.

These are workforce and operating-model decisions, not simply product features.

That distinction is central to AI-Native Workforce Transformation: the goal is not to insert AI into every existing step, but to examine where human judgment creates the most value, where AI can augment people, and where automation can responsibly remove work.

Execution gives leaders evidence for making those choices.

At the beginning, the team planned to measure time saved on research and drafting. That is a logical starting point, but real usage may show that it tells only part of the story.

Suppose AI cuts the preparation portion of the process dramatically, but employees still spend meaningful time validating the result. Or perhaps work reaches the next stage much faster, only to sit in the same approval queue as before. The AI has made a task faster without necessarily making the outcome faster.

Now the measurement strategy needs to mature. Instead of looking only at generation time or usage, leaders may need to measure total handling time, human review effort, exceptions, rework, downstream delays, adoption, and the cost of producing a successful outcome.

A more expensive model, for example, could deliver better economics if employees spend less time correcting its work. A solution with impressive adoption numbers may create little value if the underlying business metric does not move.

An enterprise AI measurement framework that works makes measurement part of the initiative from the beginning, while recognizing that the bar changes as an idea moves from proof of concept to pilot, production, and scale.

The point is not to abandon the original success criteria when the numbers become inconvenient. It is to use real-world evidence to make the value case more accurate.

Now imagine the initiative succeeds. Employees use it. The business sees measurable value. Another group recognizes that similar capabilities could improve its own process.

This is the point where a successful application begins raising enterprise questions.

Should the next team build its own solution? Which capabilities should be reusable? Should teams share model access, retrieval patterns, evaluation standards, security controls, or monitoring? Who decides which AI ideas deserve the next investment? Who owns a capability once it becomes part of everyday operations? If the organization does not answer those questions deliberately, every successful pilot can create another silo.

But if it captures what the first implementation has taught, that project begins creating a repeatable system for the next one. The organization may now have a proven approach to human review, a data-access pattern, evaluation criteria, governance standards, or a clearer method for measuring value. This is where individual projects start becoming an AI program.

SPR’s AI Program Design & Mobilization work focuses on that transition: establishing the governance, ownership, decision rights, measurement, and operating model that connect AI strategy to execution across the enterprise.

The objective is not to centralize every decision. It is to stop solving the same strategic questions from scratch on every project.

Step back from the example, and the organization has learned far more than whether one AI assistant works.

A single initiative has provided evidence about which data needs stronger ownership, how people and AI should divide the work, what success should really mean, and which capabilities need to become reusable if adoption expands.

Those discoveries do not indicate that the organization failed to plan. They are the strategy becoming more informed.

The real test is whether the organization captures that learning. When a useful security pattern emerges, standardize it. When the project reveals a data gap that will affect other initiatives, put it on the roadmap. When employees show where human judgment matters, use that evidence to shape future workflow design. When the economics change, update the investment model rather than clinging to an early assumption.

That creates a simple but powerful cycle:

Strategy provides direction. Execution produces evidence. Evidence improves the strategy. The next initiative begins from a stronger position.

Over time, the questions that once had to be debated project by project become part of the organization's operating model.

Strategy first does not mean strategy finished
AI initiatives still need strategic intent before they begin. Without it, experimentation can become exactly what Part 1 warned against: plenty of activity without a coherent destination.

But waiting for a perfectly resolved AI strategy creates a different problem. It asks leaders to make detailed decisions about data, architecture, workflows, governance, and economics before they have enough evidence to make those decisions well.

The better approach sits between those extremes.

Set enough strategy to build with purpose. Build enough to replace assumptions with evidence. Then feed what you learn back into the strategy before you scale.

That is what it means to build the plan while you build the thing. The strength of the plan is not that it predicts every turn. It is that it gives the organization a disciplined way to respond when new information appears without losing sight of what it is trying to accomplish.

In AI, where capabilities, costs, risks, and expectations continue to change, that ability to learn without losing strategic coherence may prove more durable than any roadmap written upfront.