The productization loop

This is the mechanism that separates a lasting advantage over competitors from a cost centre. Everything else about the model depends on whether this loop runs.

What the loop is

At a fixed interval, somebody with authority asks one question: of everything we built for customers this period, what generalises?

Then they decide what gets moved into the platform, who does that work, and when. And they apply a stop rule to whatever does not generalise.

That is the whole mechanism. It sounds trivial and almost nobody runs it, because it requires taking engineers off customer work in the same period the customer work is visibly urgent.

Why it decides everything

The economic case for embedding engineers is that the margin you spend buys learning that improves the product for every future customer. The engineer costs real money now and the platform gets better, so the next deployment is cheaper.

Take out the second half and you have paid the cost without the mechanism. a16z's Marc Andrusko describes the outcome as thousands of bespoke deployments impossible to maintain or upgrade: revenue grows, no reusable work builds up, and there is no lasting advantage.

The industry shorthand for the intended pattern is a rough custom solution first and a standard, reusable version second. The rough version proves the problem is real and the reusable version makes the next one cheap. Skipping the second step is how a software company becomes a labour business without noticing.

This is also the mechanism behind why forward deployed engineering is growing as a category rather than staying a Palantir-specific practice. AI labs and infrastructure vendors are embedding engineers because generation makes the rough custom solution fast to build. The loop is what decides whether that speed compounds into a lasting advantage or just produces more bespoke code faster than before. Fast generation without a loop is not a shortcut, it is the same failure mode arriving sooner.

The three requirements

A schedule. Weekly or fortnightly, on the calendar, with the same question each time. Not "when we have time", because there will not be any. A regular meeting whose only agenda item is what generalises.

A named owner with authority. Somebody who can say a capability is going into the platform and assign the work. If the answer to who decides is a committee, it is nobody. This is also why the reporting line matters: an owner inside a services unit with its own margin target has an incentive against moving work into the platform, because a platform capability is revenue they no longer bill.

A stop rule. First Round Review states it well: embrace scope expansion when it creates repeatable software value, and stop when further work only helps a single customer. Somebody has to apply that weekly, out loud, and decline work.

What the loop should produce

Not a document. Working infrastructure that the next deployment starts from.

The AWS partner programme names the modern version of these artefacts directly: reusable delivery harnesses including domain ontologies, evaluation frameworks and capability registries.

Translated into things you can build:

Domain models. The structures that recur across customers in your market, so each deployment does not re-model the same concepts.

Evaluation frameworks. The checks that prove a deployment works, reusable across customers. On an AI-native engagement this is the most valuable artefact, because it is also the handover deliverable that lets a customer's team own the system. Eval-driven development covers the method.

Connectors and integrations. Written once for the systems that keep appearing.

A capability registry. A list of what already exists, so an engineer starting a deployment can find it. Without this, capabilities get rebuilt because nobody knew they were there.

How to run the meeting

Short, and structured around evidence rather than opinion.

Each embedded engineer brings what they built and one sentence on whether they expect to build it again. The owner asks whether any other customer has asked for something similar. Anything with two or more requests goes into the queue of work to move into the platform. Anything with one gets a note in the registry and stays custom.

The two-request threshold is arbitrary and useful. It stops the loop from generalising prematurely, which is its own failure: a capability built for a pattern that turns out not to exist is worse than the custom code, because now it is in the platform and everyone maintains it.

Keep a written record of the meeting's decisions, not just its attendance. A one-line log entry for every item discussed, whether it moved into the platform, stayed custom, or is waiting on a second request, is what turns the meeting into an audit trail rather than a conversation nobody can reconstruct. Months later, when someone asks why a particular capability exists or why a particular customer request was declined, the log answers it in seconds. Without the log, the answer is whoever remembers the meeting, and people leave.

Who should be in the room

The owner and every embedded engineer who shipped something that period, at minimum. Two more people are worth adding even though they slow the meeting down.

Someone from the team that will maintain whatever gets generalised. An embedded engineer proposing a capability move is not the person who will support it later, and the person who will support it should have a say in whether it is built the way the engineer under deadline pressure would build it.

Someone who can see the pipeline of accounts not yet signed. A pattern that has appeared once in delivered work and is already showing up in active sales conversations is a stronger signal than the two-request threshold alone captures, and only someone with visibility into the pipeline can supply that context.

What to measure

Revenue per embedded engineer, over time. The output measure. If the loop is running, this rises: the platform takes in what engineers learned at customer sites, so each engineer handles more accounts. Flat revenue per engineer with custom work accumulating means the loop is not running. That page covers it.

Share of shared versus custom code per deployment. Should trend toward shared. If the custom share grows with each new account, the loop is failing.

Time from signature to production, over successive deployments. Should fall. This is the number a customer feels, and the clearest evidence the loop produces value rather than internal tidiness.

The failure modes

Nobody owns it. The most common. The schedule exists and produces a list nobody acts on.

The owner has no authority. They can recommend and not assign, so the queue grows.

Generalising too early. One customer's request becomes a platform capability, and it turns out no other customer wanted it. Now it is a maintenance burden with a config flag.

Generalising too late. Four accounts have four versions of the same thing before anybody notices. This is the expensive one, and the registry is what prevents it.

The loop competes with revenue and always loses. If platform work is only done when no customer needs anything, it will never be done. It has to be funded as a budget line rather than done in spare time.

The stop rule gets applied unevenly. A senior engineer with credibility can decline a customer request that only serves one account and be believed. A newer engineer on the same team, given the same instruction, often cannot, because the customer pushes back and there is nobody senior in the room to back the decision. If the stop rule only works when a specific person applies it, it is not a rule yet, it is that person's judgment, and it needs to become policy the whole team can point to before it is reliable.

Where this fits for us

We run this as part of how we work rather than as a separate function, and the artefact that matters most is the eval suite. Because the specification is written to the level our tooling generates from, the checks derived from it are reusable across engagements in the same domain, and they are also what your team inherits at handover. The reusable asset and the handover deliverable are the same object, which is the neatest version of this loop we have found.

The two-request threshold still applies here, and the meeting still happens on a fixed schedule with a named owner, because the eval suite being reusable does not exempt the rest of the work from the same discipline.

Next: how to price it, or measuring the function.