Working Theories

Why do enterprise AI projects fail?

Most enterprise AI projects don’t fail because the model is insufficient. They fail because the surrounding organization isn’t prepared to turn a technical capability into a dependable way of working.

A successful demo proves that a model can produce an interesting result under controlled conditions. It does not prove that employees will trust that result, that the necessary context will be available, that someone will own exceptions, or that the workflow will survive contact with security, governance, procurement, and quarterly priorities.

Organizations also tend to add AI to existing processes without questioning the processes themselves. That can make an inefficient system faster without making it better. A broken approval chain with an AI summary is still a broken approval chain.

The more useful questions are operational:

• Who owns the outcome?
• Where does the necessary context come from?
• Who decides whether the output is good enough?
• What happens when it is wrong?
• What behavior must change for the capability to matter?
• Which existing steps can now disappear?

Enterprise AI becomes real when it changes how work moves—not when it produces an impressive response in a conference room.

What does a Forward Deployed Product Manager do?

A Forward Deployed Product Manager works in the space between what a product is designed to do and what a customer actually needs it to do.

That sounds similar to implementation, consulting, customer success, or solutions engineering because the work frequently touches all four. The difference is the direction in which the learning travels.

The job is not simply to help a customer adopt the existing product. It is to understand where the product, workflow, organization, and customer reality fail to line up—and turn that friction into product signal.

That may involve designing a workflow, troubleshooting an implementation, clarifying a use case, coordinating engineering, reframing expectations, or recognizing that the customer is asking for a feature when the real problem is ownership.

Forward-deployed product work is especially valuable in emerging categories because neither the product nor the customer’s operating model is finished. The product team needs exposure to reality, but raw customer requests are not a roadmap. Someone has to interpret what is happening, separate the local exception from the recurring pattern, and decide what the product should learn.

The role exists because the distance between a compelling capability and a useful product is often much larger than it appears.

What’s the difference between AI implementation and AI adoption?

Implementation means the technology is available. Adoption means it has become part of how work actually happens.

A company can purchase a platform, complete the integration, provision every employee, conduct training, and declare the implementation successful while changing almost nothing about the way the organization operates.

Adoption requires more than access. People need to understand when the tool is useful, how it fits their responsibilities, what they remain accountable for, and whether using it will help or threaten them.

That last part is easy to underestimate. Technology changes are also identity changes. Someone who built expertise around performing a task may not immediately celebrate a tool that performs part of it faster. Telling that person to “focus on higher-value work” is not a transition plan. It is an aspiration with several uncomfortable steps missing.

Real adoption becomes visible when behavior changes:

• People bring the technology into consequential work.
• Existing steps are removed rather than duplicated.
• Teams develop shared standards for acceptable output.
• Leaders update expectations and incentives.
• Employees know where judgment still belongs to them.

Implementation installs a capability. Adoption renegotiates the system around it.

Should every company build AI agents?

No. Every company should understand what agents can do, but building one is not automatically a sign of strategic maturity.

An agent is useful when work requires multiple steps, changing context, tool use, and decisions that cannot be captured by a simple deterministic workflow. If the problem can be solved reliably with a form, a rule, a database query, or conventional automation, adding an agent may introduce more uncertainty than value.

“Build an agent” is also not a complete product strategy. An agent needs a job, access to the right context, permission to take specific actions, boundaries around those actions, and a clear way to recover when something goes wrong.

Before building one, ask:

• What outcome would the agent own?
• What decisions is it allowed to make?
• Which systems and information does it need?
• How will its work be evaluated?
• What is the cost of a plausible mistake?
• Who remains accountable for the outcome?
• Is autonomy actually necessary?

The goal is not to maximize the number of decisions made without humans. The goal is to remove unnecessary effort while preserving the judgment, accountability, and relationships that make the work valuable.

Sometimes that calls for an agent. Sometimes it calls for a well-designed button.

Does AI make people better at multitasking?

No. AI doesn’t make human attention parallel. It makes execution parallel.

Human attention still moves largely one task at a time, and every context switch still carries a cost. What AI changes is how much work a focused moment can initiate.

For most of knowledge-work history, a task consumed human attention throughout its execution. Someone had to research the material, inspect every page, draft every variation, or move every item through the workflow. With capable agents, human attention can become concentrated at different points:

• Defining the task
• Supplying context and constraints
• Establishing what “done” means
• Reviewing exceptions
• Approving consequential actions

Between those moments, execution can continue without consuming someone’s continuous attention.

That doesn’t create unlimited capacity. It moves the bottleneck. As execution becomes cheaper and more parallel, judgment, prioritization, review, and organizational coordination become more valuable. Poorly framed agents can produce an enormous amount of work nobody needed—or create a review queue larger than the original task.

The goal, then, isn’t to become better at juggling more things. It’s to focus on one thing long enough to set good work in motion, then move deliberately to the next.

AI doesn’t eliminate the cost of context switching. It changes how much can happen between the switches.

When shouldn’t you use AI?

You shouldn’t use AI when uncertainty adds more risk than value, when the process should be eliminated rather than automated, or when nobody is prepared to own the result.

AI is particularly attractive when a process is slow, expensive, or frustrating. But those symptoms do not automatically make it the right intervention. The process may be slow because it lacks clear decisions. It may be expensive because work is duplicated. It may be frustrating because ownership is fragmented.

Adding AI before understanding that system can conceal the problem without resolving it.

AI is usually the wrong choice when:

• The correct output must be perfectly deterministic.
• A conventional rule or calculation solves the problem reliably.
• The necessary context is unavailable or untrustworthy.
• A mistake would cause unacceptable or irreversible harm.
• Nobody can evaluate the output efficiently.
• The organization cannot explain who is accountable.
• Automation would preserve work that no longer needs to exist.

There is also a human question: would automation remove friction, or would it remove the part of the experience people value?

The discipline is not finding somewhere to use AI. In the current market, opportunities are plentiful. The discipline is recognizing where AI would make the system more complicated, less trustworthy, or less human—and choosing not to use it there.

Should AI eliminate all friction?

No. AI should eliminate friction that consumes effort without producing value—not friction that quietly creates the conditions for good work.

Some friction is plainly waste: copying content between systems, waiting for routine execution, chasing status, or moving information through unnecessary handoffs.

But other friction functions as part of the architecture. A debate can create clarity. A review can create accountability. A pause can improve judgment. Repeated exposure can build trust and shared context.

The danger is that these two kinds of friction often look identical in a workflow diagram. Both appear as extra steps, additional time, or human involvement. Automation can remove them equally efficiently—even when one was producing something the organization had never learned to measure.

Before eliminating friction, ask:

• What does this step produce besides its stated output?
• What becomes easier because this pause, handoff, or conversation exists?
• Who gains context, confidence, or accountability here?
• If we remove the step, does its hidden value need to be recreated somewhere else?

The goal isn’t a frictionless organization. It’s an organization where the remaining friction is intentional.

Does AI eliminate organizational bottlenecks?

Usually, it moves them.

When AI makes execution dramatically faster, the next constraint often becomes review, approval, governance, or access to human judgment. A task that once took eight days may take seventeen minutes to complete, but the resulting work still needs someone to decide whether it is accurate, appropriate, and safe to ship.

That changes the nature of the human role. People spend less time producing every deliverable themselves and more time deciding what to delegate, what context to provide, what evidence to require, and which outputs deserve closer scrutiny.

The goal is not to remove humans from every step. It is to allocate human attention according to risk. Routine, high-confidence work may eventually proceed autonomously. Translation may require a focused checkpoint. A prominent brand or legal decision may still need several stakeholders.

AI doesn’t make constraints disappear. It makes execution cheap enough to reveal where judgment was the real constraint all along.

How do you know if an AI use case is worth pursuing?

A worthwhile AI use case creates measurable value in a real workflow, has acceptable failure modes, and can be owned by someone with the authority to change how the work happens.

The best use cases are not always the flashiest. They are often places where people spend meaningful time interpreting information, navigating ambiguity, transferring context, or recreating work that already exists somewhere else.

I would test a potential use case against seven questions:

1. Is the work frequent or consequential? A small improvement matters when it happens thousands of times—or when one decision carries substantial value.
2. Does the task require interpretation? AI is most useful where rigid rules struggle but informed judgment can still evaluate the result.
3. Is the necessary context available? A model cannot compensate indefinitely for missing, fragmented, or inaccessible information.
4. Can someone evaluate the output efficiently? If checking the work requires recreating it, the apparent productivity gain may be fictional.
5. Is the failure mode acceptable and recoverable? The consequence of being wrong matters more than an abstract error rate.
6. Can the workflow change? If every old step remains in place, AI becomes another layer rather than an improvement.
7. Is there a clear owner and outcome? “Increase AI usage” is not an outcome. Faster decisions, reduced rework, higher throughput, better quality, and shorter wait times might be.

A good use case is not merely technically possible. It is operationally adoptable and economically meaningful.