NFX published a piece this month on how the fastest AI-first companies really work. (link) Read the whole thing. The mission pod framework is right: organize around outcomes, not functions; put agents on the org chart; build eval culture; ship and learn fast. The five rules and five traps are worth internalizing.
Most services firms are starting from a very different condition — hundreds of people, a decade of functional structure, clients who depend on continuity, and revenue that depends on keeping today’s machine running.
So the question isn’t whether mission pods work. They do. The question is what has to exist inside an established services firm for mission pods to actually work — and to get better over time.
The answer is a function most services firms don’t have. I call it Delivery Design & Product. Its job is to continuously design and productize how the company delivers its services — bringing together strategy, operations, product management, and AI to turn emerging capabilities into a better delivery model the organization can actually build, deploy, measure, and improve.
Everything else follows from that. And everything else depends on it.
The Function That’s Missing
Most services firms have something called Product. But that function typically owns what the company sells — how services are packaged, priced, and taken to market. That’s important work.
But AI creates a second question that increasingly needs an owner: how should we actually deliver that service?
In a technology company, Product and Engineering work in tandem, continuously redesigning the product as customer needs and technology change. That redesign is somebody’s job. Services firms need the same capability, applied to the delivery model.
Client Services owns the relationship. Delivery owns execution. Technology owns the platforms. Finance owns the economics. But who owns this: how should we deliver this service two years from now, when AI is capable of doing things it can’t do today?
Usually, nobody.
That’s not a technology gap. It’s an organizational gap. And it explains why so many AI transformations inside services firms produce impressive pilots but limited structural change. The technology works. The use case works. The business case works. Then the organization goes back to doing what it was already doing.
Delivery Design & Product owns the progression from idea to delivery capability: envisioning the future, developing the business case, defining the future-state operating model, translating that into a roadmap and specifications, and partnering with Technology and Delivery to build, deploy, measure, and continuously improve.
Traditional Product owns what the client buys. Delivery Design & Product owns how the company designs, produces, and delivers it. The delivery model itself now needs continuous product management.
Here’s what has to be true before that function can do its job — and before mission pods have anywhere to land.
First: Build the Memory Layer
NFX is right about eval culture: volume without judgment degrades your product, and customers notice before you do. In a product company, the signal is fast — slop degrades the user experience and users churn.
In a services firm, the signal arrives later and does more damage. Clients don’t churn immediately — they drift. They go quiet on renewals. They stop including you in strategic conversations. They start evaluating alternatives months before they tell you.
Eval culture in a services context has to extend beyond output quality to relationship and delivery quality — what was promised, what was delivered, what the client said last quarter versus this quarter, what changed in between.
You can’t evaluate what you haven’t captured. And in most services firms, the most important signals — relationship health, client sentiment, delivery history, context shifts — live in the heads of the people closest to the account. That’s not organizational memory. That’s organizational dependency.
An agent can’t learn from what the organization hasn’t retained. A pod can’t improve systematically if every engagement starts from scratch. Organizational memory becomes part of the delivery infrastructure — and eventually part of the competitive advantage.
Build it first. Eval culture has nothing to work with until you do.
Second: Understand the Work at the Process Level
Before you can capture the right things systematically, you have to understand what you’re capturing. That means decomposing delivery workflows into discrete units — which tasks are repeatable, which are genuinely variable, and where the handoff between human and agent belongs.
I call this process tokenization.
Take a typical consulting engagement. “Deliver the strategy” sounds bespoke. But underneath it are dozens of distinct units: gathering data, researching competitors, synthesizing interviews, developing hypotheses, building models, drafting slides, pressure-testing recommendations. Some are highly repeatable. Others depend on judgment and context. The strategy may be bespoke. The process that produces it is not entirely bespoke.
Most services firms haven’t made that distinction. They’ve answered the human-versus-agent question at the tool level — “we use Claude for summarization, AI for first drafts” — rather than at the process level. That’s individual productivity with a shared license. It’s not organizational design.
The obstacle is predictable: the bespokeness objection. Everything feels custom. Every client is different. But beneath the bespoke surface of most services delivery is a repeatable core. AI handles that core. The human uses AI tools to manage the variability layer — the client-specific context, the relationship nuance, the judgment calls that genuinely can’t be systematized.
The objective isn’t to eliminate variability. It’s to stop confusing variability with the entire process.
Third: Create Dedicated Build Capacity
Once you can see the work, someone has to change it.
This is where services firms run into a structural problem: everyone is already busy delivering the current business. Everyone is billable. Delivery teams are measured on utilization. Technology teams are measured on uptime. There is no slack — by design, because slack doesn’t show up on the P&L as revenue.
Nobody’s job is to build the AI-enabled future of how services get delivered. To map the workflows. To tokenize the processes. To systematize what works. To take what works in one engagement and turn it into a repeatable capability across the firm.
NFX warns against mistaking underbuilt for lean. In a services firm this trap is structural, not accidental. You can’t do this work in the margins of a fully utilized organization. You need dedicated build capacity — people whose job is building, not delivering.
That is a real cost with no immediate billable return. And it’s the investment most services firms delay until margin pressure makes it unavoidable. By then, the firms that created the capacity earlier are already compounding.
Delivery Design & Product owns that capacity — not because it builds everything itself, but because someone has to own what gets built, why, and whether it actually changes the economics of delivery.
Fourth: Own the Whole Delivery Product
With memory, process understanding, and build capacity in place, Delivery Design & Product can do its actual job: owning the full progression from strategy to delivery capability.
Without it, the work fragments. Strategy defines the opportunity. Operations documents the current process. The AI team builds an agent. Engineering builds the platform. And yet nobody owns the question: did we actually create a better way to deliver the service?
That’s the accountability gap. The technical layer has a sponsor. The process layer has a sponsor. The people layer has a sponsor. But the delivery product has no owner.
Delivery Design & Product closes that gap — not as a temporary program, but as a permanent function. As AI capabilities change, the delivery model changes. As the delivery model changes, the organization builds better capabilities. That’s the compounding effect mission pods can’t produce without it.
Then Mission Pods Have Somewhere to Land
Now NFX’s model makes sense.
A pod needs organizational memory to learn from. It needs a decomposed process to know where humans and agents operate. It needs build capacity to change what isn’t working. And it needs someone accountable for the outcome.
Without those things, a mission pod risks becoming another cross-functional team with a better name. With them, the pod can evaluate its own work, capture what works, move tasks between humans and agents, and improve the economics of delivery over time. What the pod learns feeds back into the delivery model. The next pod starts from a better place.
Mission pods are the operating model. Delivery Design & Product is the function that continuously evolves what those pods operate within.
The Transition Is the Hard Part
The destination is relatively clear. The transition isn’t.
An existing services firm has to keep today’s business running while simultaneously building the system that will replace parts of how today’s business runs. The people accountable for today’s revenue are rarely accountable for tomorrow’s delivery model. The people who understand the process are often fully occupied delivering it. The people with the technical skills to redesign it may not understand the service deeply enough.
That’s why AI transformation stalls. The pilot works. The steering committee approves. And then nothing fundamental changes — because the transition has no owner.
Delivery Design & Product exists to own that transition permanently. Build that function first. Then the pods have somewhere to land.
Who in your organization owns the redesign of how services get delivered — not the packaging, not the platforms, not the client relationship — but the future of delivery itself?
I write about operationalizing AI in services businesses. If this resonates, I’d like to hear what you’re building — or struggling to build.