Data Product : comment appliquer le PM aux produits data ?
A travers la publication de 4 articles, nous partageons notre expérience et notre vision du Data Product Management.
Do you want to develop your product but aren’t sure which direction to take? Use product hypotheses to test and analyze assumptions that will help you develop a successful product. Here’s how.
Launching a product or new features can be time-consuming and costly. It is therefore necessary to de-risk our decisions as much as possible to develop impactful and truly useful features for your users.
In the case of launching a new product, you must make sure you are dealing with the right problem before thinking about the best solution. For example: “Is there a problem around online plane booking?”. If you answer yes to this based solely on your own perception, there is a risk that your answer will be biased and therefore incorrect.
Verifying that a problem is accurate or that your product provides the right answer can be time-consuming. It is essential to be methodical to limit the costs and the time you will spend. The Minimum Viable Product (MVP) is a good tool to validate an imperfect first version of your product and test your hypotheses in the field, with the most realistic conditions possible.
📚 Read our article on the Minimum Viable Product to learn more about the method.
In this article, let's imagine that our product is a newsletter and that we need to boost the number of subscriptions.
The challenge is to find the answers to your questions in order to improve your performance. For example: “Why are my newsletter subscriptions so low?”
To begin, you will always need to take a step back and map out everything you know before thinking about a solution.
This is what we will call: the formalization of hypotheses.
At Hubvisory, we use hypotheses to test hunches, user needs, and preferences.
“Our question is…” is the heart of your problem. This is the problem you are looking to solve. You have identified this problem because it blocks your objectives and therefore demands a solution.
You can also present this problem in the form of an affirmation. For example: “We want to double the rate of users who subscribe to the newsletter”.
The formalization of this problem is important because, like an OKR objective, it allows you to illustrate your objective.
Then, the formalization of your hypotheses goes as follows:
Example of Product Hypothesis CanvasSource : Hubvisory
“We think…” represents your intuition. To obtain a list of hypotheses, you can organize a reflection workshop with the stakeholders affected by your problem.
For the issue of subscriptions to the newsletter, we could invite a person responsible for writing the newsletters, or even a loyalty officer. Our advice at Hubvisory is to always make sure that someone carries the voice of the user, or that the user himself participates in the improvement of the product.
To make assumptions, it is important to know your market as well as your users. This will increase your ability to find relevant hypotheses and stay in line with the expectations of your customers.
“To verify we ...” is the formalization of the method. You must explain the test you are going to perform. For example, indicate that you are going to perform an A/B test on a percentage of the population with version A (a white button) and version B (a red button). I also recommend that you indicate a notion of time during which your experiment will have to be tested.
“The hypothesis will be validated if…” is the hardest part of formulating hypotheses. The objective is to determine which criterion (a measurable quantitative result) will allow you to say whether this hypothesis is confirmed or invalidated. Like any choice of KPI, it must be SMART (Specific, Measurable, Achievable, Realistic and Time-bound).
"SMART", what does it mean?
This metric can be qualitative (response from our users following an interview, etc.) or quantitative (factual data supported by figures).
In our example, we'll know the hypothesis is confirmed if we get 50% more clicks on a version with a more conspicuous button on a week-long A/B test.
Once your hypotheses have been formalized, you will be able to move on to the experimentation phase. The idea is then to validate your hypothesis to make your intuition a conviction.
You have to see your list of hypotheses as a backlog that you want to prioritize and achieve. By ordering by priority, you can define an experimentation schedule.
Having a backlog of clear and prioritized experiments has the advantage of guaranteeing good follow-up, especially when several people have to intervene in the experiments.
Your experiment sheets list the tests you are going to carry out and the results you have obtained.
If you have completed your experiment, you will get all the answers to your questions. This will allow you to more serenely embark on the design of a relevant solution.
Your experimentation did not lead you where you wanted? It's still a victory. As we have seen, experimentation is there to save you time and money in your product development.
Whether your experimentation is positive or negative, it will allow you to better know your product and your users. You now have all the keys in hand to work on your problems and make your product a high-performance product!
This method is popular because of its many advantages that allow you to improve the quality of your deliverables and thus, your daily life as a Product Manager:
The product hypothesis is the ideal tool for the Product Manager to de-risk and limit the costs that could be incurred on low-value features. In a few steps, the product hypothesis allows the Product Manager to create a product whose evolutions have been tested and analyzed, ensuring the creation of a successful digital product.
Nous croyons en un nouveau modèle de consulting où l’excellence commence par l’écoute, le partage et une vraie vision