A working prototype answers one question: can this technical approach produce a useful result under the conditions we tested?
A product has to answer a harder set of questions. Will a buyer pay for the outcome? Can an operator trust it? Can the full system behave safely in the field? Can the company install, support and improve it? Can the result repeat across customers, sites or variants?
The gap is not a mysterious failure of innovation. It is a missing product system.
Prototype evidence is necessary but incomplete
A robotics, autonomy or industrial-vision prototype is valuable. It can establish feasibility, reveal integration constraints and create a shared object for customer discovery. The mistake is treating that evidence as if it also proved adoption, supportability and commercial viability.
Keep the claim narrow:
Under these stated conditions, with this data and this configuration, the prototype demonstrated this observed behaviour.
Everything outside that sentence remains a question. That is not pessimism. It is a clean evidence boundary.
Stall 1 — No consequential buyer decision
Teams often start with a model, sensor or demo and only later ask which decision it improves for a customer. The result can be technically impressive and commercially optional.
Write the buyer decision in one sentence. Name the buyer, current workflow, consequence of error, desired outcome and evidence that would justify change. If those elements are missing, another engineering sprint will not make the opportunity clearer.
Gate: Strategy. Decide whether this is the right product opportunity before optimizing the solution.
Stall 2 — The operator is treated as an interface problem
Physical AI enters a real workflow. Operators, maintainers, safety owners, installers and supervisors each interact with the product differently. A dashboard is not evidence that the workflow works.
Observe the work. Record where a recommendation appears, who can override it, how a false positive is handled, how the system degrades, and what happens during a shift change or service visit. Convert those observations into acceptance criteria.
Gate: Discovery. Prove that the product fits the field, not only the demonstration.
Stall 3 — The model is mistaken for the system
A model result is one component in a product that also includes sensors, compute, connectivity, deterministic controls, human oversight, update paths, observability and operational ownership.
Create a failure-oriented architecture review. Start with safe state, latency budget, offline duration, data lineage, update rollback and incident evidence. Then decide where the model belongs and how much authority it receives.
Gate: Productization. The complete system, not the model, must meet the acceptance criteria.
Stall 4 — Nobody owns the day after launch
A prototype can be carried by the people who built it. A product needs explicit ownership for release approval, field support, incident response, data quality, supplier dependencies and model change.
Put names beside those responsibilities before launch. If a responsibility has no owner, it is not a future operational detail. It is an unresolved product requirement.
Gate: Launch. Installation, acceptance, support and responsible operation are part of the product.
Stall 5 — The economics depend on a perfect case
A product case built from peak model performance and ideal deployment conditions hides the cost of installation, integration, exceptions, support and variation.
Use ranges. Separate observed values from estimates. Show which assumption changes the decision. Then design a field test that targets that assumption directly.
Gate: Scale. Value, deployment and economics must repeat by design; a single successful site does not prove that they will.
The prototype-to-product decision memo
Before authorizing the next build phase, create one shared memo:
- the buyer and consequential decision;
- the field workflow and acceptance criteria;
- the observed prototype evidence and its limits;
- the complete product-system architecture;
- safety, governance and operating owners;
- economics as ranges, with unknowns visible;
- a proceed, change, partner, pause or stop recommendation;
- the evidence required for the next gate.
This memo is not a status report. It is the mechanism that forces product, engineering, commercial and field evidence into one decision.
A note on timelines
There is no universal ninety-day conversion promise. A bounded subsystem with an available field environment may move quickly. A safety-related product, new hardware design or regulated integration may not. Set a review clock to prevent indefinite experimentation, but derive the delivery plan from evidence and constraints.
Use the Physical AI Product System to locate the unresolved gate. If the decision spans several functions and the evidence is fragmented, the Product Decision Review produces the decision memo before more build work is authorized.
Source anchors
The five stall patterns are Hyperion's product-system synthesis, not claimed incident frequencies. The NIST AI RMF Core connects context mapping, deployment-like evaluation, monitoring and proceed decisions across the AI lifecycle. The UK government's Introduction to AI assurance describes lifecycle assurance, multiple complementary techniques and clear accountability. These sources support the evidence and ownership principles; each prototype still needs its own product, safety, regulatory and commercial assessment.
