A connected product moves through four controlled stages: requirements, configured sample, pilot validation and production release. Each stage fixes a different set of hardware, software, field and test decisions. One successful prototype does not replace a production baseline.
Requirements
Define the finished product, target users, target markets, installation or use environment, main functions, connectivity, software boundary and sample goal. Unknown items can remain open, but their effect on hardware, firmware, app or cloud, validation and commercial terms needs to be visible.
Outputs from this stage include the product starting point, configuration assumptions, ownership boundary and open-decision list.
Configured sample
The sample combines the selected enclosure or mechanical direction, PCBA and interfaces, module and antenna, firmware states, and the app or cloud functions needed to demonstrate the product. A sample validates the architecture and core user experience; it is not yet a production promise.
Sample evidence includes hardware revision, software versions, device functions, representative screens, known limitations and a validation plan.
Pilot validation
The pilot checks whether the configured sample can be built, installed, operated and tested repeatedly. It adds controlled materials, programming, configuration data, fixtures, issue tracking and representative field use.
Depending on the product, validation can include RF and network behavior, battery or power modes, interfaces, controls, sensors, alerts, app onboarding, cloud reporting and recovery states.
Production release
Production begins from a released baseline: product specification, hardware revision, software versions, configuration files, programming method, functional tests, packaging and unresolved-risk record. Changes after release use version and issue control rather than informal sample updates.
What changes across the stages
Requirements identify decisions. The configured sample proves the selected architecture. The pilot proves repeatability and representative use. Production release fixes the build and acceptance record. Keeping those purposes separate prevents a demonstration unit from being treated as a scalable product.
Common failure points
- Enclosure or antenna changes after RF validation
- App or account flow changes after firmware states are fixed
- Cloud fields changing after dashboard and API work
- Certification assumptions applied to the wrong configuration
- No programming or functional fixture before the pilot
- Hardware and software versions missing from the release record
Official sources
- Equipment AuthorizationFederal Communications Commission
- NISTIR 8259 SeriesNational Institute of Standards and Technology