The Unique Nature of Product Management in Embodied Intelligence
Published:
Originally published on Substack.
While pure software PM roles are increasingly being squeezed by AI, the situation in embodied intelligence is almost the complete opposite.
Embodied intelligence isn’t simply about “plugging a large model into hardware.” It’s a systems engineering challenge that spans the physical and digital worlds.
In this field, the role of the PM isn’t diminishing—it’s being forced to evolve.
1. Mistakes Here Can’t Be Fixed with “the Next Version”
In the software world, a mistaken requirement usually means, at worst:
Writing a few extra lines of code
Rolling back a version
Redoing an A/B test
But in an embodied intelligence system:
Hardware orders have already been placed
Mechanical designs are finalized
Supply chains are locked in
On-site deployment has already happened
A single wrong product assumption can cost six months and millions of dollars.
The primary responsibility of an embodied intelligence PM isn’t to drive delivery—it’s to prevent mistakes from being scaled up.
I felt this deeply when delivering production lines for BMW, Audi, and Tesla at Frimo: once the mechanical design is locked in and suppliers are committed, changing requirements costs months and millions.
This isn’t a matter of dragging a ticket in Jira.
2. You’re Not Managing Requirements—You’re Managing Irreversible System Couplings
Embodied intelligence PMs don’t face a list of features; they face tightly coupled system constraints:
Sensor accuracy ↔ Control algorithm complexity
Real-time requirements ↔ Model size
Power consumption ↔ Compute power ↔ Heat dissipation ↔ Cost
Mechanical tolerances ↔ Perception robustness
Safety standards ↔ Freedom of motion strategies
These aren’t engineering details—they’re product-level decisions.
In such a system, every “requirement” permanently alters the system’s degrees of freedom.
This isn’t writing a PRD; it’s making systemic trade-offs.
3. Embodied Intelligence PMs Must Understand the “Temperament” of the Physical World
I’ve seen far too many failures where the problem wasn’t the algorithm, but reality:
Uneven floors
Changing lighting conditions
Cable aging
Temperature drift
User misuse
The physical world doesn’t evolve according to a roadmap, and users don’t operate the product the way it was demoed.
A PM without real-world, on-the-ground experience will see their product crash and burn in actual deployment.
4. The Rhythm Isn’t Sprints—It’s the “Physical Beat”
The pace of embodied intelligence is never:
Two-week sprints
Quarterly OKRs
It’s dictated by reality:
Supply chain lead times
Mechanical prototyping cycles
Safety certification processes
On-site deployment windows
PMs manage time windows and decision sequencing, not task lists. Getting the sequence wrong is more fatal than moving slowly.
5. Embodied Intelligence PMs Are Essentially “Risk Allocators”
In software, risks can be rolled back. In embodied intelligence, risks must be allocated upfront.
The PM has to decide:
Which risks are handled by algorithms
Which are absorbed by mechanical redundancy
Which are covered by operational processes
Which must be avoided entirely through product positioning
This is responsibility boundary design, not engineering detail.
6. There’s No Room for “Weak PMs” Here
In embodied intelligence teams:
A PM who doesn’t understand the system slows everyone down
A PM who won’t make trade-offs amplifies risk
A PM who only pushes progress leads the team into dead ends
In the end, there are only two possibilities:
The PM is exceptionally strong
Or the role effectively doesn’t exist
This isn’t harsh—it’s reality.
One Final Honest Truth
An embodied intelligence PM isn’t “someone who can write a PRD.”
It’s someone willing to take responsibility for the future before the system even takes shape.
In this field:
Engineering capability sets the floor
Product judgment determines survival
That’s why I’ve always believed— Embodied intelligence isn’t where PMs disappear. It’s where PMs are truly put to the test.