Checklist / Scorecard
Prototype-to-Production Readiness Scorecard
Your prototype works. What still needs attention before other people can build, use and support it? Use this checklist to find the gaps.
How to use the scorecard
Before you order a pilot build, it helps to look beyond whether the prototype works. Can someone else set it up? Can you diagnose a returned unit? Can the factory test every board? I put this scorecard together to help your team work through those questions.
Fill it out with the people responsible for hardware, firmware, the app, cloud, support and operations. Ask each person to explain their score. If the firmware engineer can diagnose a failure but support can’t, you’ve found something to address before more units ship.
What to check
- Recovery: unplug it, interrupt its network connection and restart it. Can it return to a usable state without an engineer stepping in?
- Diagnostics: can support see the events leading up to a failure, and can engineering use that same history to investigate?
- App and cloud compatibility: try setup and control with the versions your customers will actually use. Check that the app, device and backend agree on what happened.
- Supply and factory testing: can you get the parts, test each unit and trace a returned device back to its build?
- Responsibilities: does each unresolved problem have someone responsible for fixing it and a way to check the fix?
What to do with a low score
Use a low score to decide what to work on next. If you can’t explain device failures, you may need better firmware logs before more dashboard screens. If testing depends on one engineer’s bench setup, you may need a repeatable factory test before ordering more units.
I’d question any high score that nobody can explain. A successful demo is useful, but it doesn’t tell you how the product handles a lost connection, an interrupted update or a customer trying setup for the first time.
Record the decisions
- A short list of problems, with the ones most likely to affect the next build at the top.
- A person responsible for each gap and an agreed way to check their fix.
- A description of what the customer sees and what your diagnostic tools record when something fails.
- The logs and device data you need to collect during the next build.
- An agreement on what needs fixing before more units ship and what can wait.
Resource