Test-driven product development: concepts and approach

Building digital products is a very challenging practice, since it's built on circles of thoughts among: managers, marketers, and engineers. It becomes even more challenging when we need to validate and test our ideas and concepts through out the whole development cycle.

Testing and validation isn't necessarily restricted to the technical testing (i.e. writing test cases and run them against the product functionalities), it can be also extended to the scope of validating and testing the ideas even earlier in the cycle. Before any development has taken place.

In this article I'm trying to explain more how can we pave the product environment to be more testing-friendly environment across the different stages of product development.

What’s the point of measuring stuff we build? 

As humans, we tend to measure things around us in order to understand them better. For example: You're always measuring how fast you can get to work on foot vs. by train so that you can understand how to use your time more effectively. Our brains usually tend to measure stuff and record those measurements for the next time. Guess what? Building a digital product is absolutely no different!

While building digital product, you need to be equipped and ready to measure everything, so that you can do 2 things:

Understanding your product audience, and learning from that to make it better.

You cannot control what you cannot measure.

When dealing with digital products, complexity grows over time. And the more complexity you have, the harder it will take you to control it. So, you have to be prepared! 

Taking testing seriously from day 0 in your product environment is a win-win situation. It will help you drive your product to a valuable outcome, as you'll always be challenging the hypotheses you form with tests.

When you develop this sense of testing, you'll start to take control on the product outcomes, and you'll be able to measure different aspects of the product lifecycle, things like:

• You're going to identify which product hypotheses are more realistic (i.e. address actual problems that your target customers facing) than the others, and that's how you're going to provide more valuable outcomes.
• You're going to identify which solution can be best fit for your product hypotheses, and you're going to test that in different ways that will save you pushing invalidated concepts to your engineers. 
• You're going to test the robustness and the easiness of your product quite often and quite early, that's how you're going to drive more usable product.

If you can measure your each phase in your product lifecycle you'll find it more controllable and you'd be more confident when things become more complex.

When to test? And how these tests should look like?

In his popular book "The Lean Startup", Eric Ries stated 3 main steps that form the heart of lean startups: Learn, Build, and then Measure.

In the same fashion, while building your product, and while thinking about the different stages (i.e. user discovery, solution hypotheses, product engineering, scaling, etc.) you should keep the same structure in mind.

Start with a minimal version that address something you know about your users, and measure that version with a specified metrics.

That way, you should be always testing when you have something that real product customers can deal with (not necessaries a fully-developed version). And you will form your tests in something like:

If I did [something], for [a specified product persona/segment].
They will respond by [some output you expect],
And we can measure that by [some metric you think will be affected].

Having this approach in your mind, your way of thinking about the product will become more test-driven. And you'll be able to expect the outcome and to behave accordingly in case you found things going the wrong direction.