This is definitely an issue that can occur. Validation should confirm that the final device meets documented user needs and intended use, not hypothetical  scenarios. When teams start adding extra testing or features outside the original user requirements, they risk scope creep, delayed timelines, and nonessential design complexity that can introduce new failure modes or usability issues. For example, a device validated for environmental conditions far beyond what users actually experience may drive unnecessary design changes or added cost without any clinical benefit. In regulated environments, every validation activity must trace back to a specific user requirement in the Design Input/Output Traceability Matrix. If not, auditors might flag it as unneeded validation work or as evidence of an unclear design intent. They should always be tied to a clear, risk based justification within the Design History File (DHF).