The MVP problem in hardware: what 'minimum viable' means when your product flies to orbit

The Lean Startup definition assumes you can iterate — hardware often can't

Per the course, the standard definition — drawn from Eric Ries' Lean Startup methodology — is that a minimum viable product is a version of a product with just enough features that early customers can use it and give feedback. The point isn't the product itself; it's using that feedback to test whether the underlying business idea is viable, meaning profitable.

The unstated assumption behind most MVP advice is that you can cheaply put out a version, observe, and put out a revised version days or weeks later. That's true for a SaaS dashboard. It is not true for a satellite bus, a propulsion system, or a payload instrument that has to survive launch loads, thermal vacuum and radiation, and then can't be retrieved and revised. Per the course, hardware MVPs run into capital and lead-time constraints — tooling choices like injection-moulding versus rapid prototyping, mould-material trade-offs, component procurement lead times — that a software team never has to think about.

Not every "product" carries the same MVP risk

The course's MVP module, taught by Danny of Verhaert, distinguishes three product formats, each with a genuinely different risk profile in terms of capital required and time to build: pure hardware, pure software, and IoT or hybrid products that combine both. Its own examples are useful precisely because they're all space-adjacent:

• Earth Automations — an autonomous agricultural robot with a precise GNSS receiver for position tracking, AI-assisted path routing, and a stereo camera and lidar for object detection; a hardware-heavy product with real lead times on every component
• Spottitt — a UK startup that runs analytics on Copernicus Earth-imagery data to detect water leaks for utility operators and to site wind-energy installations; effectively pure software layered on existing satellite data, with none of the physical build risk
• Packwise — a German IoT startup whose tags combine position, temperature and shock sensors to track logistics conditions, including the careful handling that satellite shipments themselves require

Know which format you actually are before borrowing MVP advice from a software blog — the "ship fast, iterate" assumption applies cleanly only to the software end of that spectrum.

"Minimum viable" does not mean "stripped down"

The course is blunt about a common misreading: if your MVP is 99% of a product but is missing a steering wheel or tires, it isn't a car — it isn't a product at all. A hardware MVP has to be fully functional in a basic form, not a partial, feature-limited version. The three-part test it uses is whether a product is feasible (does the technology actually work), viable (can it be sold profitably) and desirable (do people actually want to use it) — illustrated with a deliberately silly patented "toilet snorkel" pitch that is feasible and arguably viable but nowhere near desirable.

The more sobering version of the same lesson is Juicero: a US startup that raised $120 million in venture capital for an appliance that dispensed pre-packaged juice pouches. The company folded 17 months after launch once users discovered that squeezing the same pouch by hand worked just as well as the $400 machine. The technology worked. The unit economics could plausibly have worked. It simply wasn't desirable — and for a hardware company, finding that out after committing to a physical build is a far more expensive mistake than it is for a software team.

Case study: from a satellite's attitude-control algorithm to a €10,000 marine sensor

The course's clearest hardware MVP story is Wavemapper, built by the startup Innovation4C. Its origin is Proba-1, ESA's first small satellite: a technology-demonstration mission under a cubic metre in size — roughly a washing machine — flown on a total budget under $15 million including launch, orbiting at around 600 kilometres, built specifically to test whether a small, cheap satellite could still deliver useful Earth observation. Arguably, Proba-1 is itself a good model of hardware MVP thinking at the mission level: a deliberately minimal, technology-demonstration spacecraft built to test one core assumption cheaply before anyone committed to a bigger programme.

Innovation4C took the predictive attitude-and-orbit-control algorithms developed for Proba-1's camera-pointing system and repurposed them into an industrial motion sensor that measures a vessel's six degrees of freedom in real time. The target use case: correcting the readings of echosounders used to survey waterway depth around ports, where sand build-up requires regular dredging and post-dredging surveys. The team built portable and fixed, waterproofed versions with roughly 1-degree accuracy, priced around €10,000–15,000 — against competitors offering roughly 10x the accuracy at roughly 10x the price. It took 19 months and more than 60 interviews with surveyors, dredging operators and even competing equipment manufacturers. The first 25 units were hand-built in a garage, and the product launched through an online PDF order form — unusual for business-to-business sales two decades ago — selling 50 units globally within a month.

The real MVP lesson wasn't in the hardware's accuracy. Feedback after those first sales revealed that the intended customer — operators of high-accuracy, expensive multibeam echosounders — wasn't the actual market. The real fit was with operators of cheaper singlebeam echosounders, who needed something portable and "good enough," not maximally accurate. The MVP didn't get iterated by rebuilding the sensor five times; it got iterated by discovering who it was actually for.

Where the iteration actually happens, if not in the hardware itself

The course's de-risking principle is to test what you're least sure about, not what you already know — deliberately counter-intuitive, since working inside your comfort zone feels like progress even when it teaches you nothing new. It separates two testing modes: formative testing, which checks whether a shape, feature or interface clears a minimum bar, and summative testing, which checks whether the complete proposition is viable given a startup's limited resources.

Underneath that is a set of three distinct "willingness" questions, each answerable without a finished flight unit: willingness to adopt or use (mock-ups, wireframes, interviews probing resistance), willingness to buy (beta comparisons against competitor products, or "impersonator" tests — a fake landing page or trade-fair booth for a product that doesn't exist yet, just to gauge reaction), and willingness to pay (pre-orders through a crowdfunding-style platform, or simply probing price tolerance directly). None of these require a physical unit to have shipped, let alone flown.

This lines up with a broader shift the course's scale-up session describes across the space industry: better simulation capability is enabling a trend toward deregulation, because far more validation can now happen before anyone commits to expensive tooling or a physical prototype. The practical translation for a hardware space startup is that the actual MVP loop mostly runs through interviews, mock-ups, letters of intent and pre-orders on the ground — not through shipping and re-shipping physical revisions. The physical build happens once you've de-risked as much of "will anyone want this, and will they pay for it" as you can without it.

Empathise and define before you touch hardware

The course's Concept and Design module, taught by Maria Gross, frames product discovery as a five-step process — empathise, define, ideate, prototype, test, often visualised as a "double diamond" of discover, define, develop, deliver. The first two steps are the cheapest and fastest, and per the course they matter more, not less, for hardware, because every subsequent hardware round is expensive relative to a wireframe round.

The course's own space example is High Impulse, a German startup aiming to serve the fast-growing small-satellite market. The founders didn't set out to build a green hybrid propulsion technology — they arrived there only after talking to partners, potential clients, users and investors, and discovering that was the real, validated problem. It's a direct illustration of defining the problem before committing to a build, rather than falling in love with an initial solution.

On testing specifically, the course cites research suggesting that five users per round is a practical sweet spot: the first user surfaces most of the useful insight, and by the fifth, additional users mostly repeat what's already been learned. The recommended pattern is rounds of five, with a redesign between each round — cheap to run for a wireframe, and valuable to know before committing to expensive tooling for a hardware unit.

Toqua and the four kinds of resistance a hardware MVP still has to survive

Toqua, a Belgian startup incubated at an ESA Business Incubation Centre, is building an AI-driven "ship kernel" that combines engine telemetry (RPM, load) with externally sensed conditions, including Copernicus-derived data like sea-water salinity, which affects a vessel's buoyancy and therefore its fuel consumption. The market's bar, per the course, is roughly 90% overall model accuracy for the product to be considered viable at all.

Building that MVP, Toqua ran into four types of resistance the course names explicitly: usage resistance (a habit conflict — an engine operator who trusts a human ear over a sensor reading), value resistance (doubt that the promised price-performance can really be delivered), risk resistance (uncertainty about consequences, updates or regulatory compliance), and social resistance (a psychological reaction, individual or group). A hardware MVP can be technically flawless on the feasibility test and still fail on any one of these four — and because hardware can't be cheaply patched after the fact, mapping this resistance has to happen through direct stakeholder relationships before the build, not after it ships.

What to change about your build process for a hardware MVP

1. Do the cheap validation first. Interviews, mock-ups, impersonator landing pages, letters of intent — resolve as much "will they adopt, buy, and pay for this" uncertainty as possible before committing capital to tooling or a physical build.
2. Design for "good enough and complete," not "stripped down." A partial hardware demo reads as unfinished, not minimally viable — the car-without-a-steering-wheel test applies.
3. Know what's core versus augmented before you build. Per the course, a product like IoT Base Plate treats the physical hardware as the core and the digital layer as an extension, while a product like CEFALY treats the app experience as the core and the wearable as the extension. Know which one your product is, so effort goes into the right layer first.
4. Test your business model against your actual buyer. The course cites ATMOSYS, which had to abandon a pay-per-use software model for an old-school consultancy and service model, because its municipal customers don't buy on a pay-as-you-go basis. Institutional buyers often need a different commercial model than the one a founder's MVP originally assumed.
5. Fold a real sales process into the build itself. Arrange meetings and gather letters of intent or pre-orders alongside the technical build, the way Innovation4C sold Wavemapper through an online order form before its channel or customer segment was even fully proven. Once you can tell this story with evidence, our companion piece on pitching a space venture to investors covers how to fold it into what investors want to hear.

FAQ

Sources