Introduction
According to a recent report, 56% of startups fail due to a lack of customer product validation.
According to the same report, many founders overestimate their value before validating the market by 255%.
How do we know our product has a product-market fit and our product is validated as a good solution by the users?
What is product verification, and how is it different from validation?
Who are these “users” we’re talking about anyway?
These are relevant and interrelated questions that many product managers ask, so let’s dissect them a little more.
First thing’s first, we have to understand what types of users we are working with.
Who are the users?
Let’s assume that we are going to build a new product (this applies to already establish products as well); we’ll need to know who our stakeholders are so that we can meet their expectations.
However, stakeholders of a product might differ, depending on the level of the product usage or their relationship with the product.
As product managers, we need first to define who our product’s immediate users will be. If we are going to build an internal product, we need to define the roles and their responsibilities on the product.
Once that’s done, we can address people who will be our secondary users (if they exist).
If our product is used by end-users, to specify our user group, we need to define which people from which markets and which persona will be picked.
Assuming that you will release a product for the end-users, we need to validate it with the internal stakeholders first.
Then we launch it and make our customers (end users who pay for us) happy by covering their demographics, goals, and market size details. We do this by creating personas and working over them in detail. Who can be these “stakeholders”?
You can think of stakeholders as someone who holds a stake in the success or failure of the brand. In other words, people that you need to keep happy to make your product grow further.
Different from customers, stakeholders are key partners who back your product in the market and make it grow in various ways.
If you are a startup, you might not have many stakeholders. Still, if you manage products in a corporation, you’ll most likely work with multiple stakeholders internally and third parties externally. Due to working on different jobs, each stakeholder will ask you something different from you. For example:
Executives might ask you about additional tasks that you should prioritize among the other requests, aligning with the company vision.
The finance team may ask you about payment problems, new payment gateway integrations, or accounting-related tasks.
Engineering can have requested on the technical level, asking you about prioritizing tasks and mostly questions from the requirements. Please note that we should also consider them stakeholders since you also need to think about their problems and needs. This can affect the delivery time and quality of the product tasks at the end.
The operations team might ask you to automate some processes to reduce their workload.
Sales and marketing can approach you with tasks related to sales metrics, funnel issues, optimization requests.
Please keep in mind that, aside from working with internal stakeholders, we also might have external stakeholders too.
These external stakeholders can be on both the business and non-business end that we need to work with. Similar rules also apply by their role, as we just discussed, satisfying their needs to keep the product up, running, and growing.
Briefly, stakeholders are the closest “customers” to us who would like to make our product worthy, where customers would like to enjoy and want to see their problems resolved effortlessly.
Difference between validation and verification
So far, we have looked at who our users are and who are the stakeholders of the company.
We also stated that there is a need to verify our product and validate it to ensure that we are doing well in regards to our KPI’s.
Most of the time, the terms validation and verification are confused for each other by many. Validation and verification are two activities that assess how a system has been built. Let's elaborate on both validation and verification in detail.
What is Verification?
Verification is simply the confirmation that system requirements have been satisfied.
What is Validation?
Validation means confirmation of whether the system is built right. It is the confirmation of whether user needs are satisfied. Please note that validation can be done before deployment. However, we can only validate afterward. Let's see this comparison in detail. It might take quite a while to cover both validation and verification in the same article, so let us continue focusing on validation and how we can apply it to our product.
To continue, it’s important to understand the concept of Lean and the core values that IT implies.
Lean approach to product validation
Once you’ve passed all of the steps, you can be confident that your product idea is worth developing.
Validate the problem: Is the problem we decided to solve worth spending our time and money on? If users do not have experience with the problem, the solution that you’re providing will not be relevant for them.
For this reason, we need to verify whether the problem really exists for users. This can be done through interviews with a small group of (potential) stakeholders.
Is it worth the effort to try and solve the problem? If users don’t think this is a big problem, your solution won’t be appealing.
Firstly, we start with a small number of properly sampled, representative users and verify that the problem exists for them.
Finding at least five people who say they would be keen to use your hypothetical product is a sensible indication that you have a problem worth solving. Ideally, we should interview face-to-face to take their reactions into an account.
Obviously, the more we collect information, the more we can validate the problem.
Yet, we also need to think about optimizing and verifying this later on with more users and at a greater scale, without forgetting the user’s ethnography and market conditions as we mentioned in the user part above.
Validate the market: After speaking with users and confirming the problem, you need to make sure the market is large enough to take further steps.
Where will your users come from, and how much potential revenue lies in the market opportunity?
Depending on the expected revenue from your product, you need to set up your market expectations.
Whatever you’re building, you should make sure that a huge market is there. If you are planning on creating your own market, be sure that you are following the trends, deeply researching your potential future competitors, and finding out more about their extent to plan your strategy.
After knowing that the problem might exist, we need to understand whether the product is really solving the problem.
And there’s only one way to come to this stage: building a prototype and sharing it with users.
Don’t worry about having a ‘perfect prototype.’ There is no need for technical expertise or being an engineer to build a necessary prototype. Things must be kept “Lean.” Even wireframes on paper would be sufficient to have your stakeholders realize what your product looks like and how the process flows.
Validate willingness to pay: We might have a good product demanded by the market, but how can we make sure that the product is good enough? The answer depends on users’ willingness to pay for the product.
The first step can be creating a working landing page.
Then you’ll need to drive traffic and check the metrics from various tools to make sure that it is working.
Be a little cautious about doing this within your network of friends and family because their ideas might be falsely positive. Check the metrics from a variety of different tools to ensure that it is working.
Evaluation of the product validation steps in detail
Stakeholder Validation
Depending on needs and products, organizations might differ in terms of the phases mentioned above. However, a stakeholder validation plan, at a very basic level, can be summarized in the following bullet points:
Goal and Objectives of the requirements that we would like to satisfy in this iteration.
Roles and Responsibilities of the stakeholders or the people involved with the validation, indicating who will be checking what and its limits.
List of project deliverables that require validation with their agile stories to indicate an appropriate set of expectations, the natural cause, and the reason for the request.
Plan for the next iteration to see the next plan in advance, just in case something needs to be changed due to the validation results. KPI metrics and SLA restrictions for the tasks to be satisfied at the end of the validation.
Rules and restrictions need to be followed, as forced by the government or contracted 3rd parties.
Customer Validation
We need to observe our customer behavior by observing their metrics on the main steps to make a product valid in the market. We do this so that we can see which steps are being problematic.
Let’s consider how our six great ideas shown above fare when we put them through the Lean validation process:
Sometimes ideas fail at the first hurdle because we can’t validate the problem. Either that or they fail due to the product/solution that we are developing not solving the problem.
Sometimes ideas validate the problem or solve the problem but can’t establish a market. This might be because the market was wrong or the targeted persona was wrong.
In some ways, we successfully solve the problem and reach the market with a product that looks acceptable, but people may not be willing to pay for it.
In such instances, we need to twist the product; pivoting, and converting it to a slightly different product with different ideas or targets.
With some small touches, we see that our 4th idea has also convinced the users to pay for the product (preferably recurrently), reaching our goal. Hence, we need to have a batch of ideas in our pockets, and we should explore and develop further to find the right one.
Conclusion - TL;DR
In a nutshell, product managers always solve various problems by releasing new products and maintaining existing ones.
They communicate the problems and requests of the users to the relevant units and ensure that all stakeholders are on the same page.
The number of stakeholders and customers might differ according to the product and company size, but the aim is simple: ensuring successful delivery that solves user problems.
From identification to delivery, product managers are responsible for ensuring the qualification and quality of the system via going through validation and verification phases. The validation phase is about whether the system was built correctly and met the requirements, where verification focuses on quality checking whether specifications are met.
While numerous methodologies apply to the software development process, the Lean principle is the best to use in product management. Lean enables us to see the big picture and to eliminate anything that doesn’t bring value, all while empowering team members and encouraging learning.
Where stakeholders are looking for plans, goals, objectives, roles, KPI’s and deliverables for validating the product by their end, customers are looking for something entirely different. For customers, validation processes for products are generally grouped under four different stages: problem validation, market validation, product validation, and validation of willingness to pay.
After completing these four stages as detailed above, we can be sure that our idea is worthy of developing and nurturing.
Sarper Horata
Read also
Experience the new way of doing product management
Experience the new way of doing product management