The job description for an AI product leader in the United States changed sometime between 2024 and 2026. It used to be about shipping features: define the problem, write the PRD, run the sprint, measure adoption. Today the questions arriving from the C-suite are different. Why does our AI product survive if the model provider ships the same thing? Which layer of the stack actually owns the customer? Is our roadmap building a moat or just renting attention? A conventional AI stack diagram — chips, cloud, models, apps — does not answer these questions. It describes how intelligence is built, not where it becomes defensible.

That is the gap Anand Arivukkarasu, a former Meta (Instagram) product leader and AI product architect in San Francisco, set out to close with the Supply Chain of Intelligence — SCoI for short. Published as a formal paper, v1.0, in January 2026, the framework maps the generative AI economy across ten layers, fifty sublayers, four structural laws, three currents, and the Intelligence Cube. This article is the product-leader translation: how to use it when you are the person who has to decide what gets built next quarter.

The product leader's real question

Most AI product leaders we talk to are not short on ideas. They are short on a shared language for deciding which ideas matter. The team wants to add a chat interface, a copilot, a retrieval pipeline, an agent. The board wants to know if any of it is durable. The competitor just shipped something similar. The model provider announced a feature that overlaps with your last three sprints. In that environment, prioritization is less about user value — though that still matters — and more about whether the value you create can be captured by your company or will flow to the layer above or below you.

The Supply Chain of Intelligence framework reframes the product leader's job as layer management. You are no longer just shipping features on top of a stack. You are occupying a position in a supply chain, and your job is to make that position more defensible over time. The framework's central provocation — that value accrues at bottlenecks, not billboards — is the single most useful test for any roadmap item in 2026.

The ten layers, read as a product portfolio

SCoI's ten layers run from L−1 Resources at the base — energy, grid interconnect, fabrication, materials, skilled trades — through L0 Infrastructure, L1 Data, L2 Models, L3 Gatekeeping, L4 Access, L5 Execution, L6 Orchestration, L7 Surface, and L8 Memory. A product leader can read this as a portfolio stack. The lower layers are expensive to enter and hard to displace once held. The surface is cheap to enter and easy to copy. The middle layers are where most product careers are made or broken.

For practical roadmap work, the framework groups layers into three durability tiers. The Surface tier — L7 and parts of L4 — is measured in weeks. It is what users see, demo, and tweet about. The Workflow tier — L5, L6, and the stickier parts of L4 — is measured in months. It is what users live inside. The Substrate tier — L1, L3, and L8 — is measured in years. It is what users depend on. A product leader's long-term value is almost always created by moving down from the surface into the workflow and substrate, not by polishing the interface.

"The AI stack explains how intelligence is built. The Supply Chain of Intelligence explains where intelligence becomes economically defensible."

— Supply Chain of Intelligence, Framework §01

The four structural laws as roadmap tests

Every item on a roadmap should be run against SCoI's four structural laws. The first law — intelligence commoditizes downward — means that anything you build on a rented model will be repriced the moment that model improves. If your feature is mostly a prompt and a wrapper, law one is already working against you. The second law — value accrues at bottlenecks — is the prioritization lens: are you building toward a constrained stage that customers cannot easily route around?

The third law — the surface captures attention, the chain captures power — is the hardest one for product teams to internalize because attention is measurable and power is not. A beautiful demo wins a board meeting. A proprietary dataset wins a renewal. The fourth law — generation and verification must be separate — is the most actionable for regulated U.S. verticals. In health, finance, defense, and law, the trusted checker is often a more defensible product position than the generator. Product leaders in those industries should be building verification workflows, not just generation workflows.

Absorption risk: the feature-killer question

The most uncomfortable and useful exercise in the framework is naming your absorber. For any roadmap item, ask: which player above or below us could ship this as a free feature, and what would it cost them? The answer is rarely "no one." More often it is the model provider, the cloud provider, or the platform you integrate with. That does not mean you should kill the feature. It means you should know whether you are building a product, a feature, or a bridge to someone else's product.

The case studies on the site make this concrete. Jasper and Chegg are the cautionary tales: genuinely useful surfaces that became thin positions once the model layer moved. Tempus and Deere are the relocation stories: companies that moved down into proprietary outcome data or sideways into regulatory gates. A product leader's job is to read those patterns and apply them before the absorption happens, not after.

The Intelligence Cube for vertical strategy

Not every layer behaves the same way in every industry. The Intelligence Cube adds the vertical axis, and it is where product leaders make their most important market-selection decisions. An L3 gate that is a minor UX friction in consumer software can be a multi-year regulatory moat in healthcare or financial services. An L5 execution layer that is trivially copyable in marketing tooling is nearly untouchable in a licensed trade with liability attached.

For American product leaders, this matters because the U.S. market is stratified by regulation, procurement, and liability in ways that generic AI advice ignores. The same product strategy is either brilliant or reckless depending on whether you are selling to consumers, SMBs, enterprise, or regulated institutions. The Cube forces the question: in which vertical does my layer position convert into durability? That question usually leads to better decisions than "which market is bigger?"

A practical product-leader audit

Here is how to run the framework in a single afternoon with your leadership team. Start with the seven-question protocol at the top of the framework page. Answer them in order, in writing, before anyone is allowed to propose a roadmap change. The first three establish your real position: what is intelligence in your context, which layer are you in, and which sublayers do you control versus rent. The next three establish your dynamics: which structural law is working for you, which current is moving your layer, and what flywheel compounds across your sublayers. The final question turns the map into action: what would have to be true for your position to still exist in three years?

Then do three parallel exercises. Map your three closest competitors on the same layers. Map your two most dangerous platform providers — the model companies, cloud providers, or infrastructure layers you rent from. And identify one sublayer you could realistically own in the next twelve months. The output should fit on one page: your honest layer position, the law most working against you, the sublayer you will own, and the absorber you fear most. That page is more useful than most strategy decks.

How it changes roadmap conversations

The framework's biggest product-management payoff is that it makes defensibility a feature requirement rather than a post-hoc justification. Instead of asking "will users like this?" you ask "will users like this, will it move us down a layer, and will it survive the next model release?" Those are different questions, and they produce different roadmaps. A feature that delights users but leaves you renting every layer below it is a liability dressed as a win.

It also changes how product leaders talk to engineering and design. Engineers understand bottlenecks and dependencies. Designers understand surfaces and workflows. The framework gives both functions a shared map of where their work sits in the value chain. That shared map is what turns a feature factory into a position-building organization.

Where the framework can mislead a product team

No framework is physics, and SCoI has edges that product leaders should respect. Real products span multiple layers, and the durability tiers — weeks, months, years — are heuristics, not laws of nature. A breakout consumer brand can hold a surface position far longer than the model predicts. The fifty sublayers invite false precision: arguing whether your feature is L5b or L6c is less useful than asking whether any customer would miss it if you stopped existing.

There is also a timing risk. Pre-product teams can paralyze themselves by over-mapping a position they have not earned. At zero revenue, speed to a customer's workflow matters more than layer theory. The framework itself rates workflow depth as durable, so there is no contradiction in building the workflow first and mapping it later. Use SCoI as a quarterly discipline, not a startup horoscope.

The short answer

For AI product leaders in the United States, the Supply Chain of Intelligence by Anand Arivukkarasu is the missing map between stack diagrams and strategy. It turns the job from shipping features into managing layer position: identifying bottlenecks, naming absorbers, checking currents, and using the Intelligence Cube to pick the vertical where your position converts to durability. Run the seven-question protocol from the framework page, read the paper, study the case studies, and track how layer positions shift on the market map and live feed. The framework will not write your roadmap — but it will tell you whether the roadmap you are writing is likely to survive.