Let’s start by answering the fundamental question: what is product validation?
There are many approaches to what’s called “product validation.” Try to Google the phrase and you will find that there is more than one way to define it. My short explanation would be that product validation is a process aimed at answering the following question: is my product something that people need? When you build a product, it’s a good practice to verify its value each time you release a new version
One of the most famous frameworks in this field was presented in The Lean Startup by Eric Ries (you can find it on our list of must-read books for CTOs). He suggests following these steps:
1. Build an experiment to test if people need what you are trying to sell them.
2. Measure the result of your experiment.
3. Learn your lesson and then iterate by building your next experiment.
What I like about this approach is that Eric reveals that in order to gain value out of the cycle, you should plan it in the reverse order. First you need to know what you want to learn about your users. Next, you should think about how you will measure it. It's only at the end that you should try to figure out how to build the fastest and cheapest experiment to gain that knowledge.
I personally think that product validation is one of the greatest challenges in the whole workflow. In the project I'm currently work on, we encountered the same challenge. However, we decided to structure a process that would support our validation. We don’t call our approach the lean startup framework, although ultimately it does include the 3 aforementioned steps: build, measure, learn.
What does our validation process look like?
(Not sure what a PO does? Read our article about Product Owner's responsibilities.) Every time our PO adds a new user story to the product backlog, they have to fill in the “how to measure?” field. This approach helps them analyze, prior to any further discussion, how to recognize if the change we're about to make is something that our users need, and if we have enough tools to allow user story validation. See the snapshot of our user story template below—this is the “planning” part of our framework.
The way we run this session is very easy: the PO presents their idea for validation while the other participants discuss it and suggest improvements where applicable. This way, the PO receives a wide range of opinions and makes more informed decisions.
No validation work is done during this stage. This is the “build” part of the lean startup framework.
After the new product increment is deployed to production, our validation process starts. Some of it happens ad-hoc—our data analysts start producing stats. However, the main point of the process is a weekly meeting during which the Product Owner, UX designer, Scrum Master, and, optionally, the client’s representative, discuss what has been released to our “live” environment and what results it's generated. In other words, we validate whether the new product features had a positive, neutral, or negative impact on end users. For this purpose, we use Google Analytics, a heatmap tool, and other data analysis tools.
After we collect the necessary data and validate new features, we make decisions regarding future development plans. We use a Jira board to facilitate the meeting (see below). We take the items that are in the “To verify” column and try to move them to “Verified,” which means that we have actually validated our feature. These are the the “measure” and the “learn” parts of the lean startup framework.
We iterate these practices and the cycle starts from the beginning every next development sprint. To summarize, the validation workflow is presented on the graph below.
Aside from Jira mentioned in the example above, we use one additional tool to visualize product validation status—the impact map.
Impact mapping is startegic planning technique created by Gojko Adzic to help businesses achieve their goals.
(We were quite excited to see Gojko Adzic himself retweet this article soon after it was published.)
The idea is simple. First, you define a business goal, e.g. “Sell our product to a million clients within 3 months.” Gojko suggests thinking about impact mapping as if it were an exercise in navigating a map from point A to point B. In this case, point A would be where we are right now, and point B is the goal we would like to reach.
If we look at the map, there are usually many ways to reach the same goal. The idea is to hit the road and check if all the roads are passable. It might turn out that some are actually closed, or there may be roads that don’t exist just yet.
Using impact mapping terms, you are supposed to define 4 elements:
Decide what would you like to achieve from the business perspective. Maybe you'd like to reach a certain volume of sales in a given period of time, or maybe you'd prefer to focus on the number of new registered users. Whatever your goal is, try to define it as precisely as possible.
Think about various groups of people who can help you achieve the goal. These can be your segments of users, your employees or anyone else.
At this stage, you need to think about the actions your actors can take to help you achieve the goal.
Try to define precise product features that will help actors make an impact.
An example could look like this:
If creating a deliverable drives actors to make an impact that supports our main goal, we validate this deliverable positively. Using that information, we then plan our future work. If a deliverable doesn’t create any positive change, we validate it negatively, which is also a significant part of our learning.
The central part of the impact map (dark blue) presents the main goal we'd set as a team. It can be any sort of a business goal, e.g. 100,000 new users registered in our application in the next 3 months. It should be something precise and easy to measure at the end of the specified period.
On the borders of our impact map, we presented the deliverables (yellow, red, black, and green) we would like to offer to the end users in order to support our main goal, e.g. a free gift for everyone who registers within the specified period. In the Agile environment, deliverables would be called user stories or product backlog items.
The colors of the deliverables carry additional meaning:
In our case, the impact map is updated weekly and overseen by the Scrum Master. However, the Product Owner or anyone else familiar with it can make sure the map stays up to date.
Based on the information we have visualized on the impact map, we make data-driven decisions about the future development of the product.
Impact mapping has a number of advantages your software house can greatly benefit from. Among others, impact mapping:
To recap, here’s a few reasons why impact mapping for Agile product validation is definitely worth your time:
Hopefully this post will help you organize your product validation process within your team. Good luck, and let us know how it goes!
If you're looking to learn more about effective software development processes, we have a few articles you might enjoy: