Validating product requirements

As outlined in the article Developing a new product: Creating functional and non-functional requirements, requirements are the tactical implementation of your product strategy and product roadmap.

It would be simple to take product requirements at face value once they have been completed. However, just as with your product roadmap, validation is imperative to ensure that you are using your resources (namely your development resources) wisely.

Changes during the development process are much more expensive than changes made before the process begins. Validating your requirements can eliminate costly changes in course.

Types of validation

User validation

Validating your requirements with your prospects and clients will help ensure that you correctly interpret the problem and user scenarios. Your users can help to validate the problems that you are trying to solve, as they will be most concerned with their own goals, not product features.

Tester validation

Testers can validate your requirements for completeness, and point out scenarios that you might not have considered. They tend to be very aware of current user scenarios for your product and where gaps might exist, based on their evaluation of reported bugs.

Technical validation

The engineering team can validate a solution’s technical feasibility. They can also suggest alternative ways to solve problems.

How to validate product requirements

Have a conversation with users and testers

Talk to your users and testers about the feature and related problems. Get feedback about how you’ve understood the problem, and what the solution should do for the user.
Questions could include:

  • I understood the problem to be this. What do you think?
  • How would you describe it?
  • What should the solution do to solve your problem?

Warning: The user may have a solution in mind that is different from your own; that is okay. Ensure that you understand the problem fully when validating and that the solution might vary with the ingenuity of your engineers.

Develop a prototype

You might want to develop a prototype to validate an idea. A prototype can be tangible, like a sample piece of hardware a user or tester could touch, or something less tangible like paper screenshots of the proposed solution.

Warning: Users tend to provide better feedback when the product seems less “finished” as they won’t think that you’re too invested in the outcome. So, paper screenshots can be more powerful than online tools. Keep in mind that prototyping, while powerful for usability testing, can take up a lot of time during the development process.

Further, while prototyping can provide good feedback on the usability of a design, developers might become attached to their design and users might believe that it is the final product.

Buy-in as part of the validation process

One of the by-products of the validation process is the buy-in you gain from your users and your internal teams. By validating your requirements with customers, testers and engineers before the product is built, they will feel that their opinions are being heard and they will have a greater inclination to be dedicated to the final product.

Once you have completed validating your requirements, you can be confident that your requirements are well founded and you can begin planning your product release. This will include understanding the cost of each requirement and their order of priority.

Note: For more information on product requirements, refer to the other five articles in this series:

References

Cooper, A. (1999). The Inmates are Running the Asylum. Sam’s Publishing.
Crinnion, J. (1991). Evolutionary Systems Development: A practical guide to the use of prototyping within a structured systems methodology. Plenum Press.