The Hardware Product Development Process, Reframed
Hardware product development is a decision sequence, not a phase chart. The actual gates, the actual failure modes, and what should be decided at each one.
Search for “hardware product development process” and you read the same article fifty times. Eight phases. Five stages. Seven steps. A horizontal arrow from ideation to mass production. Each phase gets a paragraph describing what “happens” in it. None of it is wrong, and almost none of it is useful to the people actually running a hardware program.
The phase-chart framing describes the scenery, not the road. Phases do not tell a CTO when to commit, what to defer, what the cost of being wrong is, or what must close before the program is allowed to move forward. A phase chart is a calendar. A hardware program is a sequence of commitments, each more expensive than the last.
This pillar is the framing we use on every program we own. Not a process chart. A decision sequence. The phases exist — we use them — but they are scaffolding. The work is the decisions inside them.
The hardware product development process is a decision sequence, not a phase chart. Phases are time containers. Decisions are commitments. The program does not advance when a phase ends on the calendar; it advances when the decisions that phase was supposed to close have actually closed — and the cost of reopening any one of them rises super-linearly across the sequence.
Why the hardware product development process is explained wrong
The phase-chart article is a genre. It exists because phases are easy to draw and easy to sell as a consulting deliverable. Three failures follow.
First, it suggests the phases are the work. They are not. The work inside Phase 1 — deciding what the product is, what physics constrain it, what the target unit cost allows — is different in kind from the work inside Phase 3. The hardest question in each is a different hardest question.
Second, it encourages teams to move on calendar pressure rather than decision-closure. The end date arrives. The team declares the phase complete. The decisions that phase was supposed to close get deferred. We covered the downstream consequence at From Prototype to Production: programs die when decisions deferred in Phase 1 become blocking constraints in Phase 3.
Third, the phase chart flattens cost. Every box looks the same size. A wrong decision surfaced in Phase 1 costs a week of engineering. The same decision surfaced after tooling is cut costs a quarter of the year and a six-figure tooling rewrite. A phase chart cannot show that asymmetry because it treats time, not commitment, as the axis.
Hardware founders and CTOs do not need another eight-box diagram. They need a model of when decisions must close, what it costs when they do not, and where a program is allowed to be ambiguous versus where it is not.
The process as a decision sequence, not a phase chart
Reframe the program this way. Three phases — Definition and Feasibility, Prototype and Validation, Production Readiness. Each phase is not an activity. Each phase is a convergence on a specific set of decisions. The phase is done when those decisions close, not when the calendar says so.
Three convergences. Each phase is defined by the decisions it must close, not the weeks it consumes.
In this framing, “what phase are we in?” becomes less useful than “which decisions this phase has to close are still open?” The second question tells you what to work on. The first one does not.
Phase 1 — Definition and feasibility
Phase 1 exists to answer one question: is this product worth building, and in what shape? The decisions that must close here are the ones whose reversal later will destroy the program.
Product thesis. What problem does the product solve, for whom, at what price point, in what use context? This is not a marketing exercise. It constrains physics. A device that has to sell for €180 retail cannot carry a €40 lidar. A device that operates at -30°C cannot use a battery chemistry that derates at -10°C. The product thesis is a cost, environment, and performance envelope every downstream decision must fit inside. If the thesis is soft, every downstream decision will be soft.
Feasibility envelope. Is what you are trying to build actually possible at the cost and form factor the thesis allows? This is where first-principles analysis happens — thermal, power, RF link, optical, mechanical envelope, weight, battery life under realistic duty cycle. The output is a numbers-backed position on whether the thesis is buildable and at what architectural bet.
Architectural bet. At the end of Phase 1, you have committed to a set of architectural choices: which radio, SoC versus MCU, injection-molded versus machined, dedicated real-time processor versus shared. These are bets that constrain the next eighteen months. Making them without feasibility data is not bold — it is expensive.
Regulatory posture. Every hardware product has a regulatory shape. Medical device, radio device, industrial equipment, consumer electronics. The posture decides which certifications, which pre-compliance testing, which design rules, which timelines. A team that discovers its product is a Class II medical device at DVT has lost a year. A team that gets this right at Phase 1 designs its PCBs, enclosures, and firmware with the certification path already in scope.
Unit economics target. BOM target. Assembly target. Gross margin at what volume. An unconstrained BOM in Phase 1 is the single most common source of Phase 3 wreckage.
The teams that fail in Phase 1 almost always fail the same way: they treat it as the “fun phase.” Mockups, renders, a spec doc full of adjectives. They have not run a thermal calculation, priced a serious BOM, or tested a radio link. Why Hardware MVPs Fail (And What to Build Instead) is about exactly this failure: a Phase 1 that looked like a product but did not close the decisions Phase 1 exists to close.
Done right, Phase 1 produces a decision, not a deck. Go, no-go, or pivot — on specifically this architectural bet, at this unit cost envelope, under this regulatory path.
Phase 2 — Prototype and validation
Phase 2 turns the architectural bet into measured reality. The bet from Phase 1 is an educated guess. Phase 2 replaces guesses with data, on hardware, and retires the technical risks the thesis assumed away.
Architecture validation. The first real units — typically three to ten, hand-built — answer whether the architectural bet actually works in hardware. Does the thermal envelope hold under realistic load? Does the radio link close at range with a realistic antenna in a realistic enclosure? Can the processor hit control-loop timing? Does the battery deliver the runtime the thesis requires, under the duty cycle the thesis requires, at the temperature the thesis requires? These are measurements, not opinions. If the measurements disagree with the thesis, the thesis updates — now, not later.
BOM maturation. The prototype BOM is a shopping list. The production BOM is an engineered artifact with prices at real volume, qualified second sources on every critical part, lead times mapped to the program schedule, and EOL horizons that outlast the product’s commercial life. Teams that leave this for Phase 3 pay for it in Phase 3.
Firmware architecture hardening. In Phase 1, firmware is a sketch. In Phase 2 it gets real architecture: bootloader strategy, update path, calibration scheme, serialization, logging, OTA if applicable, memory budget, timing budget. A team that leaves firmware architecture in active refactor past Phase 2 will hit the DVT-to-PVT wall documented at EVT, DVT, PVT: What Each Gate Actually Decides.
Test strategy drafting. End-of-line test, calibration flow, provisioning flow — these do not appear in Phase 3. They get designed in Phase 2, built in parallel with the DVT units, and validated before the first real production pass. A test strategy that appears for the first time at PVT is late.
DFM dialogue opened. The CM relationship starts in Phase 2, while the mechanical is still plastic and the PCB is on rev C. DFM input gets folded in while the design can still absorb it cheaply. Teams that skip this and hand a finished design to a CM at PVT pay a rework tax that could have been a conversation.
The purpose of Phase 2 is not “make a prototype.” It is to close enough decisions that Phase 3 is de-risked. At AimRobotics, we owned the full program — concept through shipping product. Phase 2 was where the architectural bet on actuator type, drive electronics, and control-loop architecture got validated against measured torque, thermal, and lifetime data. Without that convergence, Phase 3 would have been a guess. With it, Phase 3 was mechanical.
Phase 3 — Production readiness
Phase 3 is the most expensive phase, the shortest in real-time if done well, and the one where the costs of earlier ambiguity come due. It is not a continuation of Phase 2. It is a different project.
Architecture freeze across layers. Mechanical, electronics, and firmware freeze together, or none of them freeze. A mechanical freeze with electronics still in flux means the enclosure will need a rev. Firmware in active refactor during DVT means the DVT units do not mean what they say. The freeze has to be cross-disciplinary or it is fiction.
BOM locked, second-sourced, priced at volume. The BOM is an artifact the CM can quote against without twenty questions attached. Every critical line item has a qualified alternate. Every long-lead item has a purchase commitment in the right window. EOL horizons extend past the product’s commercial life.
DFM sign-off. The CM has reviewed the complete design package and signed off. Tolerance analysis has been run against real parts. First-article inspection data is in spec. The design can be built by line operators, not by the engineers who designed it.
End-of-line test validated. The fixture exists. A line technician can operate it. It runs at line speed. It catches the defects that actually occur in volume. Calibration and provisioning flows are integrated and verified.
Supplier commitment signed. MSA signed, capacity committed in a specific window, pricing agreed at real volume, escalation path defined. Logistics, warranty, and service paths are defined downstream.
These are the five decisions broken down in depth at From Prototype to Production. Phase 3 is done when every one of them is converged. If any one is still open, first production is a coin flip.
At Rheo Dive, we took a consumer hardware product the full sequence — POC, EVT, DVT, PVT, mass production — with custom optics, custom PCBA, silicone over-molded tooling, an iOS app, and a dive computer rated to twenty meters. Every Phase 3 decision was closed before first tooling. First production met yield on first pass. That is the phase doing its job.
The three failure modes we see most often
Across twenty-plus programs we have led or rescued — industrial robotics, medical devices, power electronics, consumer hardware, life-safety systems — failure modes cluster into three. Every one is a failure of decision-sequence discipline, not of engineering talent.
Premature build
The team starts building before it has decided. An enclosure goes to CNC before the internal layout is settled. A PCB goes to fab before the processor is chosen. A firmware build targets a chip family that has not been committed to. The activity feels productive because parts are being made. Each of those builds encodes assumptions the next decision will invalidate, and each invalidation costs a rev cycle and two to four weeks.
Premature build almost always comes from pressure to show progress to a board, an investor, or a pilot customer. It trades visible activity for downstream cost. The cure is discipline about what enters the build pipeline. If a decision has not closed, nothing downstream of it is permitted to be cut, fabbed, or ordered. We detailed how this compounds into multi-quarter slips at Why Hardware Projects Overrun by 12+ Months.
Parallel drift
Hardware, firmware, and product strategy run on three separate tracks, each making its own decisions, each unaware of what the others have committed to. The mechanical team freezes the enclosure. The electronics team realizes a week later that the new connector pinout does not fit. The firmware team has been building against a processor the electronics team swapped last sprint. The product team has promised sales a feature the processor cannot support at the timing the mechanical cooling design allows.
In software, drift is merged away in a commit. In hardware, drift shows up as a physical incompatibility discovered too late, fixed in copper or in molded plastic, billed to the tooling budget.
The cure is cross-disciplinary convergence at the phase gates. The architecture freeze is not a firmware freeze or a mechanical freeze — it is a single act across all three.
Hidden scope creep
Decisions made in Phase 1 get quietly reopened in Phase 2 or Phase 3 because the system was not stress-tested when it was cheap to stress it. The product thesis said “battery lasts a day.” Nobody ran the math under realistic duty cycle at realistic temperature. DVT units show the battery lasts six hours. Now either the thesis, the battery, or the power architecture changes — every one a Phase 1 decision reopened after tooling is committed.
Hidden scope creep is the accumulated debt of decisions that looked closed but were not. The cure is adversarial review at phase gates — someone whose explicit job is to find decisions the team believes are closed but are, on inspection, still load-bearing on untested assumptions. Internal teams protect their own closed decisions. Outside review does not.
What “done” actually looks like for each phase
“Done” gets used sloppily in hardware programs. A phase is not done because the calendar turned over. It is done because the decisions it had to close have closed, and you can name the evidence that proves it.
Phase 1 done
You can describe the product in a single page: what it does, for whom, at what price, at what BOM target, at what performance envelope, under what regulatory posture, on what architectural bet. Every claim is backed by first-principles analysis or measured data — thermal, power, radio link, mechanical envelope, duty-cycle-adjusted battery math. A skeptical engineer reading the page cannot identify an unresolved assumption that would invalidate the thesis. The go/no-go call is defensible to a board.
Phase 2 done
EVT units exist, they work, and performance matches the Phase 1 thesis on measured data — by test report, not visual inspection. BOM is mature: every critical part has a qualified second source, a price at volume, a lead time, an EOL horizon. Firmware architecture is frozen and the code is hardening. Test strategy is drafted. The CM has given preliminary DFM input. The architectural bet is retired as a risk — it is now a committed choice.
Phase 3 done
Cross-layer architecture freeze is in place. BOM is locked, second-sourced, priced at volume. DFM sign-off is complete with first-article inspection data in spec. End-of-line test is validated by a line technician, not the design engineer. MSA is signed, capacity committed, first PO cut. PVT first-pass yield is in the mid-to-high nineties on a straightforward electromechanical product, above eighty-five percent on a complex multi-discipline system. The CM’s technical lead will tell you the program is ready. If any of the above is still open, Phase 3 is not done — regardless of the calendar.
The common thread: “done” is an evidentiary claim, not a calendar event. A program that cannot produce the evidence for a phase is not done with it, no matter what the schedule says.
When to bring in external product engineering leadership
Engineering talent is rarely the bottleneck. Direction is. The moments when external product engineering leadership pays back fastest are not the moments the team is short-handed. They are the moments the decision sequence is at risk of failing. Three of them.
Between Phase 1 and Phase 2. The architectural bet is about to be made. If the bet is wrong, eighteen months of downstream work are wrong. An external lead with pattern recognition across twenty programs will spot architectural bets that look reasonable but have failed before. This is the cheapest place to add outside judgment.
Between Phase 2 and Phase 3. The production transition is a different project from prototyping, and the internal team — deep in Phase 2 for months — is almost always the wrong team to lead it. A founder-engineer brilliant in Phase 1 and Phase 2 gets swamped in Phase 3, because Phase 3 is a CM-relationship, supply-chain, yield-engineering problem, not a design problem.
When a decision has been reopened. If a Phase 1 decision is back on the table in Phase 3, the program is in a different problem than the one it thinks it is in. External leadership at this moment is triage. The question is no longer “how do we finish the original plan” but “what does the program actually look like now, and what is the fastest defensible path to production from the new reality.”
We have done all three. At Aerones we led the infrastructure layer — power, connectivity, industrial controls — while the company scaled past three thousand turbine services per year to ten thousand, under commitments to clients representing over half of global wind capacity. The Raspberry Pi to Beckhoff migration was a decision reopened mid-flight under scale pressure. At AimRobotics, we owned the end-to-end program from Phase 1 through shipping product. At Rheo Dive we took a consumer device the full sequence including mass production.
Our model is structured on exactly the decision-sequence framing this pillar describes. We work in fixed-scope phases, not hourly billing, because the work itself is phase-structured — and because hourly billing creates the wrong incentive at precisely the gates where discipline matters most. How we structure engagements is at /framework.
The rule: if you are making an architectural bet with more than eighteen months and a million euros of downstream work resting on it, and you have not had a senior external technical lead stress-test that bet, you are under-investing in the cheapest insurance in the program.
The process is the decision sequence. Phases are scaffolding. Deliverables are evidence. The program advances when decisions close, not when the calendar turns. The cost of reopening a decision rises super-linearly across the sequence, and the difference between a program that ships and one that dies in the valley is almost always traceable to decisions that should have closed two phases earlier and did not.
Related reading
- From Prototype to Production
- Why Hardware MVPs Fail (And What to Build Instead)
- EVT, DVT, PVT: What Each Gate Actually Decides
- Why Hardware Projects Overrun by 12+ Months
- How to Launch a Hardware Product
- Embedded Systems Development
- Ad-Hoc CTO for Hardware
Starting a hardware program — or midway through one and unsure which decisions are actually closed?
We work as ad-hoc CTO and senior product team on exactly this kind of program. Every engagement starts with a fixed-scope definition phase — no open-ended billing, no ambiguous timelines.
Start a Conversation