The productization loop

This is the mechanism that separates a moat from a cost centre. Everything else about the model is downstream of 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 promoted 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 scales, nothing compounds, and there is no durable advantage.

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

The three requirements

A cadence. Weekly or fortnightly, on the calendar, with the same question each time. Not "when we have bandwidth", because there will not be any. A standing 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 promoting work, 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 halt when iterations cap at single-customer utility. 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 shapes 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 highest-leverage 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 promotion queue. 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.

What to measure

Revenue per embedded engineer, over time. The output measure. If the loop is running, this rises: the platform absorbs what the field learned, so each engineer covers more ground. 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 losing.

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 cadence 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 promotion work is only done when no customer needs anything, it will never be done. It has to be funded as a line rather than as slack.

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.

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