Your AI Strategy Should Emerge From the Portfolio, Not the Maturity Model

An opportunity-led AI strategy starts with a portfolio that can actually make decisions. If weak evidence leaves twenty ideas looking equally plausible, the organization does not have a shortlist. It has a long list wearing executive clothing.

This is the strategic consequence I keep arriving at after questioning the usefulness of company-wide AI maturity as the default starting point. Maturity can describe the environment in which AI work happens. It can reveal whether governance, data, skills, platforms or adoption need attention. What it cannot do is tell an executive which of the next twenty opportunities deserves another euro, another month of attention or another piece of scarce organizational capacity.

The alternative is not to abandon enterprise strategy and celebrate a thousand disconnected pilots. It is almost the opposite. Start with specific opportunities, motivate the use of AI to quickly demand enough evidence to separate the promising from the merely interesting, then look across the surviving portfolio for the constraints that keep recurring. Those patterns tell you where enterprise capability investment is actually justified.

A shortlist without enough evidence to eliminate ideas is not short.

The first failure is often the portfolio itself

AI strategy exercises are very good at generating possibilities. Put a cross-functional group in a room, show them what modern models can do, and it rarely takes long before the walls fill with opportunities. Customer service. Sales preparation. Contract review. Forecasting. Knowledge retrieval. Engineering support. Procurement. Product discovery. Internal communications. The creativity is useful, and I would rather have too many ideas than an organization that cannot imagine changing at all.

The problem begins when idea generation is mistaken for portfolio construction. If the organization has not collected enough evidence about the underlying problem, the value mechanism, feasibility, internal desirability, ownership and strategic fit, almost every idea can survive the first prioritization round. A scoring workshop may still produce numbers, but the apparent precision hides the fact that the evidence underneath those numbers is weak.

I have seen this end with lists that are technically prioritized but operationally useless. The top ten are separated by fractions of a point. Nobody is confident enough to kill number eleven. Sponsors can still argue that their idea deserves promotion because the assumptions were never tested. The organization has invested time in sorting possibilities without creating a basis for commitment.

This is why the distinction I made in AI Maturity Is the Wrong Unit of Analysis matters beyond assessment design. Once the opportunity becomes the unit of analysis, the purpose of the portfolio changes. The portfolio is no longer a catalogue of what AI might do. It becomes a collection of investment hypotheses at different levels of evidence.

For an opportunity-led AI strategy, a business case is more useful than a readiness score

For a specific opportunity, I care about three broad questions before I care very much about maturity: does it solve a real problem in a financially viable way, is it technologically feasible, and is it internally desirable enough that the people and organization involved will actually make the change work?

Those are not boxes that can be answered once and forgotten. They are evidence domains. Financial viability may begin as a hypothesis about time, revenue, quality, risk or capacity and become more precise as the workflow is understood. Feasibility may depend less on model capability than on data access, integration or operating constraints. Internal desirability may look obvious to an executive and collapse when the people doing the work explain what the proposed change would actually require.

This is also why a license cost is a price, not an ROI calculation. I have had too many conversations in which asking for an AI license felt strangely similar to asking a parent for a new toy. The organization can see the cost immediately. The value is left to the employee to prove after access has already become the contested decision.

That sequencing is backwards. If a team can articulate the painful workflow, the plausible value and the learning it expects from an experiment, the license becomes one input into a business case rather than the business case itself. The discussion becomes whether the opportunity deserves a bounded investment, not whether a software seat feels expensive in isolation.

This extends the Earn the Right to Transform framework. The earlier argument was that cheap experimentation should not automatically become expensive transformation. Here the additional point is that evidence must be gathered at the level where the investment decision lives. Otherwise the portfolio cannot distinguish an attractive opportunity from an attractive technology story.

The portfolio should reveal what the enterprise needs

Once several opportunities have been examined properly, enterprise strategy starts to become visible in a different way. The same blocker appears twice. Then four times. Then it becomes difficult to dismiss as a local inconvenience.

Perhaps several strong opportunities depend on data that teams cannot access reliably. Perhaps governance review repeatedly arrives so late, or operates so defensively, that promising work loses momentum before risks can be designed into the workflow. Perhaps the organization has bought capable tools but employees have no practical method for identifying where those tools could change their work. Perhaps every initiative struggles because decision rights across business, technology, risk and operations remain ambiguous.

At that point, data access, governance, adoption or decision rights have earned their status as enterprise priorities. Not because a maturity model says mature organizations should possess them, but because the opportunity portfolio shows that the same constraint is suppressing value repeatedly.

This distinction matters for governance in particular. Over-protection can look responsible while quietly becoming a brake on organizational learning. The answer is not weaker governance. NIST’s AI Risk Management Framework describes governance as a cross-cutting function that should be infused throughout risk management and performed continuously across the AI lifecycle. That is much closer to the operating model I want than a governance gate positioned outside the work.

Governance should help a valuable opportunity become trustworthy, accountable and scalable. When it is connected early enough to a concrete workflow, governance owners can reason about actual users, data, consequences, controls and escalation paths. When governance is asked to approve “AI” in the abstract, defensive generalization is almost inevitable.

Tool rollout is not the same as problem discovery

One recent professional experience made this especially visible to me. A broad Copilot rollout gave employees access to a powerful tool, while much of the onboarding understandably concentrated on features: what the product can do, how to use the interface, what functions are available. The implicit assumption was that capable professionals would then work out where the tool mattered in their own jobs.

I do not think the problem was insufficient intelligence, insufficient training or insufficient enthusiasm. The missing bridge was problem discovery. Knowing that a tool can summarize, draft, search or transform information is different from recognizing a painful part of your own workflow, reframing it, and designing a better way of working around the new capability. It is awesome, much closer to witchcraft than technology, that AI can generate a photorealistic image of a squirrel playing basketball, but that only becomes learning overhead for someone trying to shorten their reporting overhead by 50% to go home and see their kids.

That difference is visible even in Microsoft’s own current Copilot Adoption Playbook. Microsoft recommends being intentional with seat assignments, defining specific use cases, concentrating licenses in whole teams and helping people build new work habits. In other words, access is only one part of adoption. The value question has to reach the work.

I would take that logic further. Instead of beginning with “Here are the features; find something useful,” begin with “Where is the work painful, slow, repetitive, cognitively expensive or structurally constrained?” Then bring AI expertise to the problem. People closest to the work understand its exceptions, incentives, customer consequences and informal workarounds better than a central function ever will.

This is where decentralization becomes an advantage rather than a governance problem. Departments should be encouraged and rewarded for curiosity about how their business could work differently. The central organization should not try to invent every valuable use case on their behalf.

Centralize enablement, decentralize discovery

My preference is therefore a central AI office with a very specific evolution. Early on, it may need enough separation to develop capability, challenge established assumptions and avoid being absorbed into the priorities of whichever function is politically strongest. Over time, it should become progressively integrated into the company’s value chain rather than remain a permanent innovation island.

The central office should own or coordinate the things that benefit from consistency: shared platforms, architecture, reusable patterns, governance capability, specialist expertise, portfolio visibility and the translation of learning across business units. It should also be able to see when several opportunities are running into the same constraint and make the case for fixing that constraint once rather than forcing each team to solve it locally.

Problem discovery should travel in the opposite direction. Business units, functions and teams should surface the workflows and decisions that matter because they understand the work. Their role is not merely to submit use cases to a central intake form. It is to articulate the business problem strongly enough that the opportunity can be examined, challenged and either accelerated or killed.

McKinsey’s 2025 State of AI survey offers a useful empirical signal for this hybrid model. Among the organizational attributes it tested, workflow redesign had the strongest relationship with respondents reporting EBIT impact from generative AI. The same research found risk, compliance and data governance were often more centralized, while technology talent and adoption were more commonly hybrid or partially centralized. The pattern is not proof of one correct operating model, but it supports the idea that different parts of AI transformation deserve different degrees of centralization.

That is a more useful design question than asking whether the company is centrally or locally “mature.” The question becomes: which capability benefits from common infrastructure and accumulated expertise, and which decision benefits from proximity to the work?

A strong opportunity can be the forcing function for capability

This also changes how I respond when a promising opportunity encounters weak enterprise conditions. I would not automatically delay the opportunity until the company has completed a maturity journey. If the business case is strong enough, I would use the opportunity as the forcing function to build the missing capability.

A consequential problem creates urgency that an abstract capability programme often lacks. Data owners have a reason to resolve access. Governance has a specific risk profile to work with. Security can design around an actual architecture. Leaders can see why adoption support matters. Employees can judge whether the change improves their work. One bounded opportunity can become the first domino in a broader adoption design.

The reverse is equally important. A sophisticated enterprise platform, mature governance process or expensive pool of licenses does not create an obligation to fund a weak opportunity. Capability is an option, not a command to use it. If the economics are vague, ownership is missing or the problem does not matter, the fact that the organization is “ready” should make it easier to say no, not harder.

There is one qualification. A stopped initiative can still be valuable if the organization learns in a way that improves the next decision. Sunk cost is not automatically waste. The relevant question is what it would have cost to discover the same weakness through slower analysis, and whether the experiment produced reusable knowledge. That is the same reason I have argued that an AI portfolio should reward cheap failure before funding transformation.

But learning only has portfolio value when it travels. If each failed pilot disappears into its own project closeout, the organization pays tuition without keeping the education. A central AI capability can help turn local outcomes into shared evidence: which assumptions failed, which controls repeatedly mattered, which workflow patterns transferred, and which supposed opportunities never had a real business problem underneath them.

The Portfolio-to-Enterprise Strategy Loop

The model I would use is deliberately cyclical. Enterprise capability should not sit above the portfolio as a fixed maturity template. It should learn from the portfolio, then improve the conditions under which the next opportunities are explored.

This is not a universal scoring model. It should not become one. The evidence required for a claims workflow, an engineering assistant, a sales process or an industrial maintenance decision will differ because the business goals, consequences and operating context differ. That individual nature is precisely why I am skeptical of replacing one maturity score with one equally generic portfolio score.

The portfolio should create comparability where comparability is useful: evidence strength, strategic relevance, commitment required, unresolved uncertainty and the next decision. It should preserve specificity where specificity determines value.

Strategy emerges when evidence starts to repeat

There is a temptation in enterprise transformation to define the target state first. That is understandable. Executives need direction, budgets need categories and organizations need enough coherence to avoid duplicating infrastructure everywhere. A maturity model is attractive because it gives the future a shape.

AI makes me less comfortable with that sequence because the technology is opening too many genuinely new design spaces at once. Nobody has a complete map of what the AI-native version of every company should look like. The specific economics, knowledge flows, customer relationships, regulatory exposure and operating history of the organization matter too much.

That does not eliminate strategy. It changes where strategy gets its evidence. Instead of asking the organization to become more mature in every dimension and hoping value follows, leaders can let consequential opportunities reveal which capabilities deserve acceleration. The portfolio becomes a sensing mechanism for the operating model.

That is also why maturity does not disappear from the conversation. It becomes contextual. Once several opportunities show that governance capacity is a recurring constraint, governance maturity matters enormously. Once several initiatives reveal that employees cannot translate AI capability into changed work, adoption capability deserves investment. Once the same data problem suppresses value across functions, the enterprise data agenda has stronger evidence behind it.

Enterprise capability should be the answer to repeated opportunity evidence, not a substitute for it.

Whether an AI idea solves a real problem in a financially viable, technologically feasible and internally desirable way can make the maturity question secondary for the next decision. This is new ground for everyone. The organization’s individual nature, its strategy, workflows, people, constraints and ability to learn, is what makes or breaks the initiative.

I would therefore want the next AI portfolio review to end with fewer plausible opportunities, stronger evidence behind the ones that remain, and a clearer view of which enterprise constraints are worth fixing because they are repeatedly standing in the way of value.

That is an AI strategy I can work with: not a maturity narrative imposed downward, but a portfolio of consequential opportunities teaching the enterprise what it needs to become.