Teardowns

Physical AI Product Teardowns

A case study tells you what a vendor says happened. A teardown shows you a product you can go and look at, and names the decision that produced what you see. These are three, from product families where the decisions are visible in the behaviour.

How these are written

Each teardown starts from something observable without insider knowledge — how the product behaves, what its specification says, which standard it implements. From there it names the product decision that best explains the observation, what that decision cost or protected, and the rule that transfers. Where the analysis carries first-hand standing, that is stated. Where it is public observation, that is stated too. Nothing here discloses an internal decision, rationale or figure from any employer.

Three teardowns

Public EV charging — the reliability decision

What is observable: Anyone who has used public charging has met a charger that authenticated, then failed; or a bay reported available that was not. Reliability varies more between networks than between hardware vendors, and the same hardware performs differently on different networks.
The decision behind it: Reliability in charging is not an operations outcome, it is a product architecture decision made before the first unit ships: what the charger does when the backend is unreachable, whether a session can start offline, what is diagnosable remotely versus needing a van, and how a payment or authentication failure degrades. The same physical unit in two networks behaves differently because those decisions were made differently.
What it cost: Networks that deferred the degraded-mode decision inherited a field-service cost that scales with the fleet — the one cost shape that cannot be optimised away later, because it is a property of the architecture rather than the operation.
The rule that transfers: In connected hardware, the availability number is set at design time. Ask what the unit does with no backend before asking what the uptime target is.
Standing: This teardown uses publicly observable network behaviour and published specifications only; it contains no confidential employer information.

Android Automotive in a production vehicle

What is observable: Infotainment in recent vehicles increasingly runs a full general-purpose OS with an app store, not an embedded HMI. Renault OpenR Link was the first complete Android Automotive integration to ship.
The decision behind it: Putting a general-purpose OS inside a homologated vehicle forces a decision most software teams never face: two clocks. Apps expect a weekly release cadence; a vehicle expects type approval, regional homologation and a support life measured in years. You either sandbox the fast layer hard enough that it cannot touch the certified one, or you inherit the vehicle's cadence for everything — and the second choice makes the app store pointless.
What it cost: The sandbox decision determines whether the platform can accept third-party software at all. It is made once, early, and everything downstream — signals exposed to apps, update channels, what a bad app can degrade — follows from it.
The rule that transfers: When a fast-moving layer meets a certified one, the interface between them is the product decision. Draw it before either team starts, or the certified side sets the pace for both.
Standing: former-employer connected-services product leadership across multinational vehicle programmes. Written from publicly documented platform behaviour.

Video platforms at fleet scale

What is observable: Set-top boxes and video platforms update in waves, not all at once, and carry telemetry far beyond what a feature needs. Users notice neither — which is the point.
The decision behind it: Past a certain fleet size, you cannot recall a device and you cannot ask a person to look at one. Staged rollout and remote diagnosability stop being process and become architecture: if the update mechanism cannot halt mid-wave, or a fault cannot be diagnosed without a visit, no amount of QA compensates. That decision has to precede the first deployment, because it constrains how the software is built.
What it cost: Platforms that treated rollout as a release process rather than a product capability discovered the gap during their first bad update — the moment when the cost of not having it is highest and the option to add it is gone.
The rule that transfers: Ask what full deployment costs per unit for every recurring operation. Anything that scales linearly with fleet size is a launch blocker, not an optimisation.
Standing: former-employer product experience on globally deployed video platforms. Analysis of publicly observable update and telemetry behaviour.

What these are not

These are not client case studies — Hyperion publishes none, because it has none to publish. They are not audits of the companies named, and they do not claim the decisions described are the ones those teams actually debated; they are the decisions that best explain what is observable. Nothing here discloses confidential product, contract or roadmap detail from any employer. Where a teardown draws on first-hand standing, the analysis is the contribution; the internals are not disclosed and will not be.

The same reading, on your product

A Product Decision Review applies this to your own programme and returns a written decision memo rather than an assessment score.

Discuss your product decision