Working Theories
I’ve spent years working in MarTech—always customer-facing, but at the intersection of customers, engineering, marketing, and product. Then AI arrived, and the conversations changed.
At first, they centered on how to use AI everywhere. Then, after organizations burned through annual token budgets in a matter of months, the conversation shifted toward where AI actually created value. Now, as models, agents, and platforms proliferate, it’s increasingly become a question of which AI.
Those are all worthwhile conversations. But I think they’re downstream of the questions that will ultimately determine whether AI becomes a competitive advantage or another expensive technology cycle.
Over the past few years, I’ve found myself returning to the same handful of ideas—about workflows, ownership, incentives, trust, organizational change, and the systems that surround the technology itself. This page collects those ideas. They’re not immutable truths or universal answers. They’re my current Working Theories on building AI into real organizations.
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.
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.
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:
- Is the work frequent or consequential? A small improvement matters when it happens thousands of times—or when one decision carries substantial value.
- Does the task require interpretation? AI is most useful where rigid rules struggle but informed judgment can still evaluate the result.
- Is the necessary context available? A model cannot compensate indefinitely for missing, fragmented, or inaccessible information.
- Can someone evaluate the output efficiently? If checking the work requires recreating it, the apparent productivity gain may be fictional.
- Is the failure mode acceptable and recoverable? The consequence of being wrong matters more than an abstract error rate.
- Can the workflow change? If every old step remains in place, AI becomes another layer rather than an improvement.
- 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.
Map the work before selecting the technology.
Before selecting a platform or launching a pilot, choose one workflow and map what actually happens today:
- Where does work wait?
- Where is context lost?
- Which decisions require judgment?
- What gets recreated?
- What do people routinely work around?
- Who owns the outcome?
- What could disappear if the new approach worked?
That exercise will tell you more about your AI opportunity than a list of available models ever will.
The technology matters. But the organization around it determines whether that technology becomes a useful capability, an expensive demo, or one more abandoned tab in someone’s browser.