As a product manager, more or less unreliable requirements will be made. Although there may be various objective reasons for unreliable requirements, we should not be used to this. I think most of the unreliable requirements are caused by the unscientific requirements demonstration process, so how can a reliable product manager be “scientific” to do the requirements? Because I have recently started to come into contact with some articles about scientific literacy and scientific thinking, I have found that related content is very helpful to our rational science work in connection with my own work, so I will share the content in connection with work practice.
In scientific research, keywords such as hypothesis, falsification, and inference will often appear. “Hypothesis” in scientific description refers to a theory built to explain a certain phenomenon; “falsification” is the core of the difference between science and non-science. Science admits that it may be wrong. In plain terms, if you can prove XXX, then This assumption is wrong, this is the falsification of science; and “inference” is a phenomenon or fact that should be able to be observed under the assumption that the theory is correct.
If we look at the work of product managers from the perspective of academic research, what we have done is that if a certain hypothesis exists, if the result deduced by this hypothesis is beneficial to users or product goals, we will optimize and improve the product based on the hypothesis. ; And if this hypothesis is falsified in the demand argumentation process, you can make a decision without making this demand. So how do we practice this scientific spirit in actual work?
Hypothesis
Users with similar purchasing power should have the same preference for hotel brands
If you happen to be a thinking person, there will always be various guesses about users and products at work, such as “Users may prefer XXX”, “XXX will shorten the user’s decision path”, “XXX will make users feel better (The user experience is better)”, these guesses are hypotheses in scientific research. Guessing (hypothesis) is the starting point for us to continuously explore the requirements. Let’s put it this way, a PM who loves hypothesis may not end up being awesome, but a PM who doesn’t think about it will definitely not be able to create a demand that makes people shine. The hypothesis may come from extended thinking about some data phenomena, may come from past experience or other competing status quo, or it may come from intuitive judgments of human nature or the market environment, or even just a big brainstorm. On the point of putting forward a hypothesis, my suggestion is: the more the better.
Falsification
If users with similar purchasing power buy hotels with a fairly even distribution of brands, then we won’t do this demand.
With the assumptions, writing out the demand plan is a matter of course, so can the demand start to be developed and launched? Of course not. If you do, you will probably only end up with an unreliable reputation. Many requirements ultimately prove to be unreliable because the assumptions themselves are unreliable. According to scientific thinking, a reliable theory should be falsifiable and not falsified in the current situation. For the product manager, in order to make the demand reliable, every method must be used to falsify the speculation about the user and the product. The paradox is that we continue to find ways to prove that our guess is wrong, but the real purpose is to confirm that the guess is reliable, that is to say, only those guesses that cannot be proved wrong can be true. As the basis for our demand.
Common methods of falsification include existing data analysis and MVP (minimum viable product, if you don’t know what it means, you can Baidu by yourself). For example, according to the hypothesis in the case, if the data shows that the brand distribution of users with similar purchasing power is very even, then the hypothesis does not hold; sometimes for some brand new attempts, if the appropriate falsification method cannot be found under the circumstances at the time, then You can use the MVP method, which can verify whether the hypothetical demand is reliable in the case of small investment. For strategic products, offline implementation can also be considered a kind of MVP, although sometimes offline experiments are not 100% consistent with online effects.
Inference
After this demand goes online, it should be able to improve the experience of 5% of users and increase the transaction volume by 100,000
For many novice product managers, the effect estimation is the more difficult part. In fact, if the demand can be made scientifically, the effect estimation is simple and cannot be simpler. To be reasonable, the requirements are based on assumptions, and the description of the assumptions must include the coverage of the problem. If the requirements are to solve the problem in the assumption, then the scope of the problem that the demand can solve will be clearly visible. For example, if the case assumes users with similar purchasing power, the proportion of users with purchasing power information must be known, and demand can only solve the experience problems of this part of users. As for the transaction promotion value brought by the experience improvement, we can get an estimated value by referring to other similar product optimization projects, so that we can calculate the estimated effect of demand.
It should be noted that sometimes there are some logical pitfalls from hypothesis to estimation, so I won’t repeat them here. If you feel that you have flaws in logical derivation, try to be careful when doing the corresponding work, you can also read the book to make up the lesson, and recommend a useful but a little boring book “Logic Essentials”.
Having said that, is it really useful in the actual work of a product manager? In fact, these points are what the requirements document should focus on in addition to the requirements plan: the requirements background describes the hypothesis and the value proof (falsification) content; the demand estimation uses inferences to calculate what results can be achieved; the demand risk is written Know under what circumstances the demand should be stopped or how to improve. Yes, today’s focus is how to use an academic attitude to write your own requirements documents and be a reliable product manager.
