Physical AI Product Strategy
- Client
- RLWRLD
- Date
- 2026
- Role
- Strategy & Operations
- Team
- Cross-functional · Business, Product & Deployment
Context
RLWRLD is a seed-stage Physical AI company building robotics foundation models for industrial environments. The seed round was $41M, and the model reached state of the art across eight benchmarks.
What it didn't have was a product. Or a product organization, or a process for deciding what a product would be. The model was real; everything downstream of it was blank.
The Problem
At a company this early, the hard part isn't choosing between options. It's that there are no options yet — no shortlist to evaluate, no customer telling you what's missing, no analog to copy. And the usual inputs are absent: no usage data, no deployment history, and a market too new for market research to describe.
The work wasn't making a decision. It was building something capable of producing decisions, fast enough to matter to a company burning seed capital.
What I Decided
1. The model wasn't the bottleneck. The data pipeline was.
A foundation model is only as good as what trains it, and for robotics that means physical interaction data — which nobody has at scale. Working across the strategy, product, and deployment teams, I mapped the pipeline that would have to exist for the model to keep improving: collection, augmentation, annotation, curation, evaluation. Each of those is a product surface, not a chore. That reframing is what turned a blank page into a buildable list.
2. Prioritize against three capability sets, not market size.
Market sizing for a category this new produces a number nobody should act on. Instead I evaluated each candidate against what we could build, what competitors already covered, and what partners — including data providers — could supply. What survived was the set where our capability was real, the gap was genuine, and no partner was better positioned to fill it.
3. The user isn't the factory. It's whoever deploys to the factory.
A seed-stage company cannot roll robotics out across an industrial base. That work goes to consulting and systems integration firms — which means the product they need is different from the product the factory needs. Deployment tooling, integration paths, and evaluation they can run themselves without our engineers on site. I spent five years inside that kind of firm. I knew what makes an enterprise integrator able to sell and ship something, and what makes them quietly drop it.
4. Use AI to compress the loop, not to produce the answer.
With no data and no precedent, the constraint was cycle time. I used AI heavily — not to generate conclusions, but to get a rough first pass on the table in hours instead of days: competitor capability maps, literature synthesis, keyword frequency across papers and industry news. The team then argued with it. Being wrong quickly and visibly was more useful than being careful and slow, because the thing we were optimizing was the number of times we could revise a position per week.
5. Turn the strategy into orders, not a deck.
Once the pipeline was mapped and prioritized, I assigned workstreams to three teams: Product built the tooling, Lab — an affiliated research group — owned the model-level improvements each product surface required, and Deployment owned the integration paths that would make the whole thing shippable by third-party firms. Each team received priorities scoped to their process stage, not a strategy document to interpret.
Where It Stands
The strategy was adopted and is in execution. Specifics are internal.
Open Questions
The prioritization rested on interviews and judgment more than evidence, because evidence didn't exist yet. I'm not sure that was avoidable at this stage — but I'd want to know sooner which of those judgments were wrong, and I didn't build a way to find out. In a market this undefined, the strategy that matters most may be the one for learning you were wrong.