Engineering Validation Passed. Is the Product Ready to Launch?
A passed test is not a launch decision
“Getting a product through development isn't the same as it being ready to launch.” That warning, from a recent NPI leadership post, captures a costly distinction: teams often treat a completed design and a passed validation plan as proof that the business is ready to sell and deliver the product.
The gap between “works” and “ready”
Product programs create momentum around visible milestones: design freeze, prototype completion, verification, tooling, first article, launch date. Each milestone can be real and still leave the central business question unanswered: can we deliver the intended value, at the expected cost and quality, to the customers who will pay for it?
The gap persists because “ready” is rarely defined across functions. Engineering may mean the design passes its tests. Operations may mean the line can meet takt and yield targets. Sales may mean a launch date is on the calendar. Finance may mean the business case still clears the hurdle rate. Customer support may not yet know what failures to expect or what parts to stock.
When each group uses a different definition, a green status report can conceal an unready system.
Root cause: the test plan inherits the assumption
A validation plan is built from requirements. If the requirements omit an important market, production, or use condition, the tests can be executed perfectly and still provide incomplete evidence.
This is not an argument against verification. It is a reminder that verification answers, “Did we build the defined product?” It does not automatically answer, “Did we define the right product and the right conditions for a viable launch?”
One public example came from a product program where customers liked the performance of a sophisticated water analyzer. The team later realized the intended treatment plants did not need the measurement at the point the product was designed to serve. The program had spent more than $1.1 million, then stopped before a forecast additional $1.9 million was committed.
Core Insight: A test can confirm the answer to a question the market never needed answered.
Root cause: the business case goes stale
A business case is a set of assumptions, not a permanent approval. Market access, expected volume, target price, material costs, tooling, yield, and service burden can all change while the design moves forward.
Yet many programs preserve the original case in a slide deck while the working decisions drift away from it. A cost reduction may lower performance. A supplier change may lengthen lead time. A feature may require new certification or support capability. Each decision can look sensible on its own while the combined effect erodes margin or changes what the customer receives.
The useful question at a gate is not only “Are we on plan?” It is “Does the current plan still produce the economics and customer outcome that justified the investment?” If the answer is unknown, the gate should surface the uncertainty rather than disguise it with a milestone color.
Core Insight: A business case that is not refreshed becomes a record of what the team once believed.
Root cause: production readiness is inferred from a successful build
A working prototype proves that a team can make a unit work. It does not prove that a production system can make the unit repeatedly, at planned volume, with controlled variation and realistic labor content.
A recent public account from a contract manufacturer described stopping a customer-requested product review after three days. The downstream buyer had not been asked whether they would pay for the finished product, and the performance claim anchoring the concept lacked an industry benchmark. The author said the stop preserved $75,000 in tooling and production capacity for other work.
Core Insight: A production plan is not validated by the prototype that preceded it.
The real cost is accumulated commitment
There is no single reliable cost multiplier that applies to every late product problem. The impact depends on what has already been committed: engineering hours, tooling, supplier capacity, certification, inventory, launch spending, customer promises, and the opportunity cost of the team.
The public cases above show two different forms of exposure. In one, the decision avoided a further $1.9 million forecast spend after more than $1.1 million had already gone into development. In the other, the reported early stop protected $75,000 in tooling and capacity. Neither number is an industry benchmark; both illustrate why teams should make assumptions testable before irreversible commitments accumulate.
Late discovery also consumes time in less visible ways: reprioritized engineers, supplier negotiations, schedule recovery, customer communication, rework, and leadership attention. A launch can happen on the planned date while the product economics or delivery system quietly fail.
The fix: make readiness an evidence gate
Sarga II’s diagnostic approach starts by separating readiness into claims the team can actually test. The precise checklist varies by product, but a useful review covers four questions:
Customer and commercial: Have the intended users and buyers confirmed the problem, buying criteria, target price, and path to purchase with evidence stronger than positive feedback?
Technical: Does the product meet the requirements under representative use conditions, including important edge cases and interfaces?
Manufacturing and supply: Has a production-representative build demonstrated repeatable output, acceptable yield, realistic cycle time, capable suppliers, and a feasible ramp?
Business and support: Does the updated business case still work, and are service, spares, training, installation, and escalation responsibilities in place?
For each claim, record the evidence, the remaining uncertainty, the owner, and the decision it affects. A statement such as “manufacturing is ready” is too broad to act on. “The pilot run met the agreed yield threshold across three shifts, with the target supplier and released work instructions” is a claim that can be checked.
Then revisit the evidence at meaningful commitment points: before tooling, before production release, before broad customer shipment, and after initial field use. A gate should not be a ceremony for confirming that work happened. It should be a decision about whether the next investment is still justified.
Case pattern: the calendar says go
Imagine an industrial equipment team has a product that passes bench testing. A launch date has been shared with customers. The first production run, however, uses a different supplier and a new assembly sequence. Sales has not confirmed that the buying group accepts the final configuration at the target price. Service has not received a failure-analysis plan or spare-parts list.
No single team has necessarily made a bad decision. Engineering completed the agreed tests. Procurement secured supply. The project team protected the date. The failure is in the system: no one required those separate conditions to be true at the same time before calling the product launch-ready.
This is a case pattern, not a report of a specific customer engagement. Its purpose is to make the missing evidence visible. If the team can name the assumptions before launch, it can decide whether to test, mitigate, change scope, or stop.
What good looks like after the gate
A ready product has more than a technically successful design. The customer and buyer evidence is current. The economics reflect the design and production route that will actually ship. The factory has demonstrated the process under representative conditions. Supply risks have owners and contingencies. Service and quality teams know how to detect, route, and resolve early field issues.
Most importantly, the decision is explicit. Leaders can see what is proven, what remains uncertain, and what they are authorizing by proceeding. A launch date is then the consequence of readiness, not a substitute for it.
If the date is green but the evidence is not
The practical test is simple: can every function explain what “ready” means in evidence, not just in status language?
If the answer is no, the next move is not another dashboard. It is a focused readiness review that tests the commercial, technical, production, and support assumptions before the next irreversible commitment.
Comments