Prototype-to-Production Readiness Scorecard

How to use the scorecard

Use the scorecard before a pilot build, before a manufacturing handoff, or when a connected product keeps producing unclear field issues. The point is not to create a perfect grade. The point is to force the team to name what the product can prove today and what still depends on hope, memory, or clean-bench conditions.

Score each area with the people who own the product day to day: hardware, firmware, app, cloud, support, and operations. A useful review should expose disagreements. If firmware says device state is clear but support cannot explain a returned unit, that gap is the work.

What each scoring area reveals

• Recovery exposes whether the product can fail, restart, reconnect, and explain what happened without a bench engineer nearby.
• Diagnostics expose whether support, firmware, cloud, and mobile teams can see the same useful history.
• App and cloud compatibility exposes whether setup, state, permissions, and backend records agree under real conditions.
• Supply and factory readiness exposes whether the product can be built, tested, and traced repeatedly.
• Ownership exposes whether every risk has a person, next action, and validation path.

What a weak score means

A weak score is not automatically a blocker. It is a signal that the next build or launch plan needs a narrower risk-reduction step. Weak diagnostics may mean adding firmware events before building more dashboard screens. Weak factory readiness may mean building a repeatable production test before ordering more units.

The dangerous score is the one nobody can justify. If a category feels green because the prototype worked once, it should usually move back to yellow until the team can point to evidence.

What evidence should exist after review

• A short risk list ordered by production impact, not by team preference.
• An owner for each weak area and a next validation step.
• A clear distinction between customer-facing status and engineering diagnostic truth.
• A list of signals the system must capture before the next pilot or production build.
• A decision on what can wait and what must be fixed before more units ship.