The phases of electronic product development
The prototype works on the bench, and the usual question follows: how far are we from manufacturing it? The answer depends on which phase the project is in, and on what has been left open along the way. No standard defines the phases of electronic product development, and every company uses its own. But the most widely used methods share the same logic: decide early on what is expensive to change, test against what was specified, and don't go into series production without preparing for it.
The phases, from idea to factory
These are the phases that structure a typical project. The names vary depending on who uses them. What matters is what goes into each one, what comes out and what is decided before moving on.
1. Specification
What goes in is an idea, sometimes with a proof of concept on an evaluation board. What comes out is a document stating what the product has to do, in which environment, in which markets it will be sold and at what target cost. It is the reference against which everything else will be tested.
2. Architecture and feasibility
This is where the building blocks that constrain everything else are chosen: microcontroller, communications, power and battery, enclosure and connectors. You check that the combination is technically and commercially feasible, and that the key components can be bought.
3. Detailed design
Schematic, PCB layout and firmware, with reviews at fixed points. What comes out is everything needed to build the first prototype: manufacturing files, bill of materials and a test plan.
4. Prototypes and validation
The boards are assembled and brought up, and validation tests check that they meet the specification. In consumer electronics and IoT it is common to call the round that validates the engineering and components EVT (engineering validation test), and the one that validates the complete design against the requirements DVT (design validation test). It is widely used terminology, not a standard. In our projects, two board iterations before production is normal.
5. Certification
The tests and documentation required by the target market, which in Europe end in the CE marking. We explain it in the article on which certifications an electronic device needs.
6. Pre-series and industrialisation
The PVT round (production validation test) validates the production process: that the product can be built repeatably and at scale, usually in a pilot run. This is where design for manufacturing (DFM) and production testing come in. Even when the design is right first time, the contract manufacturer that assembles the boards (EMS) usually asks for small changes to optimise production.
7. Production
The first batch, and support for whatever turns up in it.
From schematic to first prototype:Hardware designPrototyping and bring-up
Three methods for moving through the phases
The phases say what has to be done. A method says how you move from one to the next and who decides. There are three approaches worth knowing, because each solves a different problem.
Stages and gates (Stage-Gate)
This is a management method created by Robert G. Cooper, who first published the term in 1988. It splits development into stages: discovery, concept, business case, development, testing and validation, and launch. Before each stage there is a gate: a decision point with defined deliverables and criteria. The possible decisions are go, kill, hold or recycle. A "go" commits budget, people, timeline and the date of the next gate.
Its strength is that it forces decisions based on evidence, and makes it possible to stop a project that is not going to work before it is too late. It does not say how to design or how to test: that is left to engineering.
The V-model
This is an engineering method. The V-Modell XT, the reference model of the German federal administration, sums it up in four principles:
- On the descending branch of the V, the system is broken down into modules and specified in increasing detail: the requirements say what it must do, and the architecture and the integration and test plan say how.
- On the ascending branch, the parts are built or bought and integrated up to the complete system.
- There are tests at every level, and their specifications derive from the requirements and specifications on the descending side: every requirement has its test.
- The V is not traversed just once: it is normally gone through several times, in iterations, and the system grows with each one.
The V helps to separate two questions that are often confused. NASA distinguishes them like this. Verification shows that the product meets each requirement, in other words that it was built right. Validation shows that it achieves its purpose in the real environment, in other words that the right product was built. A product can pass every verification and still be of no use to the customer, if the specification was wrong.
Iterative and agile
The Agile Manifesto was written in 2001, for software. Among other things, it values working product over comprehensive documentation and responding to change over following a plan, and it proposes delivering something that works every few weeks. In hardware, those iterations run into the lead times of making physical parts: you cannot recompile a board. According to engineering software vendors such as PTC, this is why many organisations use hybrid models that combine agile practices with traditional engineering processes.
How they fit together in practice
The three approaches do not compete. The V-Modell itself organises the project around decision points it calls quality gates, and allows combining it with agile methods such as Scrum or Kanban. In an electronics project, a sensible combination looks like this:
- The gates separate the phases in the figure and force a decision: no moving to design without a closed specification, and no pre-series without a passed DVT.
- Each prototype round is a full pass through the V: specify, design, build, integrate and test against the specification. EVT, DVT and PVT are the names of those passes.
- Within each round, firmware and testing can move forward in short iterations, which is where agile works without clashing with manufacturing lead times.
This is also the logic behind how we work: a proposal with a fixed scope, design with reviews, and prototyping and validation iterated until the specification is met.
Why late changes cost so much
A 2004 NASA study, on hardware and software systems the size of a spacecraft or a small satellite, estimated how much it costs to fix a requirements error depending on the phase in which it is found. If fixing it in the requirements phase costs 1, it costs 3 to 8 in design, 7 to 16 in manufacturing, 21 to 78 in integration and test, and 29 to more than 1,500 in operation. These projects are far larger than an IoT product and the figures do not carry over as they are, but the trend holds at any scale: every phase that goes by makes the change more expensive.
That is why NASA insists on validating often during design, and especially at the start, when correcting course is still cheap. In practice, it means showing mock-ups, early prototypes and the specification to the people who will use the product before the design is frozen.
What a working prototype is missing
A prototype that works on the bench has passed, at most, something like an EVT. What people who arrive with a prototype like that are usually missing is design for manufacturing and industrialisation: components that can be bought in volume, a board the EMS can assemble without rework, a production test and the documentation to build it without the designer standing next to the line. Those are phases 6 and 7, and they cannot be improvised at the end.
If your project is at that point, we can help you work out what is missing to reach production.
Getting to production:Design review and rescueTest and validation