Frequently Asked Question

Close the lifecycle by feeding field performance, service data, nonconformances, customer feedback, and supplier learning into the next design cycle. Separate symptoms from verified causes and confirm corrective-action effectiveness.

Product retirement should address remaining obligations, spares, service information, records retention, and communication to affected users.

Traceable product-development method

Product-development work should connect the customer need to a measurable requirement, design output, manufacturing control, and objective evidence. For Lessons Learned, Field Feedback, and Product Retirement, define the function, stakeholders, inputs, constraints, failure risks, verification or validation method, acceptance criterion, and accountable owner. Keep assumptions and unresolved risks visible instead of hiding them in status language.

This is a prioritization aid, not a physical law. Use the project’s approved rating definitions and treat safety, regulatory, and single-point risks explicitly.

Worked example

If a seal requirement is leakage below 1.0 mL/min, the evidence plan should identify the production-intent seal, pressure and temperature cycle, measurement resolution, sample size, acceptance rule, and disposition for an outlier. “Tested” is incomplete without those details. A design change that alters the seal interface should trigger impact review of requirements, DFMEA, verification, PFMEA, and control plans.

Gate discipline: make the reviewed configuration, decision, open action, owner, due date, and residual risk explicit.

Engineering check

For Lessons Learned, Field Feedback, and Product Retirement, maintain traceability from requirement to risk, design output, evidence, and approval. Record the configuration, acceptance criterion, test or analysis conditions, open actions, and residual risk. A method is not complete when the document is filled in; it is complete when the evidence supports the decision and affected controls are updated.