Sep 2025 · 2 min read
By Jonathan Lwowski
Why Physical AI Teams Become Infrastructure Companies
Product strategy for robotics must account for the data, simulation, evaluation, and compute systems that make dependable physical intelligence possible.
Physical AI · Product Strategy · AI Infrastructure
When people ask what a robot can do, I often find myself thinking about the work around the robot. How will the team collect evidence, train safely, evaluate behavior, and learn from what happens after deployment?
This is an original companion to the AI & PM Insights newsletter edition on Physical AI infrastructure. The central lesson is practical. The product boundary is usually wider than the initial model or robot feature.
The workflow is the product
In my experience, robotics teams need a repeatable path from a real-world observation to a decision about what to build next. That path connects capture, labeling, simulation, training, evaluation, and deployment.
A physical AI roadmap should name the learning workflow, not only the model capability.
Each link introduces a product decision. A team must decide what signals to retain, what constitutes a useful evaluation, when simulation is representative enough, and how production results return to the development loop. Ignoring those decisions does not remove the work. It distributes it across ad hoc tools and manual handoffs.
Design around learning velocity
Infrastructure earns its place when it reduces the cost and time required to learn. I find it helpful to keep four questions visible.
- Data Can the team find and trust the observations behind a result?
- Simulation Can it test consequential behavior before a field release?
- Evaluation Does success reflect the customer task, not just an offline metric?
- Compute Can the workflow iterate at the pace the roadmap requires?
The answer will differ by application. What matters is making the tradeoffs visible, giving someone ownership, and paying attention to whether the loop is actually getting faster and more reliable.
Build the right interfaces
Observe → define → build → evaluate → deploy → learn.
The goal is not to build every layer internally. It is to preserve enough context between layers that people can understand why something happened and decide what to do next. When that connection is in place, infrastructure stops feeling like overhead and starts becoming an advantage the whole team can build on.