Hardware and Physical Products: PM Beyond Software

Software product development, across nearly every framework in this curriculum, implicitly assumes that a mistake discovered after launch can be corrected through a subsequent deployment, typically at a cost proportional to the size of the fix rather than the number of users affected. This assumption underlies concepts as varied as the A/B testing rigor from Module 5 and the migration discipline from Lesson 68 — even a large-scale software migration, however costly and disruptive, remains fundamentally a matter of coordinating a change that is still technically possible to make. Hardware development breaks this assumption at specific, identifiable points in its lifecycle. Once a product design has been committed to tooling — the expensive, custom manufacturing equipment specific to a particular design — changing that design requires re-tooling, at a cost and timeline that can run into the months and into significant capital expenditure. Once units have been manufactured and shipped to customers, a flaw that cannot be addressed through a firmware update is no longer a bug; it is a defect that exists in every physical unit already in a customer's possession, correctable only through an expensive and reputationally damaging recall or replacement program.

This lesson introduces the Commitment Curve, illustrating how the cost of reversing a hardware decision increases sharply and non-linearly as a product moves through its development stages:

The Commitment Curve's core discipline is recognizing that the appropriate level of validation rigor for any given decision should scale with proximity to these commitment points, rather than remaining constant throughout development. A design assumption that would be reasonable to test quickly and cheaply at the Concept or Prototype stage becomes an entirely different category of risk once the same assumption is embedded in a Tooling Commitment, since an error discovered after tooling has been committed can no longer be corrected through further iteration on the same design — it requires either accepting the flaw, or paying the very high cost of re-tooling. This is precisely why hardware product teams typically invest disproportionately in validation, user testing, and design review before crossing the Tooling Commitment threshold, compared to the validation rigor a software team might apply before an equivalent-seeming decision, since a software team retains the ability to iterate further even after a decision has technically shipped.

Firmware — the embedded software running on a physical device — represents one of the few mechanisms available to preserve genuine post-shipment flexibility for an otherwise fixed hardware product. A device with over-the-air (OTA) update capability can have its behavior meaningfully changed after it has already shipped to customers, correcting certain categories of flaws (a software bug in the device's control logic, a suboptimal default configuration) without requiring a physical recall, in a way directly analogous to the Layer 2 Developer Surface concept from Lesson 61 — the firmware update mechanism is, in effect, its own promise to customers about what can and cannot be corrected after purchase, and that promise should be designed deliberately rather than assumed. Critically, however, OTA update capability can only correct flaws in the firmware, not in the physical hardware itself — a defective sensor, an undersized battery, or a structurally weak physical component cannot be fixed through a software update regardless of how sophisticated the device's update mechanism is, meaning firmware flexibility, while valuable, does not eliminate the fundamental irreversibility the Commitment Curve describes for genuinely physical design decisions.

A specific and costly hardware product management mistake is applying uniform validation rigor throughout development, rather than deliberately intensifying scrutiny as a design decision approaches an irreversible commitment point. A hardware team that treats every design review with the same level of urgency, regardless of whether the decision under review is still cheaply reversible or is about to be locked in through tooling commitment, risks either wasting excessive validation effort on decisions that could be iterated on cheaply later, or, more dangerously, failing to apply sufficient scrutiny to a decision immediately preceding an expensive, irreversible commitment.