To validate is to confirm something has the quality of being well-grounded or correct. Validate before, during, and after is a reminder that teams should be confirming along the way.
Validate Before — Is it needed?
At the onset, there is a problem we wish to solve. Before we dive too deeply into possible solutions, how might we validate the problem? Are there unchecked assumptions that underly our current understanding of the problem? Do we know how many people this actually affects? Do we know how people are addressing this problem today? Do we know how many other organizations are actively working on solutions to this problem? Here we seek to validate the need. It doesn’t have to be comprehensive, but it should be enough to substantiate the undertaking — is this really a problem and it is worth our effort to try to solve it?
Validate During — It is doing what we expect?
Once we’ve determined there is an actual need, it is worth our effort, and it is our top priority, we move into cycles of design and development. Here, we have ideas of how the solution should behave. We want to validate this behavior as we go. Is the solution doing what we intend? Does it have any side-effects? Validating the behavior as we go allows us to confirm we are on the intended path and reduces the likelihood of releasing buggy solutions.
Validate After — It is actually useful?
Now we have some increment we believe to be of value — something that we can put in front of users in a production environment and see how they respond. We want to validate that value. Are people engaging with it? Is it an improvement over their existing solution? Are they returning to use it again? Is it performing well enough? Is it continuing to add value over time?
Conclusion
Validating the need helps you stay focused on the most valuable and impactful problems. Validating the behavior helps you ensure you are on track and creates a safety net for future changes. Validating the value helps you make informed decisions about which solutions to keep, which to alter, and which to remove.
In future articles, we will cover tools and techniques to aid in validating before, during, and after.
If you want to keep up on the progress of the Behaviors Book, pay attention to the Behaviors Book page. And if you would like to learn more about how we use The Behaviors to guide teams, reach out.
In this article, I want to go more in depth on Opportunity Solution Trees; what they are, how they are used, how to create one, and how I think about them slightly differently (but only slightly) than folks like Teresa Torres who really introduced them broadly to the Product community in her book “Continuous Discovery Habits”. This book, by the way, is a must have for anyone who works in software product development - not just folks in product-specific roles.