Product validation is a vital aspect in software development. After a long journey of user research, problem and market validation, and most importantly development, you finally have a working product. Validating your product means getting meaningful feedbacks and using them to improve your product in the next iterations. In Agile, this is usually done on the Sprint Review meeting, where the team presents a demo of the product to the stakeholders. That said, there are other techniques you can use to validate your product. They will be explained in this article, along with their strengths and weaknesses.
In a product demo, the presenter demonstrates new features and fixes on the product to the users and stakeholders. This allows the team to get feedbacks immediately and work on them in the next sprints.
However, the users don’t get an actual experience of using the product itself, so the feedbacks may be limited. Not to mention that the users’ view of the product may be biased because they’re influenced by how the presenter demonstrates the product.
You can do direct observation by watching closely as the users use your product to perform some tasks in the target environment. Unlike product demo, in direct observation the users get to interact directly with the product, so you can learn about the users’ experience and what their behaviours are like.
The main disadvantage of direct observation is that it takes a long time to observe multiple users. There’s also the possibility of the users acting differently as they’re being watched by someone else, also called the observer effect.
Unlike direct observation which is conducted where the product will actually be used, usability test is done in a controlled environment, like a meeting room. You ask the target users to perform tasks with your product and observe how they use it. Then you perform a short interview about their impressions of the product. This technique’s advantage is that it quickly generates real user data. Like product demo, it can also be done during a sprint review meeting.
That said, users may act differently since they’re performing tasks in an artificial environment. The observer effect also applies to this technique.
Another way of validating a product is by releasing a beta version of it to gather feedbacks from a group of users. With this technique, the feedbacks gathered is not biased because the product is used by the real users in real environments. Moreover, since a large number of users are involved, the data can be more representative for the target market.
One drawback of this technique is since you don’t observe the users directly, you don’t get to learn about why they use the product or why they don’t. It also takes time because people need to install and use the product for you to be able to gather relevant data.
You can also use prototypes to validate your product. The advantages include low cost and quick data gathering.
On the downside, focusing more on how to build a product can result in an overkill prototype without making real progress on the actual product.
There is no one-size-fit-all technique to validate a product. Each method has its advantages and disadvantages, so it’s important to choose carefully according to your team’s needs. It’s recommended to switch between techniques as the development process moves forward.