Category: AI Strategy

When you watch a customer support agent resolve tickets end to end in a demo, the workflow looks complete. It reads the complaint, checks the account, drafts the response, applies the credit, and closes the case. The room nods. Then the product reaches production and the real questions begin.

Which refunds can it issue? What happens when the customer threatens legal action? Can it change account status? What data can it read? Who approves edge cases? Where does the audit trail live? How do you reverse a bad action?

These are not secondary concerns you add after the demo. They are the product problem. Agentic products should not expand autonomy until the control system around them can constrain, inspect, evaluate, escalate, pause, and recover from their actions. The first requirement for an autonomous agent is a control system, not independence.

Capability is not the same as control

A capable agent can plan and act. A controlled agent can be limited in scope, tools, duration, and authority before it acts, not just investigated afterward. This distinction matters because agents are no longer only chat interfaces. They can touch files, credentials, commands, customer records, workplace messages, regulated data, and production systems. Once that happens, the product changes category. It stops being only an interface design problem and becomes an operating system for delegated action.

Operating systems do not trust every process equally. They isolate, schedule, interrupt, log, and revoke. Agentic products need the same product instinct. Not because agents are malicious by default, but because delegated action without boundaries turns small model errors into operational incidents.

In a copilot, the user is often the control surface. The system suggests, the user decides, and the scope of damage stays small. In an agentic workflow, the product itself must carry more of that control. It needs permission boundaries, approval gates, escalation paths, logs, evals, rollback paths, and shutdown controls. The team is no longer designing only what the agent can do. It is designing what the agent is allowed to do, how the system knows when to stop it, and who can reconstruct the run afterward.

This is one reason enterprise adoption moves more slowly than the agent narrative suggests. The technology can already perform meaningful multi-step work, but high autonomy remains rare because governance, reliability, integration, and risk tolerance all have to catch up with capability. In my experience, teams are not only asking, “Can the agent do the work?” They are asking, “Can we trust the system around the agent when the work goes wrong?”

The agent control ladder

The practical question when you design an agentic product is not, “How autonomous should this agent be?” The better question is, “What has to be true before this agent earns more autonomy?” I use the Agent Control Ladder as the operating model.

1. Bound the task

Define the exact job the agent can perform. What is in scope? What is out of scope? What counts as overreach? If the agent’s job description sounds like “handle customer operations” or “manage internal work,” the scope is too broad. A controlled agent has a narrow mandate. “Draft refund recommendations for accounts under $500 using approved policy rules” is a better starting point than “resolve billing issues.”

2. Limit the scope of damage

Decide what systems, files, tools, and data the agent can access. Access should be least-privilege, task-specific, and time-bound. Dangerous combinations should be blocked. For example, an agent should not freely combine private customer data, external web content, unrestricted shell access, and production write permissions. The more sensitive the system, the more explicit the boundary.

3. Define human control

Choose the control mode by risk. Some actions require approval before execution. Some allow monitoring with veto power. Some can run unsupervised because the cost of a bad action is low and the workflow is well measured. Human review is a spectrum, not a single pattern.

4. Set escalation rules

Define the thresholds that route work to people. Low confidence, ambiguous intent, policy exceptions, regulated data, customer harm, financial impact, security risk, or missing context should trigger escalation. The queue should have an owner. The owner should have enough context to decide quickly. Escalation cannot be a vague instruction to “ask a human.” It has to be part of the workflow.

5. Evaluate independently

Build evals outside the agent doing the work. Independence is a spectrum. A first version might use out-of-band checks, manual review of traces, red-team cases, and policy tests. Over time, the evaluation layer should become more decoupled from the goal-seeking agent and more continuous in production. The eval layer should review execution logs, not only final outputs. It should test routine cases, edge cases, adversarial inputs, tool failures, and policy conflicts. Manual checks should come before production. Automated checks and production metrics should follow. As autonomy increases, evaluation has to become more continuous.

6. Make behavior inspectable

Log prompts, actions, tool calls, decisions, handoffs, configurations, approvals, and delegated authority. A human should be able to reconstruct what happened. Security should be able to trace access. Compliance should be able to inspect the record. Operators should be able to see where the agent stopped, escalated, or acted. If the trace is incomplete, the autonomy level is too high.

7. Prepare recovery paths

Every serious agent needs pause, override, shutdown, and rollback paths. The team should know how to halt the agent, collect logs, trace access, reverse bad actions, and update controls after an incident. Recovery is part of the product, not an emergency procedure invented later.

Human review is a control mode, not a speed bump

The wrong response to agent risk is to put a person in front of every action. In many systems, that does not scale operationally, and it confuses oversight with control. The useful question is not whether a human should always approve the agent, but which actions need which control mode.

A low-risk, high-confidence workflow can run with more freedom. A medium-risk workflow may need monitoring with veto power. A high-impact workflow needs approval before execution. Some workflows should stay as copilots because the action is too sensitive, too ambiguous, or too hard to reverse.

Consider a support agent. It can summarize a ticket, draft a reply, suggest a policy article, and classify urgency without much friction. It might even issue a small refund when the customer meets clear criteria and the amount falls below a defined threshold. But it should not close an enterprise account, change billing terms, or disclose sensitive customer data without review. If confidence drops, policy language appears, or the customer asks for something outside the agent’s scope, the task should route to a human queue.

That is how autonomy becomes usable. Humans should define success, constraints, allowed actions, stopping points, and review gates. They should not have to micromanage every step. Their job is to set the control plane, not become the agent’s full-time supervisor.

Permissions are the first hard boundary

The more useful an agent becomes, the more access it wants. That is the bargain. A workplace assistant wants email, chat, documents, and project tools because that is where the work lives. A DevOps agent wants logs, terminals, tickets, repositories, and deployment systems because that is where incidents get solved. Every new permission expands what a mistake can touch.

This is why permission design has to come before autonomy design. Agents need narrow tasks, least-privilege access, time-bound permissions, and clear limits on dangerous tool combinations. Sensitive actions need approval. Production writes need review and rollback. Regulated data needs stricter boundaries.

For most high-stakes enterprise workflows, smaller agents with explicit rights reduce risk better than broad “super agents.” Some work requires broad context, but broad context does not require broad authority. A workplace agent that summarizes Slack, email, and documents should not automatically gain the ability to send messages, invite external users, update HR records, or post to company-wide channels. Draft-before-send is a control pattern. So is approval-before-post. So is granting access for one task and expiring it afterward.

Agent identity also matters. If agents act through borrowed human credentials, the audit trail gets muddy. Enterprises need nonhuman identities, delegated rights, session controls, and logs that show which agent acted, under whose authority, with what context, and against which system. Modern IAM already has useful building blocks: delegated access, short-lived credentials, service identities, policy engines, and audit logs. Agent chains expose gaps in how many organizations apply those patterns. If Agent A can spawn Agent B, and Agent B calls Agent C, the organization needs to know where authority started, how it moved, what each agent was allowed to do, and where authority stopped.

Evals have to grow up with autonomy

Teams should not jump from a good demo to production autonomy. A demo shows that an agent can complete a task under favorable conditions. It does not prove that the agent can handle bad inputs, ambiguous policies, poisoned context, missing data, tool failures, or adversarial instructions. Autonomy without measurement is trust by assertion.

The eval system needs to mature with the agent’s freedom. Early workflows can start with manual checks before production. As the agent becomes more central, teams need automated evals in CI/CD, red-team exercises, production metrics, guardrail tracking, and review of execution logs. Agents should not grade their own homework. At minimum, the evaluation path should be out of band from the execution path. The stronger version is a separate evaluation layer that inspects full traces, compares outcomes against customer-specific criteria, and flags failure patterns.

This matters because agent failures often hide in the path, not only the final answer. The output may look plausible while the agent used the wrong data, skipped a policy check, exceeded its authority, or ignored a conflicting instruction. If the system cannot reconstruct the run, it cannot reliably learn from it.

Trust comes from inspectability and recovery

Enterprise buyers do not trust agent products because the model sounds confident. They trust them when the whole operating system around the model can answer operational questions. Who owns this agent? What can it access? What can it change? Where are the logs? How do approvals work? What happens when it fails? Can we shut it down? Can we roll back the action? Can compliance inspect the record later? These are not secondary controls. They are adoption requirements.

A DevOps agent makes the point clearly. It may be useful if it can investigate an incident, read logs, identify the likely cause, and propose a fix. But production writes belong in a different control tier. The agent can draft the change. A human reviews it. The system logs the recommendation, approval, deployment, and rollback plan. If the change misfires, the team can pause the agent and reverse the action. That is a controlled workflow. Without those controls, the same agent becomes hard to approve. It may be technically impressive, but the organization cannot explain what happened after the fact. That kills trust faster than a lower benchmark score.

The ladder in practice

Take a finance or HR agent. At the first rung, it handles routine lookups. It answers policy questions from approved sources, summarizes employee requests, and drafts responses. At the second rung, it gains narrow access to specific records. It can retrieve payroll status or benefits information only for authorized users and only for the task at hand. At the third rung, it starts preparing actions. It can draft a payroll correction, but it cannot execute the change. A human must approve anything involving bank details, regulated data, compensation, or employment status.

At the fourth rung, it uses thresholds. Routine, low-risk requests flow through. Exceptions escalate. Confidence drops trigger review. Policy conflicts route to a specialist. At the fifth rung, independent evals review full traces. They check whether the agent used the right policy, accessed the right records, respected permissions, and escalated correctly.

Only then should the team consider more autonomy. The goal is to let the system earn speed.

The market sells autonomy. Enterprises buy control.

Agent vendors often describe the future as a move from copilots to agents to autonomous operations. That path may be directionally right, but it skips the hard middle. The hard middle is control design.

Enterprises need agents that can act, but they also need agents whose freedom can be bounded, measured, explained, and revoked. They need identity, authorization, auditability, monitoring, escalation, evals, and recovery. They need policy choices about when verification is valuable, morally required, or legally required. That is where many deployments stall. Not because agents are useless, but because a risk owner asks basic control questions and the team cannot answer them yet.

Before asking whether an agent can act, ask whether the organization can constrain the action. Autonomy is useful. But in agentic products, autonomy is the reward for getting control right, not the starting point.

The dangerous question in agentic AI is no longer, “Can the agents talk to each other?” It is, “Who gave them permission to decide?”

That question sounds simple until a workflow goes live. A customer support agent triages a complaint. Another agent retrieves account history. A third drafts the response. A fourth recommends a credit or issues one under a configured threshold. The demo looks clean because the agents coordinate. Then an executive asks why a $2,000 refund was approved. The logs show that the refund happened. They show which tool ran and when. But they do not show which policy version applied, what evidence the agent used, who approved that level of authority, or which human role should have reviewed the exception.

That is one of the governance problems agentic AI exposes most quickly. The shift is from judging outputs to controlling delegated actions. The hard part is not only whether agents can connect to tools, data, models, and each other, but whether the organization can define, constrain, observe, override, and audit what those agents are allowed to do at runtime. Multi-agent orchestration solves a technical problem. It also creates an operating model problem.

The control point has moved

Teams often treat agent orchestration as plumbing. Which model calls which tool? Which agent hands work to the next? Which protocol connects one system to another? Which memory store preserves context? These choices look technical. In agentic systems, many of them carry governance consequences.

If an agent can route a case to collections, that is not just workflow logic. In a governance sense, it is delegated authority. If an agent can send a customer email, modify a record, approve a discount, or submit a purchase order, the organization has granted it action rights. If another agent decides whether a human should review the case, the system now controls an escalation path. Connectivity answers whether agents can interact. Authority answers whether they should be allowed to act.

This distinction matters because enterprise deployments are still hybrid. Most organizations are not handing entire business processes to fully autonomous agent networks. They are combining agents with rules, configuration, human review, service commitments, access controls, and workflow systems. The result is delegated work under constraints, not pure autonomy.

For agentic workflows that can affect real systems, sensitive data, money, customers, employees, or regulated outcomes, deployment review alone is not enough. Traditional AI governance often starts before launch. A team reviews the use case, checks the model, validates risks, approves release, and monitors performance. That still matters. But agentic workflows keep making choices after deployment. They perceive context, reason over goals and constraints, call tools, trigger downstream systems, and coordinate with other agents. They do not merely produce an answer for a human to inspect. They can act. So the control point moves from “Was this system approved?” to “What is this system allowed to do right now?”

General AI risk frameworks still help define governance expectations. Identity governance, privileged access management, segregation of duties, workflow controls, internal audit, NIST AI RMF, ISO/IEC 42001, and the EU AI Act all cover important ground. They do not disappear because agents arrive. The issue is that agentic systems turn those expectations into runtime delegation questions. An AI management system can say the organization needs human monitoring. The workflow still has to define where review happens, what threshold triggers it, which role receives it, and what the agent can do while waiting. A security policy can say least privilege applies. The architecture still has to separate standing privileges from dynamic, session-level permissions. A regulation can require logging. The system still has to preserve the rule version, evidence, approval authority, and action trace for each meaningful decision.

The missing layer is an agent-specific map of authority, accountability, enforcement, and auditability, not “more governance” in the abstract.

Authority is the design unit

An enterprise agent is a delegated actor, not simply software that completes a task. It can be granted rights to see data, update memory, call tools, invoke services, route work, draft communications, make recommendations, and trigger actions. In some cases, it behaves less like an application and more like a privileged user that moves quickly across systems. Before asking what an agent can do, we should ask under what authority it acts.

A procurement agent makes this clear. It might search vendors, compare terms, check budget codes, draft a purchase order, and submit an order. Those tasks do not carry the same risk. Search rights are not purchase rights. Recommendation rights are not approval rights. Drafting a purchase order is not the same as submitting one. Updating a vendor record is different from reading it.

A useful governance model separates those rights instead of treating the agent as one object with one permission level. It asks what the agent can perceive, what it can decide, what it can do, when it must stop, who owns the outcome, and how the organization can reconstruct the decision later. Without those distinctions, teams often overcorrect in one of two directions. They either grant broad authority because the workflow needs speed, or they require human approval everywhere because the risks feel unclear. Both choices are blunt.

Bounded autonomy is the better target. Agents should act independently where the risk is low, the policy is clear, and the action is reversible. They should escalate when the stakes, ambiguity, or irreversibility cross a defined threshold. The goal is to make every autonomous action bounded and traceable.

Decision orphans are the real failure pattern

The risk is not only that an agent does something unauthorized. A quieter risk is that an agent does something no one can explain, own, or resolve. Call these decision orphans: machine-made decisions with no clear origin, no responsible owner, no visible rule version, no preserved evidence, and no escalation path.

They become more likely as agent systems become networks. One agent classifies intent. Another retrieves context. Another applies policy. Another takes action. A vendor tool enriches the record. A workflow engine triggers a follow-up. A human sees only the final result. From the outside, this can look like one automated workflow. Inside, several authorities are at work.

Super-orchestrator designs create a specific version of this risk. They simplify the external interface by hiding multiple internal agents behind a single boundary. That can help the product feel clean. It can also make independent review harder unless the orchestrator exposes internal decision paths explicitly. If the orchestrator made the decision, which internal agent supplied the evidence? Which policy check passed? Which component had action rights? Which team owns the exception?

This is where ordinary telemetry falls short. A log that says “refund approved at 10:42” is not enough for agentic work. Agentic audit trails need to go beyond typical telemetry by explicitly linking actions to the evidence, policy version, delegated authority, approval rule, and accountable owner. Many current implementations stop short of this. The organization needs to answer not only what happened, but why the system was allowed to make it happen.

The agent authority map

Before scaling an agentic workflow, teams need a practical way to see where authority enters the system and how it is controlled. The Agent Authority Map is a review tool for that purpose. It does not replace AI governance programs. It translates them into the operating details of agentic work. Its method is authority decomposition: break the workflow into perception rights, decision rights, action rights, escalation rules, runtime controls, audit requirements, and accountable owners before the system scales. Use it for each agent, agent cluster, or orchestrated workflow.

Identity and ownership. What the agent is, which workflow it serves, who owns it, and whether it acts for a user, team, business unit, or enterprise. The agent has a named business owner, technical owner, risk tier, and operating context.

Delegation chain. Which owner, policy, upstream agent, user, or system can authorize it to act. Authority can be traced across handoffs, including agent-to-agent delegation.

Perception rights. What data, context, tools, and memory the agent can see, use, or update. Sensitive data access changes by purpose, user intent, and risk tier.

Decision rights. What judgments the agent can make, recommend, escalate, or never make. Independent decisions are separated from recommendations and approvals.

Action rights. What systems it can affect and which actions are allowed, denied, or approval-gated. “Can use the CRM” becomes concrete actions such as draft a case note, update status, or request a supervisor-approved refund.

Escalation rules. When the agent must stop, who receives the escalation, what response time applies, and what happens if no one responds. Human review is designed as a trigger, role, channel, SLA, and fallback, not a vague safety promise.

Runtime controls. Which policies are enforced at point of use and which privileges are dynamic rather than standing. Policy checks, session-level authorization, monitoring, and revocation happen during action.

Audit requirements. What must be reconstructable later. Evidence, policy version, approval authority, model output, tool call, memory update, handoff, and action trace are linked.

Accountability. Which humans and forums remain responsible for outcomes, exceptions, changes, and incidents. Delegation changes the operating model without making responsibility disappear.

The map is not meant to create paperwork for its own sake. It gives product teams clearer lanes. If low-risk actions are explicitly bounded, they can move faster without blanket manual approval. If high-risk actions have clear thresholds, governance stops being a last-minute veto and becomes part of the design. Implementation will vary. Some teams will use policy-as-code engines, session-level authorization tokens, AI gateways, runtime guardrails, or platform-native audit hooks. The point is that enforcement has to meet the agent at the moment it tries to act, not the tool category used for enforcement. A system that only authenticates the agent asks, “Who are you?” A governed system also asks, “What are you allowed to do in this context, and how will that rule be enforced right now?”

How the map changes the conversation

Imagine a product team wants to launch a multi-agent customer support workflow. Without an authority map, the review conversation tends to stay broad: Is the model accurate? Are the integrations working? Is there a human review option? Are logs available? Those questions help, but they miss the operating details.

With the map, the conversation becomes sharper. The triage agent can classify tickets and route them. It cannot close regulated complaints. The account agent can retrieve history. It cannot expose payment details to other agents unless the customer intent and risk tier justify it. The response agent can draft messages. It cannot send them when the case involves legal language, policy exceptions, or high-value credits. The credit agent can recommend refunds up to a threshold. It can issue small credits automatically only when the customer type, complaint category, and policy version allow it. Above that threshold, it escalates to a named role. Every credit decision preserves the evidence, rule version, approval authority, and action trace. That is accountable autonomy, not anti-autonomy.

The same logic applies to procurement, finance operations, HR case handling, incident response, claims processing, and field service. Anywhere agents perceive context, make judgments, and act across systems, the authority model has to be visible.

Gateways before scale

The next stage of agentic AI will not be governed by asking whether agents are useful. Many will be useful. The better question is whether the organization can absorb the delegated authority it is creating.

Before scaling an agentic workflow, the organization needs a few gates. Can it trace who delegated authority to whom? Has it separated perception rights, decision rights, and action rights? Does it know which actions are low-risk enough to run independently and which require threshold-based escalation? Are authorization and enforcement happening at the point of use? Can the organization reconstruct the evidence, rule version, approval authority, and action trace after the fact? Can someone pause, revoke, or narrow the agent’s authority when the workflow changes?

If the answer to any of these is no, the workflow is not ready to scale. It may be technically impressive. It may even work most of the time. But it is creating decisions the organization cannot fully own. The organizations that get agentic AI right will not be the ones that connect the most agents fastest. They will be the ones that govern delegated action clearly enough for agents to move quickly without making responsibility disappear.

AI will not replace product managers. It will replace the parts of product management that never required much judgment.

That distinction matters because the current debate is too broad. One side says PMs are safe because product work is human, strategic, and cross-functional. The other says PMs are exposed because AI can draft specs, summarize calls, analyze feedback, update tickets, and generate roadmap decks. Both are partly right.

AI is making product artifacts cheap. A PM can now turn customer notes into a PRD, acceptance criteria, launch messaging, a stakeholder update, and a backlog of tickets in minutes. Agents can summarize meetings, categorize research, draft requirements, analyze customer data, and help with bounded prototypes. That is real disruption. But cheap artifacts do not make product judgment cheap. They make weak judgment easier to spot when teams know what to inspect.

The real story is that AI separates product work that records decisions from product work that merely formats them. The function survives. Many roles as currently practiced will not. As output gets cheaper, the scarce work becomes deciding what matters, understanding customers, making trade-offs, and owning the consequence when the recommendation is wrong.

The floor went up

For years, a lot of PM work looked valuable because the artifacts looked valuable. A well-formatted PRD suggested clarity. A roadmap deck suggested strategy. A business case suggested rigor. A research synthesis suggested customer understanding. Sometimes those artifacts carried real thinking. Often they carried ambiguity in a cleaner container. AI changes that bargain.

If everyone can produce a competent-looking PRD, the PRD no longer proves much. If every team can generate ten analysis cuts, the analysis no longer creates advantage by itself. When every stakeholder request can become tickets, FAQs, launch plans, and update docs by the end of the afternoon, artifact volume stops being a signal of product value. In many product tasks, the floor rises. The ceiling matters more.

This is why the strongest PMs are protected by their ability to make the documents mean something, not by their ability to write better documents. A high-judgment PRD says: we are solving this problem, for this customer, now, because this evidence changed our view. We are not solving these adjacent problems. We accept these risks. We will know we were wrong if this signal moves. A low-judgment PRD says: there is an opportunity to improve the user experience. AI can produce both. Only one is product management.

The artifact is not the problem

It is tempting to say AI automates artifacts and humans keep judgment. That is too clean.

Artifacts matter. Specs, tickets, roadmaps, research summaries, and stakeholder updates create shared reality. They force teams to write down assumptions. They help engineers, designers, sales, support, and leadership coordinate around the same decision. The problem is not the artifact itself. What matters is whether the artifact avoids the decision.

A roadmap deck can be high-judgment if it explains why the company is choosing one market over another. A ticket can be high-judgment if it constrains scope around the smallest useful version. A research synthesis can be high-judgment if it separates a loud anecdote from a recurring pattern. But a deck that lists every stakeholder priority is not strategy. A ticket that translates a request without challenging it is not product work. A synthesis that treats correlation as causation is not insight.

AI can also make shallow work easier to hide, at least for a while. A flood of polished documents can overwhelm scrutiny. That is why teams need to look past format and ask what decision the artifact changed. When they do, AI makes the gap harder to ignore because the container is no longer scarce. The remaining question is whether anyone made the call.

The new scarcity is selection

When production gets cheaper, selection gets more valuable. A PM asks AI to draft a PRD from research notes. The tool produces structure, user stories, success metrics, and risks. A low-judgment PM forwards it for review. A high-judgment PM asks harder questions: which customer problem does this actually solve? Which segment matters most? Which metric would prove value instead of activity? What feature should we remove because it does not serve the core use case? Same artifact. Different work.

Or take analysis. A leadership team gets three polished AI-generated reads on churn. One says churn rose because of a recent product launch. Another points to seasonality. A third points to segment mix. All three sound plausible and cite data. None of them is the decision. The PM’s job is to decide what evidence is causal enough to act on, what remains uncertain, and what change the team will make despite incomplete information, not to admire how well the AI synthesized the data. AI can surface patterns and rank inputs. It can summarize every customer call and every support ticket. But surfacing information is not the same as deciding what matters.

The order-taker PM is exposed

The most exposed version of product management is the order-taking version. This PM receives stakeholder requests, converts them into PRDs, writes tickets, attends meetings, routes status, and produces updates. They may be busy, responsive, and keep the machine moving. But if they do not bring customer evidence, clarify the problem, define trade-offs, challenge scope, or own the outcome, AI can do much of the visible work. In fact, AI may do it faster and with better formatting.

That does not mean the person is lazy or useless. Many organizations trained PMs into this shape. They rewarded responsiveness over judgment. They treated PMs as coordination buffers between executives, engineering, design, sales, and customers. They asked for more documentation instead of clearer decisions. AI exposes that operating model when leaders stop rewarding volume and start looking for accountable decisions.

A stakeholder asks for “just a quick feature.” AI can instantly create a PRD, tickets, a launch plan, a sales FAQ, and a stakeholder update. The product question is still untouched: should this exist, for whom, at what cost, and what will we stop doing? That is the line. If the PM’s value is producing the package around the request, the role is vulnerable. If their value is changing the quality of the decision, the role becomes more important.

Headcount can shrink while judgment gets more valuable

There is a hard truth inside this argument: saying product judgment remains valuable does not mean PM headcount stays stable.

Some AI-native companies are already testing smaller product teams, founder-led product judgment, and prototype-first workflows. Some larger companies are asking a related question: before adding people, what would this area look like if AI agents were already part of the team? These are early signals, not proof of a broad law.

The likely outcome is fewer PMs in some contexts doing work with higher impact, plus more product judgment distributed across founders, engineers, designers, data people, and operators. That last point needs care. Product judgment is a function, not always a job title, but it does not distribute itself. If no one owns customer reality, scope, trade-offs, and the cost of being wrong, the company has not distributed product judgment. It has abandoned it.

In a small AI-native team, a technical founder or senior engineer may own customer reality, prioritization, and trade-offs without a dedicated PM. But in a large company with multiple markets, complex dependencies, and high switching costs, the PM function becomes harder to compress. The question is not “will there be a PM in the room?” The question is: who owns the product judgment?

Strong PMs will use AI more, not less

The answer is not to avoid AI. That would miss the whole shift.

The most effective PMs will use AI aggressively to create options, speed up synthesis, test prototypes, draft first versions, inspect edge cases, and reduce the cost of being wrong early. A PM working on activation might ask AI for ten onboarding variants, generate rough prototypes, summarize recent support tickets, and draft an experiment plan. That is useful. But the product work starts when the PM chooses which customer segment matters, which friction is worth removing, which metric proves progress, and which variant should not ship because it teaches the wrong behavior.

When prototypes are cheap, the PM does not prove value by writing a perfect spec before anything exists. The PM proves value by noticing which experiment deserves more attention, which behavior from users matters, which trade-off the team is about to miss, and which promising demo should not become a product. AI changes the operating model from artifact-first to judgment-first.

It also changes the PM’s relationship to implementation. A technically fluent PM can use AI to explore a prototype, write a precise spec for a bounded change, or understand a code path well enough to ask better questions. But in large-scale production systems, code safety remains engineering work. The PM’s job is to choose the right task, define the right boundary, and preserve expert review, not to pretend expertise in engineering.

AI can also weaken the judgment it rewards

There is a trap here: the PM who uses AI to multiply thinking gets stronger, while the PM who uses AI to replace thinking gets weaker.

This is the risk behind polished work slop. AI-generated professional content can look competent while being hollow. A PM can ask for a research synthesis and receive a confident summary that strips out the messy customer context. They can ask for prioritization and receive a ranked list that reflects broken inputs, biased surveys, incomplete event tracking, or a taxonomy nobody trusts. They might ask for strategy and get a plausible memo that says nothing risky enough to matter.

The real threat is that the PM stops building the muscles to know when the output is wrong. If AI does all the synthesis, the PM loses contact with the raw material. They stop hearing the customer’s phrasing, noticing what sales and support disagree about, and forming the pattern recognition that later looks like taste.

AI should widen the PM’s context, not narrow it into a private prompt loop. That means adding friction in the right places. Before reading an AI-generated research synthesis, write down what you expect to be true based on the last customer conversations you personally heard. When AI clusters feedback, require specific quotes or source links and spot-check the raw material. When it ranks priorities, ask what data is missing, who disagrees, and what the model cannot know from the prompt.

The best PMs will use AI as a thinking partner and production accelerator. They will still talk to customers, argue with engineers, inspect the data, and decide.

The product judgment test

A task is not high-judgment because it has a strategic-sounding name. Someone calling it “strategy” does not make it strategy. A task is not low-judgment because it produces a document. The same PRD can be either, and so can the same roadmap review or AI-generated prototype. Use this test instead.

A product task requires real judgment if it answers at least one of these questions:

1. Customer reality: what first-hand customer evidence changes the decision?
2. Problem selection: is this the right problem to solve now?
3. Trade-off: what are we choosing not to do?
4. Causality: do we know what is driving the signal, or only what correlates with it?
5. Scope: what is the smallest useful version that preserves the customer value?
6. Accountability: who owns the call if the recommendation is wrong?
7. Taste: which of several plausible options is actually worth making?
8. Cross-functional truth: what would engineering, design, sales, support, or customers see that the prompt did not include?

That test changes how teams should assign work: ask AI to draft the PRD, but do not ask it to decide whether the PRD should exist. Ask AI to cluster the research. Do not let the cluster replace customer understanding. Ask AI to generate prototype directions. Do not confuse having ten options with knowing which one deserves the roadmap. Ask AI to summarize stakeholder feedback. Do not mistake consensus for strategy. Ask AI to find signals in the data. Do not let a confident synthesis become causal proof.

Before generating the artifact, ask what trade-off the artifact must record. Before trusting the synthesis, ask what customer reality or cross-functional context the prompt did not include. Before adding headcount, ask which judgment the person will own that AI cannot be accountable for. Before cutting PM headcount, ask who will own customer reality, scope, trade-offs, and the cost of being wrong.

What to do on Monday

If you are trapped in a low-judgment environment, do not start by announcing a new philosophy of product management. Start by changing the artifact.

In your next PRD, add a section called “The trade-off.” Name what you are choosing not to do and why. If there is no trade-off, the PRD may be a delivery note, not a product decision. In your next stakeholder request, answer with the customer evidence you would need to justify it. You can still be responsive. The difference is that you are moving the conversation from preference to proof. In your next AI-generated synthesis, force the output back to source material. Ask for the three customer quotes, data cuts, or support examples that would change the recommendation. Then check at least one yourself.

These are small moves. They retrain the organization to expect judgment inside the work, not decoration around it.

The practical future of PM work

The future PM will spend less time proving they can produce artifacts and more time proving they can improve decisions. That changes what companies should value. Do not measure PMs by document volume. Measure whether they clarify customer reality, reduce wasted work, make trade-offs explicit, and improve decisions under uncertainty.

Do not celebrate AI adoption because teams produce more. Ask whether they learn faster. Do not replace product judgment with AI-generated prioritization. Use AI to reveal more options, then hold someone accountable for choosing.

That does not rescue low-judgment PM work. It raises the bar. More product surface area means more need for people who can decide what matters, not more tolerance for people who can format ambiguity. AI will make product work faster. That is exactly why product judgment matters more. When building gets cheaper, building the wrong thing becomes harder to excuse.

If you work in a large organization, you already know this, even if you have never named it. Most organizations have two versions of the same workflow. One appears in the process map. It has swim lanes, systems of record, approval paths, owners, and service-level expectations. The other lives in the work itself: the spreadsheet someone updates every morning because the dashboard cannot be trusted, the Slack thread that becomes the escalation path, the email chain where decisions happen, and the person every new hire learns to ask because she knows which exception matters.

Leaders often dismiss these workarounds as disorder. Some are exactly that. A few create compliance, safety, privacy, quality, or control risk and need to be corrected, not celebrated. But many workarounds are evidence of a missing operational capability. They show where process, data, ownership, judgment, and systems have drifted apart. That is where AI strategy should often begin.

For COOs, CIOs, transformation leaders, and AI program owners, the question is not where AI can be inserted. The question is where the organization has already invented unofficial work to compensate for missing capability. A missing operational capability is a recurring need the official workflow cannot satisfy: trusted data, accountable ownership, timely escalation, exception handling, cross-functional translation, decision rights, or usable visibility. A use-case list says what AI might do. A roadmap says which workflow constraints must change for AI to matter.

The next wave of agentic AI makes this more urgent. Organizations are being asked to approve agents that route work, prepare decisions, trigger actions, and coordinate across systems. If those agents are pointed at the visible artifacts of broken workflows, they may make the artifacts cheaper while leaving the operating problem intact. I have seen this play out enough times that it is now the first place I look.

The green dashboard problem

Consider a composite example from manufacturing. A production dashboard is green. The formal system says the process is healthy. But three people are watching three different systems. A camera feed shows something odd, but nobody owns the camera. No work order opens. No escalation rule triggers. A Slack channel fills with messages. Someone prints a screenshot. A huddle forms only after the line stops.

The dashboard did not fail because it was green. It failed because the real workflow was somewhere else. The real workflow was in the judgment that the camera mattered, the confusion about who owned the signal, the Slack thread that became the escalation path, and the human huddle that made a decision after formal mechanisms did not.

That is the conformance gap: the difference between the workflow as designed and the workflow as executed.

AI strategy often skips this gap. A team sees the Slack chaos and asks whether AI can summarize the thread. Someone sees the screenshot and asks whether computer vision can detect the issue. Another person sees the huddle and asks whether an agent can schedule meetings faster. Those questions may be useful later. They are not the first questions.

The first question is: why did the formal workflow fail to convert an observed signal into accountable action? The answer might be better instrumentation, clearer ownership, an escalation rule, workflow-native alerting, AI-assisted exception detection, or a change to the operating rhythm. In many cases, automating the visible artifact before addressing the underlying gap preserves the broken workflow at higher speed. In a few cases, automation can surface the failure and force redesign. Either way, the artifact is the clue, not the diagnosis.

The artifact is usually not the real problem

Workarounds announce themselves as artifacts: a 20-tab Excel dashboard, a daily status email, a duplicate tracker, a personal checklist, a side approval path, a risk log, a standing meeting, a shared spreadsheet that everyone pretends is temporary. The artifact is tempting because it is visible. You can point at it, count it, and imagine an AI tool producing it faster.

But the problem is rarely the spreadsheet. The problem is what the spreadsheet has been forced to become.

In frontline logistics, teams share spreadsheets and scheduled daily emails because the formal system does not give them enough confidence about tomorrow’s execution. Supplier updates sit buried in email. People reconcile status manually because no trusted communication layer shows what changed, who owns the next step, and what risk needs attention.

In a go-to-market handoff, the workaround might be a meeting between marketing and sales because the systems disagree. One team defines a lead one way. Another team reports pipeline another way. A CSM checks accounts in a separate place. The handoff depends on memory, relationships, and clarification after the fact. Adding AI to summarize the meeting does not fix unclear routing, missing fields, conflicting reports, or undefined response rules.

The same is true of the “ask Sarah” dependency. Sarah appears to maintain updates, send summaries, clean up docs, run coordination meetings, and remember the status of every exception. But Sarah is reading weak signals. She knows which stakeholder will object. She translates between teams that use the same words differently. She absorbs role ambiguity. She carries informal legitimacy that no system has been given. An AI system can draft Sarah’s update and summarize her meeting. It can generate a risk log. That may give Sarah more capacity for higher-value work. But if the organization has not captured the judgment, trust, timing, legitimacy, and informal feedback loops that made Sarah’s work matter, the AI will make the artifact cheaper and miss the capability.

Preserve the signal, not the workaround

This argument has a hard boundary. Some workarounds are not clever adaptations. They are control failures.

In financial services, regulators have fined major institutions after employees used private messaging apps and personal channels for business communications outside required record-keeping systems. That was a compliance failure, not a shadow workflow to productize.

Healthcare offers a different warning. Research on electronic health record workarounds has found that locally rational behavior can harm patient safety, quality, and efficiency at the system level. Clinicians may bypass a system to complete urgent work, but the workaround can break the audit trail, hide risk, or create downstream errors.

This is why leaders need a triage gate before they treat any workaround as an AI opportunity. If the behavior touches safety, regulated records, privacy, security, financial controls, auditability, or deliberate circumvention, the response starts with risk review, correction, and governance. A behavior that would not pass an audit should not be renamed innovation. If a person could be disciplined for the behavior, do not productize it before the control issue is resolved.

Workarounds are evidence. Evidence can show a missing capability. It can also show unsafe behavior, misconduct, poor training, user resistance, or a control design that people have learned to evade. The work is to tell the difference.

Why AI makes the gap matter more

Before AI, a broken workflow created human cost. People copied data, reconciled reports, chased approvals, sent reminders, and sat in meetings to rebuild context the system should have carried.

Now AI risks amplifying the cost of those failures when leaders misunderstand the work. The evidence on the magnitude of that effect is still developing, but the mechanism is straightforward. AI can produce more reports nobody acts on, route tasks through systems without clear owners, make recommendations from data nobody trusts, and automate approvals without knowing which exceptions require judgment.

McKinsey’s March 2025 State of AI survey found that workflow redesign was the attribute most strongly associated with reported EBIT impact from gen AI among 25 attributes tested. The same report found that only 21% of respondents at organizations using gen AI said their organizations had fundamentally redesigned at least some workflows.

That does not prove workflow redesign causes AI value. Organizations with stronger AI results may simply be more likely to redesign workflows, or another factor may explain both. But the finding is consistent with a practical lesson: AI value is tied to how work changes, not just whether tools get deployed.

Gartner has issued a related warning. In June 2025, it predicted that more than 40% of agentic AI projects will be canceled by the end of 2027 because of escalating costs, unclear business value, inadequate risk controls, or insufficient data quality. Gartner also warned that many use cases marketed as agentic do not need agentic implementation.

These are not abstract readiness categories. They show up in workarounds every day. A reconciliation spreadsheet is often a trust problem. A daily email is often a signal problem. An approval thread is often a decision-rights problem. An “ask Sarah” dependency is often an undocumented-judgment problem.

This is why workaround analysis is different from generic AI brainstorming. It begins with operational evidence. It asks where people already had to invent a shadow workflow to keep the business running, then tests whether fixing that workflow would change something that matters.

Before and after, treated carefully

Public examples are imperfect because many come from vendors. They are still useful when treated as illustrations, not neutral proof.

Axis Bank is one useful case. According to a Microsoft customer story, the bank had manual, email-based, and spreadsheet-driven workflows across branch operations, audit, finance, compliance, and approvals. These were not random bad habits. They signaled missing structured tracking, governance, visibility, and reusable workflow ownership. Axis Bank built a Power Platform Centre of Excellence and scaled governed low-code workflows. Microsoft reports that the bank created more than 120 solutions, reached more than 50,000 users, processed more than 100,000 transactions per month, and reduced operational latency by 40%.

The lesson is not “replace spreadsheets with apps.” What the shadow workflow revealed was a capability gap: structured tracking, governed workflow design, reusable components, and a clearer operating layer.

A similar pattern appears in finance operations. A ServiceNow customer story says Standard Chartered’s Global Finance Operations team moved multiple spreadsheet- and email-based processes into automated workflows, improving transparency and traceability and saving more than 16,800 annual hours. Again, the spreadsheet was not the diagnosis. It was the clue.

The shadow workflow diagnostic

Leaders need a practical way to turn shadow workflows into decisions. Not every workaround deserves investment, not every painful task is worth automating, and not every AI candidate is ready. In my experience, the following diagnostic helps teams decide what a workaround means and what response it deserves.

1. Triage the risk

Before diagnosis, screen the workaround. Does it involve safety, regulated records, privacy, security, financial controls, auditability, or deliberate circumvention? If yes, treat it as a risk issue first. The question is not, “Can AI make this easier?” The question is whether the behavior violates a control or creates unacceptable risk.

2. Observe the workaround

Capture the behavior without judging it too early. Ask what official workflow people bypassed, who uses the workaround, when it happens, what decision or exception it supports, what data people recreated, who became the informal owner, what artifact it creates, and what risk it introduces.

This step matters because many organizations diagnose from complaints instead of evidence. “The CRM is bad” is not enough. “Sales managers export pipeline data every Friday, reconcile it in a spreadsheet, and use that version in the forecast call because they do not trust stage definitions in the CRM” is evidence. Now there is something to study.

3. Measure friction and value

Score the pain, but do not stop there. Look at frequency, labor, delay, error risk, dependency load, and business value.

A workaround that forces 200 employees to copy data across systems every day deserves a closer look. It may also be the best available solution under current constraints. Frequency signals importance. It does not prove the answer.

Every candidate needs an outcome hypothesis. What should change if the workaround is fixed: cost, margin, cycle time, revenue, risk, quality, employee capacity, or customer experience? If no important measure changes, set it aside.

4. Diagnose the capability gap

Name the reason the workaround exists. Most shadow workflows trace back to one or more gaps: data, trust, visibility, ownership, platform fit, judgment, or governance.

A data gap means the system lacks needed information. A trust gap means people do not trust the data, default decision, or approval path. A visibility gap means nobody can see status, ownership, risk, or progress. An ownership gap means roles, queues, escalation paths, or service boundaries are unclear. A platform-fit gap means the system tracks records but does not support the flow of work. A judgment gap means the workflow depends on expertise, interpretation, or legitimacy that has not been captured. A governance gap means review, approval, audit, override, or risk controls are not explicit.

This is where many AI programs go wrong. They identify an artifact, skip the root cause, and automate the artifact.

Take access requests. A request may involve a ticket, an application owner, a manager, billing, license availability, and security review. The tempting answer is an AI agent that approves access. The better answer separates the routine path from the judgment path. If 90% of requests match clear rules, automate that path. If 10% require a real decision, escalate them with context. The goal is to stop wasting human judgment on cases that do not need it while making the real exceptions more visible, not to remove approval altogether.

5. Classify the response

Choose the response before choosing the technology. A workaround may need to be eliminated, standardized, governed, redesigned, integrated, productized, automated, AI-enabled, or deferred.

High-friction, high-value workarounds with high readiness are prime opportunities. Those with low readiness are strategic dependencies: fix the data, ownership, controls, integrations, or process clarity first. High-friction, low-value workarounds are local efficiency problems. Simplify them, template them, or automate lightly. Low-friction, high-value workarounds are risk watches. Monitor, govern, instrument, or clarify ownership. Low-friction, low-value workarounds are noise.

“AI-enable” should trigger a readiness check. Is the data searchable, reusable, and trusted? Are the relevant systems connected? Are decision rights explicit? Are identity, access, authorization, and delegation governed? Can the organization monitor what the AI did and why? Are exceptions defined? Do users understand how their work will change? Is there a business metric tied to the change? If those answers are weak, the opportunity may still be real. It is just not ready.

Not process mining with a new name

Organizations already have ways to study work. Process mining uses event logs to show how processes run through systems. Task mining captures lower-level user activity: application use, clicks, spreadsheets, websites, and repeated desktop behavior. AI use-case workshops gather ideas about where AI could help. All three can be useful.

Shadow workflow analysis asks a different question: what recurring need does the official workflow fail to satisfy? It is especially useful where the important work happens outside clean event logs: judgment calls, verbal handoffs, political navigation, trust gaps, informal escalation, side spreadsheets, and expert dependencies. Process mining shows where work moves inside systems. Shadow workflow analysis shows where the human system repairs what the official system cannot handle. Use both when both are available.

Psychological safety is evidence quality

Shadow workflow discovery fails if people think it is surveillance, blame assignment, or a pretext for replacement. Call it a data-quality point instead of a soft culture point.

If surfacing a workaround feels like volunteering for punishment, the useful evidence will stay hidden. People will clean up the story before they tell it, describe the official process instead of the lived one, and protect the spreadsheet that protects them.

Harvard Business Impact, drawing on Amy Edmondson’s work, defines psychological safety as the ability to ask questions, admit mistakes, and challenge ideas without fear of embarrassment or retribution. In this context, the practical rule is simple: leaders must frame the inquiry as a study of where the system of work fails the work, not where employees failed the system.

That means a few operating rules. Name the purpose before collecting examples: “We are studying where the system forces workarounds, not who broke the process.” Separate discovery from discipline, unless a safety or legal issue requires escalation. Collect patterns before names. Protect the practical expert. The person everyone asks for help is often compensating for missing translation, context, or decision rights.

Make the response menu explicit. The outcome is not automatically automation or headcount reduction. It might be eliminating duplicate work, governing a risky behavior, redesigning a handoff, integrating systems, productizing a local practice, or deferring until the basics are fixed.

Show one closed loop quickly. Pick one low-risk workaround, diagnose it with the team, remove friction, and report back. Trust turns shadow workflow discovery from confession into repair.

The better AI question

The weakest AI strategies ask, “What can AI automate?” A stronger question is, “Where has the organization already created a shadow workflow because the official workflow cannot support the work?”

The strongest question is more precise: what failure made this workaround necessary, and what response would remove, govern, redesign, or productize the need for it?

That question forces leaders to slow down in the right place. It separates artifacts from causes, friction from value, opportunity from readiness, and useful adaptation from dangerous circumvention. It also respects the people doing the work.

A workaround is often a sign that someone cared enough to keep the business moving despite a system that did not fit the job. But respect does not mean preservation. Some workarounds should become supported capabilities, some should become governed workflows, some should disappear, and some should remain deliberately human with better tools around them rather than a new bureaucracy on top of them.

The person maintaining the spreadsheet, the team working in Slack after the dashboard stayed green, and Sarah carrying the unofficial map of how work gets done are not side characters in the AI strategy. They are showing leaders where the official system has lost contact with reality.

Follow that signal carefully. Protect the people who reveal it. Then decide what should be removed, governed, redesigned, productized, automated, or left human. The workaround is the clue, not the strategy.

The worst AI question is also the most common one: “How do we use AI?”

It sounds responsible. It sounds urgent. It sounds like the kind of question a leadership team should ask when the board, investors, or an executive offsite demands proof that the company is moving fast. But it points the organization in the wrong direction. Once the question starts with AI, the answer usually becomes activity: pilots, tools, demos, task forces, infrastructure programs, and slide decks showing where AI might fit. Some of that work teaches. Most of it never turns into value.

A real AI strategy starts somewhere less glamorous: with painful customer or business problems. It asks which workflows are expensive, slow, repetitive, judgment-heavy, document-heavy, or hard to coordinate. Then it asks whether AI changes what is now possible, whether the value is measurable, and whether the solution can survive production.

That distinction matters now because the first wave of enterprise AI experimentation is running into a wall of unrealized business impact. Gartner’s 2025 IT spending research found that failed AI proofs of concept commonly break down because they do not demonstrate value, reveal additional needs too late, or fail to show enough business impact. Other industry research points in the same direction: many AI leaders are under pressure to justify investments that still have not produced the returns executives expected. AI can create value. The issue is that many organizations confuse AI activity with AI strategy.

AI activity looks productive until it has to produce

Picture the pattern. A board asks the CEO, “Where is our AI strategy?” The CEO turns to the executive team. The executive team turns to business units, IT, product, and outside consultants. Soon the company has 20 proofs of concept.

One pilot summarizes customer calls. One adds a chatbot to an internal portal. One drafts sales emails. One searches policy documents. One promises to automate reporting. The demos look polished. The steering committee sees motion. Everyone can say the company is doing AI.

Then the hard questions arrive. Which customer pain does this solve? Which business metric moves? Who owns the workflow after the pilot? What data does it need? What happens when the system is wrong? Who approves production access? How does this affect cost, throughput, revenue, risk, or retention? Too often, no one has a good answer.

This is why “how do we use AI?” is such a dangerous starting point. It sends teams looking for places to attach the technology instead of problems worth solving. It rewards visible experimentation, not disciplined selection. The failure data points in the same direction: AI initiatives often stall because they fail to demonstrate value, lack sufficient business impact, or uncover additional needs too late. That does not mean the starting question is the only cause. Data readiness, governance, integration, risk, ownership, and change management all matter. But starting with AI makes those problems easier to avoid until the demo is over.

A proof of concept asks “can we make this work?” A proof of value asks “does this change anything that matters?” Most AI strategies need fewer proofs of concept and more proofs of value.

The better starting point is painful work

The strongest AI opportunities often begin with boring work. Not visionary work. Not brand-new work. Not work that makes for the most exciting demo. The best candidates are the tasks people already hate: reading documents, comparing reports, cleaning spreadsheets, routing exceptions, checking status across systems, preparing summaries, reconciling records, drafting first-pass responses, or finding the few issues that deserve human attention.

These workflows share a pattern. They are repetitive enough to matter, but not simple enough for older automation. They involve text, judgment, messy inputs, unstructured data, or context spread across systems. They waste time, but they also require enough interpretation that a basic rule or script could not handle them. That is where current AI capabilities change the economics of work.

A customer does not wake up wanting an AI feature. They want to get rid of the spreadsheet, stop digging through reports for three hours, have fewer manual follow-ups, or see a claim, invoice, ticket, or underwriting file move faster without losing control. The same logic applies inside the company. A workflow owner can usually name the pain before anyone mentions AI: “Our onboarding takes too long.” “The system says we have inventory, but the warehouse cannot find it.” “Managers spend hours reading reports before they know what to fix.” “Our team handles the same customer exceptions every day.” “People are copying data between tools because the systems do not talk.”

Those symptoms are strategy inputs. They tell you where work is breaking, where cost hides, and where current tools have failed. AI strategy begins when the team stops asking where AI can fit and starts asking what work should change.

AI is not the differentiator. Redesigned work is.

For a while, saying “we have AI” sounded like a product strategy. That window is closing. As generic AI tools become widely available, access to AI stops being the source of advantage. The durable advantage comes from workflow design, domain expertise, proprietary data, operational discipline, and a clear understanding of customer constraints.

That explains why so many AI features feel thin. A vendor adds an AI widget to the corner of a product. A team embeds a chatbot into a workflow no one wanted to use in the first place. A product markets itself as agentic without changing the actual customer outcome. The AI model is visible. The value is not.

The stronger pattern hides the AI model behind a solved workflow. In insurance, for example, the valuable work is not “ChatGPT for underwriting.” The valuable work is reading documents, extracting context, identifying missing information, comparing details, preparing the file, and reducing the busy work before a regulated human decision. In that setting, the system does not need to replace the decision maker to create value. It needs to make the decision path faster, clearer, and more reliable.

That is the strategic shift. The question is not “where can we add AI?” The question is “what work can now be redesigned because machines can interpret language, documents, patterns, and context at scale?”

Pain is necessary, but not enough

Problem-first does not mean “pick a painful workflow and start building.” That is still too loose. A painful problem can fail as an AI initiative for at least five reasons.

First, the use case can be too small. Saving 26 minutes a day for one person may be useful, but it does not automatically create a financial case. CFOs will ask whether the time savings become lower cost, higher throughput, faster revenue, better retention, reduced risk, or avoided hiring.

Second, the use case can be too complex. Some workflows need too many integrations, too many permissions, too much judgment, or too much exception handling to make sense as an early project.

Third, the data can be unready. Generic AI tools do not fix broken enterprise data. If the required data is fragmented, low quality, trapped in legacy systems, or governed inconsistently, the AI system inherits the mess.

Fourth, the risk can be wrong. The more useful an AI system becomes, the more important access controls, monitoring, escalation paths, and human review become. A summarizer with no system access has one risk profile. An agent that can update records, send messages, or trigger transactions has another.

Fifth, the pilot can fail at production. A demo can work with clean examples and still fail when it meets real users, edge cases, security rules, latency requirements, audit needs, and workflow ownership.

This is where many AI strategies collapse. They mistake relevance for readiness. A problem-first approach removes one kind of failure: building something no one needs. It does not remove the harder failures of data readiness, integration, governance, change management, and measurement. That is why the strategy cannot stop at problem selection. It has to test whether the problem can become a production system.

The value-readiness gate

Before the next AI initiative gets budget, it should pass a simple test. Not a 60-page business case. Not a theoretical AI roadmap. A practical set of questions that force the team to move from AI activity to strategy.

Problem and value fit

1. What painful customer or business problem are we solving? If the answer starts with the technology, stop. A strong answer names the pain in operational terms: manual report review, delayed claims processing, duplicate data entry, slow customer follow-up, inventory mismatch, document comparison, exception routing, or hours spent searching across systems. The problem should be painful enough that someone already feels it.

2. Why can AI solve this better now than older tools or processes could? AI is not better for every problem. It is more likely to matter when the work involves unstructured data, language, pattern recognition across large datasets, judgment support, or context spread across many sources. If a rules engine, workflow tool, dashboard, or process fix solves the problem more simply, use that. AI is not the goal. Solving the problem with the right tool is.

3. Who experiences the value, and what KPI proves it? User delight is not enough. Time savings are not enough unless they convert into something the business can measure. The value might show up as lower cost per case, higher cases per employee, faster cycle time, fewer stockouts, reduced external agency spend, better first-contact resolution, lower risk, or avoided backfill. Different problems need different metrics.

This is where the CFO becomes useful, not obstructive. Finance forces the team to define whether the gain is real, measurable, and worth scaling. A useful pressure test is simple: if the value case converts time saved into financial return, who has already agreed that time saved will change headcount, throughput, spending, or capacity?

Workflow and operating fit

4. What workflow, task, or decision will actually change? A strategy-grade initiative changes work. It might reduce the number of steps in a claim review. It might prepare an underwriting packet before a human decision. It might route customer issues automatically when confidence is high and escalate uncertain cases when confidence is low. It might turn four hours of seller research into 15 minutes of account preparation. If the team cannot say what changes in the workflow, the initiative is still a concept.

5. What data, systems, permissions, and integrations are required? This question separates demos from deployable systems. A customer-service agent that only suggests responses has one set of requirements. A self-directed system that resolves issues across billing, shipping, and CRM systems needs governed data access, identity controls, audit trails, permissions, and integration with core systems. Many failed AI projects do not fail because the model is weak. They fail because the surrounding system is not ready.

Risk and production fit

6. What risks, guardrails, and human review points are needed? The right level of autonomy differs by workflow. Some tasks can be automated end to end. Some should be drafted by AI and approved by a person. Some should use AI only to focus human attention on the right issue. Some should not be automated at all. In regulated workflows, the best design often separates preparation from judgment: AI can read, summarize, compare, flag, and route, while a human still makes the final decision. Good strategy names that boundary before deployment.

7. What has to be true for this to move from demo to production? This is the question most pilots avoid. Production means ownership, support, controls, measurement, training, feedback loops, and exception handling. It means the system works when data is messy, when users push back, when the answer is uncertain, and when the workflow crosses departments. A pilot that cannot answer this question is not ready to scale. It may still be useful for learning, but it should not be mistaken for strategy.

The seven questions do not prove the project will succeed. They do something more immediate: they reveal whether the team is ready to spend real money, or only ready to produce another impressive demo.

The counterargument is real: infrastructure matters

Some technology leaders will object to the problem-first frame. They will say an AI strategy has to start with data infrastructure, governance, security, and platform investment. They are partly right. If the company’s data is siloed, untrusted, poorly governed, or trapped in decades-old systems, no problem-first workshop will magically create production value. Some organizations need serious work on data ownership, lineage, access controls, integration, and platform architecture before AI can scale.

But that does not make the argument infrastructure-first instead of problem-first. It means the two have to meet. Platform investment needs a portfolio of real problems to justify its shape. Problem selection needs infrastructure reality to avoid fantasy. The mistake is treating them as alternatives.

The same distinction applies to experimentation. Some organizations need early AI pilots to build literacy, test governance, and learn what the technology can do. That is legitimate capability building. But capability building has to be named as such. It is not the same as claiming the company has a value-producing AI strategy. Experimentation teaches. Strategy selects.

Before you fund the next AI initiative

A good AI strategy does not look like a list of tools to test. It looks like a set of operating choices. It names the painful workflows worth changing. It explains why AI changes the solution space. It defines the business value before the build. It decides where the human stays in the loop. It identifies the data and systems required. It names the risks and controls. It sets the threshold for production.

That kind of strategy can still move fast. Problem-first does not mean slow. It means directed. A team can pressure-test the value-readiness gate in a short sprint, then decide where deeper discovery is needed. The point is to stop funding initiatives that cannot explain why they should exist, not to bury AI work in analysis.

This is also how companies find stronger opportunities. Much of the highest-return work in enterprise AI will not be where budgets first went. Back-office automation, operational workflows, and domain-specific work often create more value than visible front-office experiments because the pain is clearer and the work is closer to cost, capacity, and throughput. That should not surprise anyone who has watched enterprise software closely. In large organizations, the most valuable technology frequently starts in the least glamorous workflow.

Before asking “how do we use AI?” ask “what painful work deserves to change?” Before calling something strategy, ask whether it can pass the proof-of-value test. An AI idea says “here is where AI fits.” An AI strategy says “here is the problem we are solving, why AI changes the answer, what work will change, how value will be measured, and what must be true for this to run in production.” That is the difference between looking serious about AI and doing serious work with it.