Software product managers get to be wrong cheaply. Ship it, watch the funnel, roll it back by Friday. A bad decision may cost a sprint, perhaps a quarter.
Hardware offers no such mercy. Tooling gets cut. Inventory gets ordered. A contract manufacturer books the line. A decision made in a planning meeting can become a warehouse filled with millions of dollars’ worth of unusable tools and unsellable stock.
In hardware, being wrong ends in a write-off. In software, it may require little more than a rollback and a revised schedule.
But the boundary between those two worlds is beginning to blur for modern day hardware devices. These enter a new class of products: Tangibles – connected products such as the smartwatch, thermostat, city car, and coffee machine, which are physical objects augmented by a layered software stack.
Digital interfaces, connectivity, over-the-air updates, services, and intelligence allow manufacturers to observe how products are used, change their behavior after release, and sometimes turn them into something materially different months after they leave the factory.
That is the opportunity, and most teams waste it, treating the software stack as a bunch of features to ship, rather than as a way to de-risk every decision that comes before shipment. They do use software to improve the product after launch, but not to make better commitments before the factory locks them in.
So here is the operating principle, and the method that follows from it:
Learn early. Commit late.
The cost of being wrong is a curve, not a number
Picture your product timeline as a cost-of-error curve.
This cost gradient is not unique to hardware. When Geoffrey Moore, author of Crossing the Chasm, read an early draft of this argument, he suggested that the deeper divide lies partly between consumer and enterprise. “Consumer software with its Minimal Viable Products fits the pattern you call out precisely,” he observed, whereas enterprise software still involves “longer release cycles, hard to unwind, little permission to iterate.”
Hardware simply occupies the far end of that spectrum - the domain where reversing a decision is slowest, hardest, and most expensive.
Under deadline pressure, teams often feel an irresistible urge to move toward that expensive end of the curve. “Let’s get it into tooling so we feel like we’re shipping.” But that instinct is exactly backwards. The hardware product manager’s job is to extract as much learning as possible while the curve is still flat, and to postpone every irreversible commitment until the last responsible moment.
This does not mean moving slowly. It means moving the cheap parts quickly and holding back the expensive ones. That is one of the practical dividends of building a tangible: software moves part of the bet off the curve altogether. What lives in software can be decided late. Only what lives in atoms must be decided early.
Better Place is the cautionary tale I keep returning to. Its proposition – swappable EV batteries, with the car sold separately from the energy – was genuinely visionary. But the company committed to the most capital-intensive and irreversible version of that vision before validating a cheaper one. It built physical swap stations and bespoke vehicles, sank close to a billion dollars into atoms, and went bankrupt before the market caught up.
Better Place (fatally) committed early and learned late that the idea may have been early.
Disciplined connected-hardware teams do the opposite. Again and again, they separate what they need to learn from what they need to build.
—
The decoupled MVP
A tangible is what makes the Decoupled MVP possible. Because the product will continue learning after it ships, you no longer have to answer every question before you build.
Many hardware teams assume that a minimum viable product must be a minimum viable unit: a manufactured device, assembled and placed in a tester’s hands.
Sometimes it must.
Usually, not yet.
A Decoupled MVP separates the question you need to answer from the artifact you assume you need to build. Then it answers that question with the cheapest artifact capable of producing a trustworthy result.
Run it in three passes.
First, identify the riskiest assumption, not the most exciting feature. Every hardware program rests on a stack of bets: that the problem is worth solving, that customers will pay your price, that they will use the product as you imagine, that the physics works, that you can manufacture it at the target cost.
List those bets. Rank them by a single question:
“If this assumption is wrong, how dead are we?”
The answer at the top of the list determines your next experiment. It is almost never the feature your team is most eager to build.
Second, find the lightest artifact that resolves that bet. Demand and willingness to pay rarely require a working product. They require a convincing representation of the value and a real commitment from the customer. That artifact might be a concierge service delivering the outcome manually, a non-functional mock-up testing whether people even understand the concept, or a connected pilot in which the “AI” is simply a human behind the curtain.
The two AI hardware disappointments of 2024, Humane AI Pin and Rabbit R1, illustrate the danger. Both companies manufactured and shipped finished devices before validating the central assumption: that the interaction model actually worked in a customer’s hand. The hardware was complete. The learning had barely begun.
Third, commit only the layer you have earned. Hardware naturally stages commitment: paper, prototype, soft tooling, hard tooling, production. Each stage costs more, takes longer, and becomes harder to reverse. Progress to the next stage only when the evidence justifies it, not because the calendar demands it.
The companies that master this discipline are not slower. SharkNinja is a good example. It runs dozens of inexpensive experiments before cutting production tooling, allowing weak ideas to fail while failure is still cheap. By the time steel is cut, most of the uncertainty has already disappeared.
—
Where software changes the economics
This is where the software layer earns its keep.
A connected product gives you two capabilities that conventional hardware never had. It tells you how customers actually use the product, and it allows you to improve that product after it leaves the factory.
Use the first before making irreversible commitments. Even a small connected pilot converts assumptions into measured behavior while changes remain inexpensive. You discover which features people use, which they ignore, where they struggle, and what they are willing to pay for. That data becomes your validation engine, not merely your post-launch analytics.
Exploit the second by keeping decisions in software whenever physics allows. Every behavior that can be implemented in firmware or the cloud is one less decision that must be frozen into steel. Software lets you make those decisions later, with evidence instead of prediction.
That is the essence of the strategy: push irreversibility out of the atoms and into the bits wherever possible.
Geoffrey Moore made the same observation from another angle. Because modern hardware inherently contains software, that software becomes “where there is some freedom to adjust to a niche market’s unique requirements,” as companies such as Tandem and Sun Microsystems did for specialized enterprise markets.
The software layer is what allows a physical product to adapt to its beachhead market without rebuilding the hardware.
—
What to do Monday
You do not need to reorganize your company to start.
Take the next hardware decision on your roadmap and ask three questions.
- What is the riskiest assumption beneath this commitment?
- What is the cheapest artifact that would test it?
- What is the latest responsible moment to make the irreversible commitment?
If you can answer those honestly, you are already practicing the discipline of Learn Early, Commit Late.
The connected nature of your product is not merely something to market after launch. Properly used, it changes when you have to decide.
It lets a hardware team be wrong while mistakes are still inexpensive.
But only if you spend the learning before you spend the steel.
