AI Isn't a Product Implementation

We've been implementing software in organizations for thirty years. We know how to do it.

The scope is defined before you start. The deliverables are documented. The expected outcomes are measurable. A project manager runs the work. A change lead aligns the people. Someone senior makes sure it connects to the rest of the organization. When a rollout lands badly, we know why, and most of the time, we can fix it.

AI transformation isn't failing because the discipline doesn't exist. It's failing because most organizations are applying the wrong discipline to it.

The illusion of product implementation

The first instinct most organizations have with AI is to treat it as a product. Buy the tool. Run the pilot. Scope the rollout. Measure adoption. Call it done. This is exactly how we've implemented CRM, ERP, and most other systems for a generation, and it has worked well enough for single-product decisions.

It doesn't work for AI because AI isn't arriving as one product. It's arriving as dozens of small projects at once, coming from different vendors, initiated by different teams, operating at different levels of sophistication. A copilot in the CRM. A generative tool for proposal writing. An agent for customer triage. A forecasting model in finance. A retrieval layer in customer success. Each one looks like a small product implementation on its own. In aggregate, it's portfolio chaos.

The product-implementation playbook scales linearly. One project at a time, with dedicated oversight and change support. You cannot run twenty product-implementation playbooks simultaneously and stay coordinated. The discipline was never designed for that volume.

Shadow IT at a hundred times the surface area

Ten years ago, we had a name for what happens when departments buy their own tools without coordination. We called it shadow IT, and we built practices to manage it: portfolio reviews, capability standards, shared roadmaps, coordination between central and distributed teams.

A department buys their own scheduling solution. They do it because the central system is slow, or because they have a budget and a problem. It solves their immediate need. Then we discover it doesn't integrate with the master calendar, creates security gaps, duplicates work somewhere else, and the maintenance cost never landed in any roadmap. The organization pays for the lack of coordination in ways that never appear on the tool's invoice.

AI adoption in most organizations today looks exactly like this, except at a much higher cadence. Marketing adopts a writing tool. Support adopts a summarization layer. Sales adopts a prospecting agent. None of it is coordinated. Some of it overlaps. Some of it contradicts. Some of it solves a problem that was already being solved, just differently, and now there are two sources of truth where there should be one.

This isn't new territory. It's an old problem with more surface area.

The discipline that actually fits

What AI needs isn't a new AI framework. It's three operator practices most organizations already know how to do, applied at the velocity AI is arriving at.

Portfolio coordination. Someone senior looks at the full set of AI initiatives, not just each one in isolation. Where are we duplicating? Where are we underinvested? What does this specific initiative do to the systems around it? These are questions AI programs consistently fail to ask, because each initiative looks small enough to approve on its own.

Change management. The human roles surrounding each AI capability are redesigned intentionally. Most AI rollouts skip this because it's the politically expensive part. The result is that the productivity case never lands. Humans do the same work they did before, plus supervising the AI.

Capability stewardship. A clear view of what AI can actually do at your organization's sophistication, not what the vendor claims. This is the practice that prevents operating models from being designed around capabilities that don't yet exist at the scale required.

None of these are new. All of them are how disciplined operators already manage complex software portfolios. The only difference is that AI is arriving faster than most organizations are keeping up with, and the gap is widening.

What actually works

The organizations that are quietly pulling ahead treat AI as a portfolio decision, not a product decision. Someone senior owns the portfolio view. Initiatives get proposed, evaluated, and coordinated before they sprawl, not after. Overlapping capabilities get rationalized early rather than discovered at the wrong moment.

They treat change management as a peer function to AI capability building, not as a downstream activity. When a new capability deploys, the human roles around it are already redesigned. The productivity case lands because the work that was displaced actually stops.

They treat vendor claims as hypotheses, not specifications. They pilot at realistic scale before committing operating models to a claimed capability. If the capability doesn't land at production scale, the operating model holds without collapsing.

These practices aren't AI-specific. They're how disciplined operators have always managed complex change. AI is the stress test for whether the discipline was there in the first place.