The product team arrived with something valuable: a prototype that demonstrated the central use case. Customers could understand it. Investors could see the potential. The engineering team could operate it reliably in a controlled setting.
That success created urgency. The natural next request was to find a Chinese manufacturer, reduce cost, and build a pilot batch. But “find a manufacturer” was too early. The prototype had proven a function. It had not yet defined a repeatable product.
Several parts came from online distributors. Mechanical interfaces had been adjusted during assembly. Calibration lived in an engineer’s notebook and memory. A printed enclosure had been revised around the electronics rather than designed from a controlled stack-up. Cable lengths were “about right.” Firmware releases could be reproduced by the original developer, but not yet by an external production partner.
The first industrialization deliverable was not a cheaper quote. It was a product definition that two independent teams could interpret the same way.
The prototype was a result; production needed a system
A prototype can succeed because a skilled engineer compensates for variation. Production has to succeed because the design, process, tooling, test equipment, and instructions constrain variation before compensation is needed.
We separated the product into five control layers:
- Functional architecture: what the system must do and which performance characteristics matter.
- Physical interfaces: datums, tolerances, connector positions, cable routing, thermal paths, sealing, and service access.
- Electronic and software interfaces: board revisions, firmware versions, calibration data, programming, logs, and update responsibility.
- Production process: assembly sequence, fixtures, torque, adhesives, inspection points, end-of-line test, and rework limits.
- Field system: packaging, installation, configuration, spare parts, diagnostics, repair, and feedback into engineering.
The team had strong knowledge in layer one and fragments of the other four. The China program therefore needed to fill control gaps before it optimized purchasing.
The BOM was not yet a bill of materials
The prototype list contained part descriptions and purchase links. That is enough to rebuild one unit while those links remain valid. It is not enough to control a production configuration.
Each line needed a manufacturer part number or controlled specification, approved alternates, lifecycle status, revision ownership, critical characteristics, expected lead time, minimum order implications, and a decision about who could authorize substitution. Without those fields, a contract manufacturer would either stop frequently for approvals or make reasonable substitutions that silently changed the product.
| Prototype habit | Production risk | Required control |
|---|---|---|
| Purchase link as specification | Uncontrolled vendor or revision change | Part number, approved source, alternates policy |
| “Equivalent is acceptable” | Performance moves without design review | Critical parameters and substitution authority |
| Hand-selected component | Yield loss when natural variation appears | Incoming range, calibration strategy, or tighter design margin |
| Engineer-installed firmware | Wrong build or unrecoverable units | Controlled image, programming method, verification record |
| Visual final check | Functional defects escape | Test limits, fixtures, logged result, failure disposition |
This work also exposed commercial decisions. Some components were cheap per unit but carried long or volatile lead times. Others were available quickly but required minimum orders that distorted the pilot economics. One custom part could be simplified to a catalog component if the mechanical interface changed. The better sourcing answer depended on whether speed, unit cost, redesign effort, or long-term resilience was dominant.
The most important supplier question was: who owns the design?
The team initially wanted a single factory to “take responsibility for everything.” That sounds efficient. It can also transfer design knowledge without transferring design accountability.
We distinguished three roles:
- Design authority: decides whether a change is technically acceptable and maintains the controlled product definition.
- Process authority: decides how the product will be built, inspected, tested, and reworked within that definition.
- Supply-chain authority: selects and manages approved sources, lead times, commercial terms, and continuity risk.
A capable manufacturing partner could hold the second role and parts of the third. The product company still needed to retain the first, even if it used external engineering support. Otherwise every supplier suggestion—changing a connector, widening a tolerance, replacing a sensor, modifying firmware—could become a product decision made through purchasing.
We selected a supplier architecture before selecting suppliers
The product crossed mechanical, electronic, cable, firmware, test, and final assembly disciplines. No single company needed to make every part. One company did need to own final configuration and production records.
Three models were considered:
Vertically integrated manufacturer
Attractive for consolidated responsibility, but likely to be strong in only some processes and to subcontract the rest. The diligence question would be whether it controlled those external processes and protected the product’s critical characteristics.
Contract manufacturer as orchestrator
Strong when the assembly partner has disciplined engineering change control, incoming quality, test development, and supplier management. Weak when it behaves mainly as a purchasing office around an assembly line.
Product company manages specialist suppliers
Offers the most direct technical control but creates coordination load. It is usually fragile unless someone owns configuration, incoming acceptance, nonconformance decisions, and the final build record.
The project chose a lead assembly and test partner supported by specialist suppliers for a small number of critical items. The decision was based less on factory size than on documentation discipline, engineering access, test ownership, and willingness to work through a controlled change process.
The pilot was redesigned as a sequence of learning gates
A pilot quantity is often treated as a smaller purchase order. We treated it as an evidence program. Units would be released only when the previous layer had answered its question.
- Architecture freeze: define controlled interfaces and unresolved assumptions.
- Engineering units: prove assembly sequence, programming, calibration, and basic functional test.
- Design verification: test critical performance and environmental risks against explicit limits.
- Process trial: build without the original prototype engineer compensating at each step.
- Pilot release: produce controlled units with serial records, approved deviations, and a field feedback plan.
Crucially, the “golden sample” was not allowed to become the specification. A sample is useful as a visual and functional reference, but it cannot explain which dimensions are critical, what variation is acceptable, which firmware it contains, or how an apparent mismatch should be resolved. Drawings, specifications, software versions, test limits, and approved deviation records had to remain authoritative.
What the China visits needed to prove
Once the architecture was clear, factory visits became much more productive. Each visit had a decision attached to it.
- Could the candidate lead partner control revisions across mechanics, electronics, firmware, and test?
- Could it show a real example of an engineering change moving from request to approval to production?
- Would the engineers who quoted the project remain involved after the order?
- Could it develop and maintain fixtures and end-of-line tests, including failed-unit disposition?
- How would subcontracted critical processes be approved and monitored?
- What evidence would travel with each pilot unit?
The difference was visible. Instead of asking factories whether they could make the product, the team could test whether each candidate could own a defined part of the industrialization system.
The commercialization lesson
China did not solve the prototype simply by offering cheaper parts. It offered dense access to component suppliers, manufacturing processes, fixture builders, assembly partners, and engineers who could iterate quickly. That advantage became useful only after the product team knew which decisions it was willing to delegate and which it needed to control.
The workstream shifted from “quote and build a batch” to “define, test, and transfer a controlled product.” That shift is less exciting than watching a prototype run. It is also what makes the next hundred units more likely to behave like the first one.