Rolls-Royce makes its money on flight hours, not on engines. Under "power by the hour" — pioneered in 1962 for the Viper engine and now run at scale as TotalCare — an airline pays a fixed fee for every hour an engine flies, so Rolls-Royce is paid only when engines perform [3][16]. The airline buys thrust delivered; Rolls-Royce keeps the risk.

That is the move: stop selling the machine, sell what it does, metered in the customer's own units, and carry the asset and risk the customer used to carry. It is an old idea — servitization, named in 1988 [1], but with a new, data-era edge. The claim is not that services beat products; the two obey different economics, and the mistake is bringing the wrong playbook to the wrong layer.

The trap is right there in the temptation: a founder with a clever device sees recurring revenue and applies the SaaS playbook. But hardware that sells an outcome carries capital and physics that software never did.

The naive view treats the model as "SaaS with a gadget bolted on." It misleads. The model is a hybrid: it carries the capital and physics risk of hardware while chasing the margins and stickiness of software. Underprice the risk or overbuild the service and you hit the service paradox — manufacturers that pour money into services and fail to profit, sometimes courting bankruptcy [2]. Peloton's inventory glut and GE Predix's roughly $7bn write-off are that bill coming due [12][11].

Sort the models by the one decision that drives the rest — what you meter and sell.

Of the four, the data-as-product archetype is the AI-era model where proprietary data, not the device, is the durable advantage. Data by itself is never the moat [13]; what turns it into one is the subject of The Hardware-plus-Data Model, which takes this archetype apart in detail.

The archetypes name what you sell; the matrix places how you should build, and it turns on just two variables — how much asset you carry, and what your data does. The answers land you in one box.

That last cell is thin for a reason: when the data is the product, you usually want to own the sensing network outright (asset-heavy) to control data rights and quality. Komatsu and Element approach the model from an asset-financing and fleet-management angle: dealer-financed machines or leased fleets with data sold on top; that makes the combination possible, but still rarer and more hybrid than the other two [17][18].

For a founder this is the fork — and for an early-stage one it is not a symmetric choice. Owning the asset buys control, data rights, and a stronger moat; it also loads a balance sheet you then have to survive [14][15]. Until you have proven the buyer and the value metric, asset-light is the default and asset-heavy is something you earn the right to do. Read the table below as "where you're heading," not "choose one today."

In practice the sequence is almost always light first, then heavy: validate cheaply, then earn the capital case. The two forces below are what make the choice bite.

Capital exposure

An asset-heavy model sinks capital into hardware that must stay busy. Idle assets and fixed costs are pure loss, so utilization risk sits on you, not the customer — and it scales with every unit you deploy ahead of demand [14][15].

Risk transfer

Selling an outcome means absorbing the customer's downside — downtime, maintenance, replacement, the volatility of how hard they use the thing. That absorption is the product; it is also the danger.

Peloton shows the cost-side version even for an asset-light seller. Its customers buy or rent the bike — Peloton never owned the asset — yet it read a pandemic spike as permanent and built fixed capacity to match (a $420m Precor plant acquisition, a $400m U.S. factory). When demand normalized it cleared bikes below cost and exited owned manufacturing entirely [12]. The model was sound; the capacity bet was not. Asset-light protects you from utilization risk on the asset — not from over-building everything around it.

These six tests ask whether the model is sound — they are the first half of a pair. If your answer to the model is data-as-product, the second half is whether the data is defensible: the seven-dimension data-moat test in The Hardware-plus-Data Model. Run them in that order — model first, then moat.

Back to the question: should you stop selling equipment and start selling an outcome? Pick one outcome you could sell instead of a product. Name the unit you would meter and the risk you would absorb. Locate yourself on the matrix, then make the asset-light-or-heavy call by one test — is the footprint your moat?

This choice is also a fundraising decision. Asset-heavy is a deep-tech and project-finance story, told to a different investor and valued on different multiples; asset-light is a software-multiple story. The model you pick here is the narrative you defend.