. Не игнорировать просьбы.

, . Мы можем максимально прозрачно объяснить все те сложности, с которыми столкнемся в случае если пойдем по предложенному ими пути.

. Мы можем видоизменить требования пользователей, и вывести несколько похожих опций на всеобщее голосование. При этом каждая из опций должна быть выполнима, и соответствовать нашим бизнес целям. Само голосование можно провести без указания абсолютного кол-ва участников (только проценты). Затем, аппелируя к большинству мы можем отказать в рассмотрении требуемых изменениях, и имплементировать те, которые победили на голосовании. При этом мы подчеркиваем, что делаем все в соответствии с пожеланиями пользователей ().

, . Мы можем показать пользователям существенные изменения в устоявшемся порядке действий в привычных компонентах продукта, если мы согласимся с предложенными изменениями. Идея в том, чтобы показать пользователям как сильно они недооценивают удобство устоявшихся практик.

. Мы можем отвлечь пользователей от их требований, серией кратковременных бонус- предложений/наград.

. Если предложенные изменения выпадают из контекста продукта, тогда нам следует развернуто это объяснить. Конечно, пользователи не обязаны понимать важность целостности продукта, однако объяснение наших беспокойств – это меньшее что мы можем сделать.

. Пользователи могут захотеть увидеть разницу в виде «до» изменений и «после». Если мы считаем что наша транспарентность с аудиторией может нам помочь, тогда нам следует наглядно показать потенциальные результаты изменений.

. Иногда нам может быть достаточно показать то время, которое потребуется на разработку предложенных изменений. Если речь идет о нескольких месяцах, требуемых на разработку, тогда мы можем подчеркнуть, что к моменту запуска обновлений, они утратят свои полезные качества.