What did we build?

What did we build? Thinking about if the product is right.

I like to imagine three ways to think about how we evaluate a product.

Did we build the right product?

This is about whether or not we built something the customer, user, market, business wants and needs. Will people use it happily, or will they disregard it? Will they come back to us for more business, or will they go somewhere else? The only way to know for certain if you have built the right product is to get feedback from the people who need it and are going to use it. You can ask other people, and their feedback may be useful, but all they can provide is a guess.

Did we build the product right?

This is about whether or not we built what we intended to. We have some idea of what we want the product to do, what requirements it must meet. We create that, and then we check if it does indeed do what we want, if it does indeed meet the requirements as we understand them. All sorts of members of the team, even the customer, can help answer this question, but the first and earliest and usually fastest and best way to answer this question is if the people making the product, the developers, ask and answer this question. The developer should use tools and methods that help them answer this question, even guide them to more easily make the product right.

Did we make a mistake?

Sometimes we make mistakes, even when we know the product is the right product, and we know we have built it to do everything we intended, we still make a mistake that might cause a serious problem. We don’t know what those mistakes are, because if we did we wouldn’t have made them. We rarely anticipate them, we rarely address them in requirements, or understand them as something we might even do. Our customers do not want, and should not be the ones that find these mistakes. Frequently finding and describing these mistakes require skills that exceed those of the customer. The mistakes often cause the customer harm or lost money and time, so they do not want to find our mistakes for us. Our developers can find many of these mistakes, especially if they are good at testing techniques that go beyond checking off items on a requirement list. But finding these mistakes sometimes requires time and focus unavailable to a developer that is busy designing and building the next necessary change to the system. We find more of these mistakes when we can dedicate somebody’s time and focus on doing so. This is usually the job of a tester.