A primitive is a unit of technological capability. A product is a unit of value. They are not the same, and the gap between them is where most products fail.
I learned this on Amazon's multimedia systems. We had engines that generated virtual worlds, millions of photoreal 3D models, image generation at millions of images for cents. None of it was a product. Creators and brands didn't want science experiments. They wanted tools that finished a job - design, edit, and publish at scale without needing weeks, a PhD, or a Hollywood budget. The work was the translation: turning capability into value.
Why the gap matters more now.
In any prior platform shift, primitives were expensive enough that building one was the work. A new database engine, a mobile SDK, a cloud API - possessing it was an advantage. Translation into a product mattered, but the queue for primitives was long, and most teams were fighting the backlog.
AI has flattened that queue. The cost of building has fallen by orders of magnitude; the cost of building the wrong thing has risen by the same. When primitives are abundant and cheap, the primary constraint left is judgment. AI slop is what happens when teams skip it.
This is not only my experience. In March 2026, Anthropic published a study of AI's labour-market impact comparing two things for every occupation: tasks a model could theoretically do, and tasks actually being done with AI. Blue is the first. Red is the second.

The blue is capability. The red is capability translated into use. In computer and mathematical work, the most exposed category, models could touch 94% of tasks; real coverage sits near a third.
Anthropic reads this as evidence that AI has not yet displaced work at scale. Read another way, it is a map of untranslated capability. Some of the gap will not close, tasks beyond a model's reach, others held back by law or trust. The rest is untranslated: the capability exists, and no one has turned it into something someone in that job can reliably use.
The primitives.
The vocabulary is standard enough now that most readers will know it. Anthropic's material and the OpenAI cookbook go deeper than I can; the taxonomy I've drawn below names the ones that matter.

The point worth making is structural. These are atoms; a product is a molecule. A prompt is not a product. A model is not a product. A tool, a skill, an agent, none of these is a product. They are the units capability comes in. The work of this essay is not the atoms.
The translation.
Translating a primitive into a product has five moves. They are not stages to complete, but questions the PM has to keep open for the life of the product. With primitives mutating faster than they used to, translation is not a one-time act. It is the continuous work of holding a moving primitive against a moving workflow and keeping the product still.
The first is inventory. Understanding the full potential of the primitive, what it does, how it fails, what it costs at scale, the workflows it composes into. An agent that handles each step with 95% reliability finishes a five-step task about 77% of the time and a ten-step task about 60%; errors compound. Same agent, different primitive depending on the workflow you put it inside.
The second is anchoring. A primitive does not become a product until it is attached to a journey someone is already trying to complete. The brand manager doesn't want a generative model. She wants a product photograph with the specified lighting and white background her catalogue update needs, in the four hours it allows.
The third is composition. Most outcomes need more than one primitive. The single AI image a creator publishes is the output of a chain: a template feeds a generation model, an edit pass feeds an editing model, photorealism grounding ensures it's shippable. The product is the composition with primitives as inputs.
The fourth is control. This is where translation becomes craft. Power without a control surface overwhelms; after the first failed attempt, the user will not return. The right controls don’t constrain capability, they translate it into the user’s needs - the editing layers, the templates, the single button that compresses a workflow into one click. Control builds trust and a reason enough to return.
The fifth is the boundary. The deterministic-probabilistic line is the most consequential translation decision in the product. Which steps of the workflow do we let the model decide, and which do we lock down? Customers tolerate variance in the suggestion. They do not tolerate it in the checkout, the price, or their privacy.
What endures.
One of the most useful things I learned about primitives, I learned from one that could not be translated. An engineer on my team built, with skill, a renderer that could place an effectively infinite number of light sources in a single scene, millions of them, where most engines stop in the low thousands. No creator wanted a million lights; they wanted four, well placed, with presets and a way to move them. The capability was real. No workflow, then or now, could turn it into something a customer would reach for.
Some principles hold across cycles. The same gap existed when SQL became a primitive, when the browser did, when the mobile SDK did. The primitives change every cycle. The translator stays the same, standing between the customer and technology, refusing to mistake one for the other.
Shape for understanding, not exposure. A primitive feels infinite because it is, and infinity is not a place anyone can start work. Sometimes it's the whole capability collapsed into one obvious move: "remove background," one button. Sometimes it's invisible. ChatGPT and Claude are not blank text boxes over a model. Behind the cursor sit a system prompt, a tuned model, suggested openings, and tools that fire on their own. The product gives that infinity a starting point.
Context turns power into product. A primitive inside a problem someone already has turns technology into value. Finding that frame is translation, and it runs both ways: the customer knows the problem but not the capability, the engineer knows the capability but not the problem. Neither speaks the other's language.
Simple surface, layered complexity. The best products hide depth until it's needed. For users, that means a clean interface revealing the primitive gradually. For architecture, it means modular layers so the depth can grow, and change, without disturbing the surface.
Where translation becomes the artefact.
With AI, the harness holds the translation. The eval is how you know the translation works. The boundary is the translation’s most consequential line.
This is why the moat in AI is moving where it is. As foundation models commoditise, every product team has access to roughly the same primitives. Cursor and a hundred forgettable IDE plug-ins are all built on the same handful of frontier models; what separates them is the thinking behind the product, and the harness: prompts, tools, retrieval, controls, evals. The team that translates builds a better product from the same primitives. When the translation is right, the technology disappears into the background of what someone is making or doing.
The primitives are abundant and getting cheaper. The translation is not.
Next: XX
From Primitive to Product
AI Product Management | A primitive is capability; a product is value. With AI, capability is cheap. Translation is the PM's edge.