# State of Physical AI Product Management 2027 — research protocol

**Protocol owner:** Mohammed Cherifi / Hyperion Consulting
**Protocol version:** 0.2
**Protocol date:** 5 September 2026
**Status:** design protocol; recruitment has not started and no findings exist

## Research question

How do organizations assign product ownership, make evidence-gated decisions and move intelligent
machines from technical capability into repeatable field and commercial operation?

The study is designed to expose decision patterns, not to manufacture a market-size headline. It
will examine where product authority sits, what evidence changes investment or release decisions,
where transitions fail, and how the role changes by product maturity and organization context.

## Working definitions

**Physical AI product:** a product whose value depends on an AI-enabled system perceiving, deciding,
communicating or acting in a physical environment, with consequences shaped by a machine, operator,
site, service system or other real-world constraint.

**Operated product:** the complete promise a buyer can justify, users and operators can use, sites
can deploy, specialists can assure, and an organization can support and improve at repeatable
economics.

**Product owner in this study:** the person or group with real authority over integrated product
choices. A title alone does not establish ownership.

The instrument must not assume every respondent uses “Physical AI” or employs a “Physical AI
Product Manager.” Recruitment language should include robotics, autonomous systems, intelligent
machines, industrial AI and software-defined physical products.

## Scope

### Include

- industrial and collaborative robotics;
- autonomous vehicles, mobile robots and connected mobility;
- intelligent machines, inspection and control products;
- AI-enabled energy, charging and infrastructure products;
- embodied or edge-AI products with material field, operator or service consequences;
- platforms and product families that support these products.

### Exclude or analyse separately

- software-only generative-AI products with no material physical operating system;
- fixed automation where AI behavior is not material to the product decision;
- pure research projects with no declared user, buyer or productization intent;
- consultancy responses that describe only a service catalogue rather than an operated product;
- anonymous or unverifiable duplicate submissions.

## Study design

This is an exploratory, mixed-method study. It is not a representative census and will not make
causal claims.

### Phase 1 — design-partner interviews

- target: 8–12 interviews;
- purpose: test definitions, reveal missing decisions, remove consultant language and improve the
  survey instrument;
- participants: founders/executives, product leaders, engineering/systems leaders, operations/field
  leaders and investors or recruiters with direct relevant exposure;
- output: revised codebook, survey and interview guide—not market findings presented as general
  truth.

### Phase 2 — structured interviews and survey

- structured-interview target: 25–40 completed interviews;
- survey-response target: 80–150 eligible, quality-checked responses;
- these are recruitment targets, not achieved sample claims;
- the study may publish with a smaller sample only if the limitation is explicit and no ranking or
  population inference is presented.

### Phase 3 — validation

- return an anonymized theme summary to participants for error checking;
- invite a small, disclosed practitioner review panel to challenge definitions and analysis;
- record disagreements and negative cases rather than forcing consensus;
- separate reviewer input from participant data.

## Sampling and recruitment

Use purposive maximum-variation sampling across:

- company stage: research-to-product, early commercial, scaling, mature portfolio;
- role: founder/executive, product, AI/ML, systems/hardware, safety/quality, field/service, commercial;
- product type and sector;
- organization size;
- region, with a declared European/Netherlands weighting if that is what recruitment produces;
- success state, including stalled, stopped and failed transitions—not only launch stories.

Maintain a recruitment ledger with invitation source, eligibility, sector, role, company stage,
status and conflict-of-interest flag. Do not use Hyperion clients as silent proof. Label any client,
partner, founder-career or commercial relationship in the methods and exclude it from promotional
testimonials unless separately authorized.

## Core constructs

The instrument should measure or elicit:

1. the product and operating context;
2. actual decision rights versus formal titles;
3. product boundary across model, software, hardware, operator, site and service;
4. evidence used at strategy, discovery, productization, launch and scale decisions;
5. build, buy and partner choices;
6. safety, quality, security, regulatory and legal authority boundaries;
7. product/platform/family and variant governance;
8. product economics across device, integration, compute, deployment, support and installed life;
9. human authority, trust, behavior legibility and adoption;
10. transition, capability building, hiring and handover;
11. failure modes, stopped work and decisions respondents would change;
12. outcomes respondents can support without revealing confidential data;
13. the unit of exposure, operating envelope, severity and denominator used for reliability;
14. intervention, recovery, repeated-failure, operator-workload and cost-per-success measures;
15. the declared role and authority of world models, action models, learned policies and monitors;
16. whether evaluation or critic components share models, data, sensors or assumptions with the
    acting component;
17. memory, experience-data, correction and fleet-learning governance;
18. technology-curve, plateau, migration, reversibility and vendor-dependency decisions;
19. product completeness across capability, reliability, authority, evaluation, operations,
    service, commercial commitment, evidence and scale.

## Interview guide

Ask for a specific product and decision before asking for opinions about the category.

1. What did the system do, for whom, and in which operating conditions?
2. Which decision most affected whether it became a repeatable product?
3. Who formally owned that decision? Who owned it in practice?
4. What alternatives were considered, what evidence existed and what remained unknown?
5. Where did hardware, AI, software, site, operator, service or economics create a seam?
6. What claim could the team honestly make at simulation, bench, controlled integration, supervised
   field and normal operation?
7. What was deliberately common, configurable or bespoke across customers and variants?
8. How were build, buy and partner decisions made?
9. What changed for operators, users, maintainers, sales, support or leadership?
10. What did launch require beyond technical readiness?
11. Which metric changed a decision rather than merely reporting activity?
12. If the product owner disappeared tomorrow, which decisions or context would be lost?
13. What should a capable product leader have done differently?
14. Which term or question in this interview misunderstood your reality?
15. What was the exposure unit and denominator behind the reliability claim, and which operating
    conditions were excluded?
16. When the system failed or became stuck, who or what detected it, intervened and recovered it?
17. If a world model, VLA or learned policy was involved, what exact role and maximum authority did
    it hold in the released configuration?
18. How independent was the evaluator or critic from the acting component, and which dependencies
    could create common-mode failure?
19. Which new technology improved capability, which lifecycle complexity did it add, and what
    would trigger rollback or migration?

## Survey design rules

- Use behaviorally specific questions before attitude scales.
- Ask “who decided” and “what evidence changed the decision,” not only “how important.”
- Include “not assigned,” “shared/unclear,” “not applicable” and “prefer not to answer.”
- Randomize response options when order has no meaning.
- Do not require confidential metrics, client names or incident details.
- Pilot comprehension with at least five people outside the design team.
- Freeze the instrument and version before broad launch; record every later amendment.
- Do not combine materially different response modes without reporting the effect.

## Data integrity and exclusions

Record exclusion rules before analysis. Exclude responses that are ineligible, duplicates, empty,
machine-generated, internally contradictory beyond resolution, or completed too quickly to be
credible. Preserve a count and reason for every exclusion. Do not quietly remove inconvenient
responses.

Keep raw data, cleaned data, analysis code and publication tables separate and versioned. Any manual
coding change needs a traceable reason. A second reviewer should independently code a sample of
qualitative responses; disagreement is resolved and documented, not averaged away.

## Analysis plan

- Report counts and denominators beside percentages.
- Describe the achieved sample before interpreting patterns.
- Use medians and distributions for skewed numeric data; do not report false precision.
- Suppress cross-tabulated cells with fewer than 10 respondents and combine categories only when the
  combination remains conceptually honest.
- Do not rank sectors, roles or companies from small or non-comparable cells.
- Treat associations as descriptive, not causal.
- Triangulate role/title answers with the concrete decision narratives.
- Publish negative cases that contradict the dominant pattern.
- Separate design-partner insights from the frozen main sample.
- Label any framework mapping performed by Hyperion as interpretation, not respondent language.

## Privacy, consent and confidentiality

Before participation, state:

- who runs and funds the research;
- the purpose, time commitment and voluntary nature;
- what is recorded and how it will be used;
- whether quotes may be used and under which attribution option;
- retention, withdrawal and contact procedures;
- that participation is not a condition of buying from or working with Hyperion.

Offer three quote permissions: named, role/sector only, or no quotation. Default to no public company
or person identification. Never publish raw notes, contact details, small disclosive cells, customer
secrets, security-sensitive operating details or identifiable incident information. Obtain
appropriate privacy/legal review before recruitment; this protocol is not legal advice.

## Conflicts and commercial separation

Hyperion may benefit commercially from category visibility. Disclose that fact. The report must not:

- turn respondents into implied clients or endorsements;
- score participants against a hidden sales qualification model;
- recommend Hyperion as a finding;
- suppress evidence that weakens a Hyperion framework;
- describe an interview invitation as independent academic research;
- gate access to aggregate findings behind a sales call.

Commercial follow-up requires a separate, explicit opt-in.

## Publication package

If the evidence threshold is met, publish:

1. executive summary;
2. full report with sample, dates, method and limitations;
3. questionnaire and interview guide;
4. codebook and analysis notes;
5. aggregate tables with disclosure controls;
6. anonymized dataset only where consent, contracts and re-identification risk permit;
7. correction and version history;
8. durable archive/DOI after the public release is stable.

Every chart must show the question, base, sample size, date and whether it is single- or
multi-response. Illustrations must be distinguishable from observed data.

## Stop / no-publication criteria

Do not publish a “State of” report if:

- eligibility or provenance cannot be checked;
- the sample is dominated by one undisclosed source or relationship;
- the instrument materially changed during collection without separable versions;
- privacy or contract obligations cannot be satisfied;
- the sample supports only anecdotes but the proposed title implies market measurement;
- analysis cannot be reproduced from the retained source data.

In that case, publish a clearly labelled interview synthesis or methods note—or publish nothing.

## Pre-launch gates

- [ ] Owner approves scope and budget.
- [ ] Privacy/legal review complete.
- [ ] Conflict and relationship labels defined.
- [ ] Consent language and withdrawal path tested.
- [ ] Recruitment ledger and data locations secured.
- [ ] Design-partner guide tested.
- [ ] Main instrument version frozen.
- [ ] Exclusion and analysis rules preregistered with an immutable timestamp.
- [ ] Publication and disclosure review owners assigned.
- [ ] No result, sample size or participant logo is advertised before it exists and is authorized.