Verification and validation strategy

In plain language

Verification and validation are two of the most important disciplines in medtech because they answer two different questions. Verification asks whether the product was built correctly according to requirements. Validation asks whether the product actually solves the intended problem for real users in the real environment. Both matter. A product can be carefully built and still be the wrong solution. It can also solve the right problem while being too fragile to trust.

For non-technical founders, the practical takeaway is simple: good demos are not enough. A polished prototype may show that a workflow is promising, but that does not prove the underlying system is reliable, testable, or ready for broader use. Verification and validation are what turn confidence into evidence.

What this page helps you decide

This page helps learners separate confidence from evidence. Verification checks whether the product was built correctly against requirements. Validation checks whether the product is suitable for the intended users, use conditions, and workflow.

Use it when a demo looks promising but the team has not yet shown what has been tested, under what conditions, against which requirement, and with what result.

Evidence by layer

Evidence is built in layers. The lowest layers check whether small pieces of the product behave correctly. The middle layers check whether components work together and support the workflow. The highest layers check whether the finished product is suitable for intended users and intended use conditions.

• Unit and component tests for implementation reliability.
• Integration and system tests for interface and workflow performance.
• Usability and validation studies for intended use evidence.

This layered approach matters because different problems appear at different levels. A unit test may catch a broken calculation. An integration test may catch a failed interface between systems. A usability or validation study may reveal that the overall workflow is confusing or unsafe even though the software itself technically works.

Evidence by stage

Early evidence can be lightweight, but it should still answer the right question for the stage. Prototype evidence answers “is this worth pursuing?” Pilot evidence answers “can this run safely in a constrained setting?” Production evidence answers “can we operate, monitor, support, and change this repeatedly?” When teams mix those stages, they often over-trust demo feedback and under-plan verification.

Why founders should care

Founders do not need to write the tests themselves, but they do need to insist that the team can explain what evidence exists and what is still missing. If the product supports a critical workflow, you should be able to ask: what has been tested, in what environment, against which requirement, and what was the outcome? Those are not overly technical questions. They are management questions about product readiness.

A strong V&V strategy also protects budget and timeline. Problems found late are usually more expensive than problems found early. A clear test strategy helps the team discover issues while they are still cheap to fix and before they become customer-facing failures or regulatory headaches.

Common failure mode

Teams over-invest in demo validation while under-investing in systematic verification, creating brittle products that fail in production workflows.

A common pattern is to spend time proving that users like the concept while skipping the less glamorous work of structured testing, traceability, and repeatable evidence collection. The result is a product that looks promising in meetings but becomes unstable or hard to defend once usage grows. In medtech, this gap is especially dangerous because confidence can outpace proof.

Concrete advice for non-technical founders

Ask your team to describe the current test strategy in plain language. What do we test automatically? What do we test manually? Which risks are covered well? Which risks are still weakly covered? What evidence would we need before using this in a more serious real-world setting? If those answers are unclear, the verification plan is likely still immature.

A good founder exercise is to take one critical workflow and map it to the evidence that supports it. What requirement defines it, what tests check it, what usability evidence supports it, and what happens if it fails? That single exercise often reveals the biggest gaps faster than reviewing a large stack of technical artifacts.