. Before assessing the likelihood of success or failure, you should decompose the situation. Instead of evaluating the probability of a product launch failure, we should write down and evaluate each potential risk separately. Such an analysis in time may take 30% longer but be 90% more accurate.
. We should put an agenda at the beginning of any discussion. We should sort the agenda by the importance of the issues (most important first). Besides, we should appoint a leader of the agenda (moderator) who will make sure that the discussion does not go into small details and does not eat up the whole team's time.
. Sometimes, an atmosphere of "openness and trust" is not enough to get each participant's opinion. To achieve this, we need to create a mechanism through which each planning participant can freely (maybe even anonymously) express their opinion. The biggest "risk" for us is accidentally finding out a detail that everyone missed.
. Any discussed dates should be cross-checked by all team members.
. We should limit the influence of our emotions and the office atmosphere on the discussed timelines and dates.
, . In most cases, we do not expect any significant changes tomorrow. We usually ignore the likelihood of changes in market conditions or the "world" of our project partners. If we do not want later on to explain the reason for our failure by "unlikely" "external" events, then we should take into account such probabilities in advance ().
. There are situations when our choice in favor of a "safe," "unambiguous" solution leads to a lost benefit. For example, we did not dare to release the update on the same day as our competitors because of the likelihood of low demand. At the same time, we did not think that the situation could be exactly the opposite, and the interest of the audience could be much higher than on any other day. By noticing our tendency to make decisions with a guaranteed outcome, we should learn to abstract from our emotions and assess the situation more soberly.
. Planning should only be based on system data and proven facts. We should be careful with the opinion of anyone who has more "power" and "recognition" than other colleagues.
. Depending on our product's specifics and audience, we may need to take into account the factor of prejudice. This applies to calendar launch dates (e.g., Friday 13), associations with negative events (day of mourning in the country), etc.
. We should write down all the agreements that our team has come up with, including those that we might think are too obvious. By showing our world view in every possible detail, we reduce the likelihood that something "extremely obvious" was missed by our colleagues or by us.
, . If our colleague ignores all of the above, believing that "this does not apply to him," then the first thing we should do is to review all the decisions he was involved in.
#63.What to do if a significant mistake occurred in the latest release?
#5.Why do users complain about product updates?
#8.Why are users so sensitive to product changes?
#22.Why didn’t users like or appreciate the recent product update?
#37.What are the risks of major changes to the product’s ideology or functionality?
#61.What should we do if our team wastes too much time on minor details?