Validate the product

Product validation investigates whether a proposed solution helps a specific user achieve the intended outcome. It can begin with a sketch, prototype or manually delivered service, before a finished product exists.

Choose a method above for the uncertainty that matters now. A usable interaction, a useful outcome and a reliable service are related questions, but one successful task does not establish demand, payment or a viable business.

Choose a product-validation method

Use the simplest representation that can answer the question, rather than the cheapest one regardless of its limitations. Prototype explains how to choose fidelity and what different prototypes can demonstrate.

Define a task and observe it

Nielsen Norman Group’s usability-testing guide describes observing relevant participants attempting tasks. Give enough context to make the task meaningful without instructing people which controls to use.

Record completion, difficulties, assistance and consequences. If you coach someone through a confusing screen, keep the assistance in the record; it is not equivalent to unassisted success. Qualitative sessions can expose problems without estimating a population success rate.

Product validation example: using a stock report

This example is hypothetical and contains no real test results. A team proposes a stock-report service for independent shops. The customer needs to decide what to order, not merely admire a report.

The drawing is a simplified task sequence. A useful session might ask an eligible owner to decide what needs ordering for the next trading period using a sample report. Observe whether the information supports the decision, where it is misunderstood and what other information is needed. Check the input-data step separately if it is an important source of difficulty.

Even if the owner can complete the task, you still need evidence about whether the report fits the real workflow, produces useful outcomes over time and can be delivered reliably. Use a clearly described pilot when real service use is the next uncertainty; explain any manual operations and protect customer data.

Product validation is not the same as QA

QA and technical verification check requirements, reliability and defects. Customer-facing validation examines usefulness in context. A feature can meet its specification while solving the wrong problem; a promising prototype can still lack the safeguards required for release.

Do not replace necessary engineering checks with user enthusiasm. Conversely, do not assume that passing an automated test establishes that people can use or benefit from the product.

Decide what the evidence supports

Before testing, write the assumption, audience, method, observations and decision criterion. Afterward, separate what happened from possible explanations, document missing evidence and assign a next action. The Experiment Sheet helps make that plan explicit.

Investigate the problem when the need itself is unclear, the market when reaching buyers is uncertain, and willingness to pay when you need a purchase decision. Product Experimentation connects these investigations; the Validation Patterns overview helps you select the next method.