, . If we are unsure whether the users will like the new functionality, we should put it in an implicit place. If we put the functionality in a visible place, and later it turns out that most users do not need it, it will be much more difficult to remove it without causing a negative reaction from the users.

. The functionality should harmoniously fit into the context of both the product and the specific page where we place it.

. The way we present the new functionality sets the tone for future updates. The more pompous we present the functionality, the higher we put the expectation bar ().

. We should investigate users' expectations from the added functionality, and during the presentation, put special emphasis on them.

. If by adding functionality, we change any of the established workflows, then it can cause a sharply negative reaction.

. We should explain all the advantages of the functionality as simply as possible, even if we think that everything is self-explanatory.

. We can significantly overestimate our ability to implement functionality within the agreed time frame.

. If we introduce functionality that can significantly change the product, but at the same time do not allow users to refuse (at least temporarily) these changes, we run the risk of running into a sharply negative reaction.

. We should minimize the threshold for using the functionality and the learning cycle time of it. All team members should consider the assumptions about the simplicity of the new functionality. Besides, it would be very useful to evaluate usability in advance by giving a group of users access to the functionality.

. If we are constantly looking for additional information about the launch of the functionality, we should determine how exactly this information will affect our decision. In other words, we should define the success criteria for our researches.