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.

Who do you know that would benefit from reading this? Share it with them now.

And if you want early access to these articles, come on over to https://docondev.substack.com/ where I’ll be publishing articles a month or two ahead of other platforms.