From risk to rigor: an MVP that passed the lab and failed the field
What happens when electrical and thermal safety constraints are treated as downstream checks rather than first-order product requirements, and a customer commitment already depends on the answer.
What “too late” can look like
An accelerator-backed ClimateTech startup had built an MVP, passed lab testing, and secured a facility operator willing to host a pilot installation. The team was small, under ten people, and moving quickly toward first deployment.
They had done what early-stage hardware teams are told to do: build fast, validate quickly, line up a pilot. The pilot was the proof point the next funding conversation depended on.
Electrical and thermal safety constraints were treated as downstream checks rather than as first-order product requirements. The MVP was built around assumptions that held under controlled lab conditions and did not hold under real electrical and thermal loads in a working facility.
Underneath that, the MVP simulated a solution rather than proving the core physics and the safety envelope. There was no structured way to translate facility operating constraints into design decisions, so the constraints were never stated as requirements and never tied to test evidence.
Immediately before deployment, after the design was set and a customer had already committed to the pilot.
The failure modes themselves were not exotic. They were ordinary electrical and thermal behaviour under real load. What made them invisible was that nothing in the development process required anyone to state them as requirements and check them.
The work shifted from fixing the prototype to defining the constraint the prototype had to satisfy.
- Isolate the root constraints. The electrical and thermal conditions that caused the field failure were separated from the surrounding noise and stated explicitly.
- Rebuild the MVP strategy around them. Those constraints were solved first, before any further commitment to form factor or feature scope.
- Build a validation framework. Performance targets, safety tolerances and test checkpoints were mapped directly to facility-level operating conditions rather than to lab conditions.
- Deliver a lean, testable proof of concept. Enough to iterate against evidence, and to give the team a credible path back to pilot readiness.
The customer withdrew from the pilot. The team lost its deployment slot, momentum stalled, and credibility had to be rebuilt before facility operators could be re-engaged.
From there the recovery was fast. The electrical and thermal failure modes were isolated and reframed in about two weeks. A functional proof of concept followed in about two months, together with a validation path the team could take back to an operator and defend.
Passing a lab test is not the same as being ready for a customer environment. When electrical, thermal and safety constraints are not treated as core product requirements, an MVP looks viable right up until real-world exposure, which is the point at which trust is hardest to recover.
Structured design-risk analysis would have forced those failure modes to be stated as requirements, challenged against real facility operating conditions, and tied to specific validation evidence before a customer commitment depended on them.
Which of your assumptions have been tested, and which have only been passed?
A test that a product passes under convenient conditions and a test that proves the product survives its real environment look the same in a status report. They stop looking the same the first time a customer runs it.
In 30 minutes we can work through where your product sits, what commitment comes next, and whether your current validation evidence actually addresses the failure modes that matter. If it does, you will hear that. If there is a gap worth closing first, you will know what it is.