Текст книги "Карьера продакт-менеджера. Все что нужно знать для успешной работы в технологической компании"

• Начинайте доставку продукта пользователям как можно раньше и делайте выводы: некоторые из ваших предположений относительно продукта могут быть ошибочными, поэтому ваш первый релиз не должен быть слишком объемным. Начните с самой небольшой версии продукта, обладающей ценностью для пользователя, и предложите ее реальным людям (например, в виде бета-версии программы), чтобы получить реальную обратную связь. Это оградит вас от создания ненужных функций и подтолкнет к выполнению именно того, что приведет к реальному успеху продукта. Кроме того, чем скорее вы выведете продукт на рынок, тем раньше пользователи и бизнес начнут получать выгоду.

• Не запускайте незначительный или некачественный продукт: ограничение масштабов проекта очень важно, но при этом может зайти слишком далеко. Не стоит предлагать подгоревшую пиццу, а потом говорить, что пицца вообще никому не нравится. Лучше сократить число функций или пользовательских сценариев, чем сэкономить на шлифовке.

• Чтобы эффективно определить объем работ, требуется скромность и храбрость: вы должны уметь признавать тот факт, что отзывы реальных пользователей могут только улучшить ваш продукт. Но вам также нужно быть достаточно храбрым, чтобы запустить продукт, зная, что он неидеален. Эмоционально проще отложить запуск до того, как каждая функция будет полностью проработана и отшлифована. Но, как правило, результат пошаговых запусков намного эффективнее.

Глава 12
Запуск продукта

Запуск продукта можно представить как нечто среднее между безупречным исполнением отрепетированной симфонии и тем моментом, когда разбивается пиньята[66]66
  Большая полая игрушка из папье-маше или бумаги, наполненная конфетами, мелкими игрушками и т. д. – Примеч. ред.


[Закрыть], дети бросаются собирать лакомства, а вы просто надеетесь, чтобы все обошлось без серьезных травм.

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

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

При этом кто-то обязательно должен проследить за тем, чтобы ничего не упустить[67]67
  И под этим кем-то мы подразумеваем вас.


[Закрыть].

Запуск – это главное испытание ваших навыков реализации. Все взгляды устремлены на вас в ожидании чего-то невероятного. Ваши первые запуски могут сопровождаться всего лишь публикацией в блоге или справочной статьей. Однако по мере совершенствования ваших умений запуски будут становиться более замысловатыми и сложными, и однажды вы будете стоять на сцене перед полным залом клиентов, партнеров и журналистов, анонсируя свой новейший продукт.

РЕВЬЮ ЗАПУСКА

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

Ревью запуска – это совещание, в результате которого вы (будем надеяться) получаете окончательное одобрение на вывод продукта на рынок. Желательно, чтобы подобные встречи проходили за несколько дней до запланированной даты запуска, чтобы у вас еще оставалось время на решение вопросов, которые неизбежно появятся. Обычно допустимо предоставлять продукт для ревью запуска заранее, до того как он будет готов на 100 %. Но только при условии, что проверяющие четко понимают, какие задачи еще выполнены не полностью.

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

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

Что бы ни случилось, сохраняйте спокойствие и не принимайте это близко к сердцу. Помните, что проверяющие преследуют те же цели, что и вы, просто каждый действует, исходя из своей позиции. Все хотят быстро запускать отличные продукты и не тратить впустую время и силы. Как только вы поймете, что цели клиентов и бизнеса для всех одинаковы, вы сможете обсудить с точки зрения логики, какие задачи и связанный с ними выбор стоит принимать во внимание.

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

ЧЕК-ЛИСТ ЗАПУСКА

Чаще всего провальные запуски происходят потому, что какой-то вопрос остается без внимания. Спасением в данном случае может стать чек-лист. Для начала обдумайте следующие моменты:

• План развертывания: на какую дату и время назначен запуск? Начнется ли он с А/В-тестирования, релиза бета-версии или будет идти поэтапно?[68]68
  Поэтапное развертывание подразумевает увеличение числа пользователей, которые постепенно в течение нескольких часов или дней будут получать новый код.


[Закрыть] Какие системы необходимо запустить и в каком порядке? Сколько времени займет каждое развертывание? На каком этапе маркетинговые материалы будут представлены публике? Будете ли вы бронировать конференц-зал на день запуска (чтобы расположить там оперативный штаб), чтобы никого не пришлось искать, если потребуется решить какой-то вопрос?

• Продукт: был ли продукт тщательно протестирован и прошел ли он необходимый контроль качества? Есть ли в нем система онбординга? Работает ли продукт на всех платформах? Пригоден ли он для международного использования? Прошел ли он через все ревью запуска? Возможно, стоит составить отдельный чек-лист тестов, чтобы убедиться, что вы учли все важные потоки и граничные случаи.

• Ведение журнала: все ли процессы журналируются, чтобы можно было проанализировать, насколько успешным был запуск, и узнать, как люди используют новые функции? Вы проверяли, как ведется журналирование, чтобы удостовериться, что все работает как надо?

• Инфраструктура: все ли инфраструктурные службы провели обзор обновлений (на предмет безопасности, стабильности, надежности сайта и т. д.)? Нужно ли провести «тайный запуск» продукта, чтобы проверить его стабильность?[69]69
  Тайный запуск – это параллельный запуск нового бэкенда без подключения его к фронтенду.


[Закрыть]

• Другие проверки: нужны ли другие проверки, например со стороны юридической или финансовой службы?

• Маркетинг: все ли материалы для вывода продукта на рынок готовы? Как потенциальные пользователи узнают о запуске? Будет ли это публикация в блоге, пресс-релиз, email-рассылка или более масштабное мероприятие по запуску? Потребуется ли обновление описания продукта в магазинах приложений? Соответствует ли позиционирование целям запуска?

• Продажи и поддержка клиентов: прошли ли эти отделы соответствующее обучение? Обновлена ли документация? Нужны ли им новые материалы или видео? А новые внутренние инструменты для работы?

• Другие системы: требуется ли обновление каких-либо других внутренних систем, например биллинговой?

• Внутренняя коммуникация: сделаете ли вы рассылку внутри компании о запуске продукта? Устроите ли вы вечеринку?

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

СТРАТЕГИЯ ВЫХОДА НА РЫНОК

Запуск продукта подразумевает намного больше, чем просто его загрузку в магазин приложений. Как люди узнают, что он там появился? Почему они должны предпочесть его другим предложениям?

Стратегия выхода на рынок (go-to-market, GTM) – это план доведения продукта до потребителя. Обычно он разрабатывается отделом маркетинга. Главная задача заключается в том, чтобы привлечь клиентов и получить конкурентное преимущество. Основная часть стратегии разрабатывается задолго до фактического запуска. Для этого применяются навыки, описанные в главе 16 «Фреймворк стратегии» (с. 208).

По мере приближения даты запуска вы вместе с маркетологом дорабатываете рекламные обращения и планы действий.

Заявление о позиционировании

Наверняка вы уже слышали такие фразы, как «Это как Uber в фотографии», «Это как Pinterest для медитации» или «Это как Академия Хана для кошек». Все это заявления о позиционировании.

Для команды, которая должна привести в соответствие продукт, маркетинговые мероприятия и бренд, эти заявления являются своего рода мини-презентацией того, как клиенты, по вашему мнению, должны воспринимать продукт. В отличие от заявлений о миссии, они позиционируют продукт в рамках конкретной категории и на фоне конкурентной среды[70]70
  Вы только посмотрите! Только что мы создали заявление о позиционировании заявления о позиционировании.


[Закрыть].

Джеффри Мур (Geoffrey Moore) описал в своей книге Crossing the Chasm[71]71
  Мур Дж. «Преодоление пропасти. Как вывести технологический продукт на массовый рынок».


[Закрыть] шаблон подобного заявления, который стал очень популярным:

Для (целевой клиент),

который недоволен (имеющаяся рыночная альтернатива) / который (описание потребности или возможности),

наш продукт – это (новая категория продуктов),

который обеспечивает (ключевая функция, которая решает проблему клиента).

В отличие от (альтернативный продукт),

мы собрали (ключевые характеристики продукта для конкретного применения / ключевые отличительные черты).

Заявления о позиционировании важны, потому что потенциальные клиенты и пользователи не будут тратить время на то, чтобы полностью понять ваше видение продукта. Каждое касание с клиентом от онлайн-рекламы и встроенного гайда по продукту до прямых обращений к клиенту должно нести одну и ту же мысль. При этом ваше сообщение должно быть максимально отточенным, чтобы услышавший его человек сразу бы сказал: «Да! Это как раз моя проблема, и мне нужно это решение!»

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

Продвижение

Как люди узнают о существовании вашего нового продукта? Если вы работаете в Google или Facebook, пресса будет с нетерпением ждать новостей о любом вашем запуске, и вы всегда можете использовать перекрестную рекламу в своих же продуктах. Всем остальным приходится уделять особое внимание тому, как продвигать новый продукт на рынке.

Существует множество способов (каналов) продвижения. Вот некоторые из них:

• Онлайн-реклама, например поисковая (SEM, search engine marketing) или реклама в социальных сетях. Затраты и эффективность такой рекламы легко отследить, так как всегда можно посмотреть, кто кликнул на рекламное объявление и затем стал реальным клиентом. Для этого способа важно правильно подобрать ключевые слова.

• Связи с общественностью (пиар, PR). Можете ли вы заинтересовать СМИ настолько, чтобы они написали статью о запуске продукта? Какие публикации читает ваша аудитория?

• Поисковая оптимизация (SEO, search engine optimization). Многие компании пытаются вывести свой сайт в топ поисковой выдачи, предоставляя контент, полезный для широкой аудитории, например как это делает блог о моде StitchFix.

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

• Мероприятия, конференции и выставки. Событие, приуроченное к крупному запуску, поможет собрать прессу и клиентов в одном месте, привлечь к продукту больше внимания и произвести особое впечатление.

• Партнерство. Совместный запуск с партнерами очень эффективен, особенно для платформенных продуктов. Клиентам сложно представить, какую пользу они могут получить при работе с той или иной платформой, пока они не увидят, что смогли на ее основе сделать ваши партнеры.

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

• Продажи. Какая команда по продажам вам нужна: будет ли она лишь отслеживать лиды (потенциальных клиентов) или попытается выйти с ними на контакт? Какие материалы понадобятся для поддержки продаж? Откуда к вам будут приходить лиды?

Для большинства запусков разумнее всего использовать сразу несколько каналов, а выбирать их следует в зависимости от целевой аудитории, а также их стоимости и эффективности.

РЕФЕРЕНСНЫЕ КЛИЕНТЫ

Референсные клиенты – это довольные клиенты, которые получили ранний доступ к новому продукту и готовы дать отзывы о том, насколько он им понравился. Их можно цитировать в пресс-релизах, добавлять в примеры использования продукта или даже пригласить их самих выступить на мероприятии в честь запуска. Они служат социально значимым доказательством того, что ваш продукт работает.

Чтобы получить больше таких клиентов, пригласите подходящих для этой роли кандидатов принять участие в предварительном запуске бета-версии нового продукта и внимательно изучите их отзывы. Общайтесь с ними как можно чаще, вкладывайтесь в эти отношения. Можно начать с нескольких потенциальных референсных клиентов – на тот случай, если у кого-то из них окажутся слишком своеобразные требования к продукту, которые вы не сможете удовлетворить до запуска.

НЕ ПРОВОДИТЬ ЗАПУСК, ПОКА ПРОДУКТ НЕ БУДЕТ ПОЛНОСТЬЮ ГОТОВ

По мере приближения даты запуска вы будете чувствовать на себе все больше и больше давления. Будьте осторожны: следите, чтобы ваше желание поскорее завершить процесс не привело к запуску продукта, который затем потерпит фиаско.

Дрю Диллон (Drew Dillon), консультант по лидерству продукта и бывший CPO[72]72
  CPO (Chief Product Officer) – директор/руководитель по продукту. – Примеч. ред.


[Закрыть], говорит:

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

A/B-тесты и бета-версия дадут вам огромное количество информации, которую можно использовать для прогнозирования успеха. Если клиентам не нравится ваш продукт или разработанные обновления кажутся провальными, проведите еще несколько итераций и попробуйте улучшить результат. Лучше отложить дату запуска на несколько недель, чем выпустить на рынок то, что заведомо не принесет успеха.

СЛЕДИТЬ ЗА ТЕМ, ЧТОБЫ НИЧЕГО НЕ УПУСТИТЬ

Во время запуска требуется держать в голове массу задач. Работая по чек-листу запуска с другими людьми, лучше использовать подход «доверяй, но проверяй». Организуйте все так, чтобы коллегам было ясно, кто за что отвечает и в какие сроки все должно быть выполнено. Можно собирать регулярные совещания, чтобы отслеживать, что сделал каждый участник команды, и гарантировать, что ничего не ускользнуло от вашего внимания. Фреймворк DACI/RACI (с. 264–265) поможет четко распределить роли.

РАБОТАТЬ НАД ОБЕСПЕЧЕНИЕМ КАЧЕСТВА

Даже если у вас есть отдел обеспечения качества (QA) или команда тестирования (что бывает не во всех компаниях), вы все равно должны погружаться в процесс создания плана тестов и самостоятельно проверять самые важные процессы. Придется не ограничиваться только багами ПО и стараться найти то, что может испортить пользовательский опыт.

Вот несколько подходов к QA:

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

• Догфудинг: использование продукта командой на стадии его разработки. Иногда приходится подключать воображение, чтобы заставить людей опробовать не слишком нужный им продукт. Например, у обычных сотрудников Google нет особых причин размещать где-то рекламу, поэтому на различных этапах разработки AdWords компания выдавала сотрудникам небольшие суммы денег, которые они должны были потратить на оплату сервиса. И обязательно нужно следить за тем, чтобы люди четко знали, где они могут оставить сообщение о баге или разместить отзыв.

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

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

• Самостоятельная проверка: всегда собственноручно тестируйте продукт. Вы лучше знаете, как он должен работать, поэтому вы сможете отследить те проблемы, которые другие могут не заметить.

Обратите особое внимание на следующие моменты:

• Обзор сквозных потоков взглядом новичка: во время разработки вы тестируете каждый кусок отдельно. Но иногда после сборки чего-то не хватает или что-то работает не так, как нужно, особенно с точки зрения юзабилити. Представьте себя новичком, незнакомым с продуктом, и пройдитесь по всем процессам от начала до конца.

• Проверка каждого отдельно взятого потока: если продукт должен по-разному работать для вошедших в систему пользователей и тех, кто этого не сделал (или для премиального/бесплатного тарифов), проследите за тем, чтобы каждый поток был протестирован.

• Общие случаи, которые не попадают в догфудинг: подумайте, какие моменты могут остаться без внимания во время проверки продукта внутри компании (например, регистрация новых пользователей, нулевые состояния, потоки обновления продукта, обучение пользованию продуктом).

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

• Детали дизайна: выровнены ли элементы относительно друг друга, равное ли между ними расстояние? Все ли изображения четкие? Срабатывает ли анимация? Правильно ли работает выделение при наведении курсора на объект? Соответствует ли конечный дизайн мокапам?

• Устройства: веб-приложения необходимо протестировать в нескольких браузерах и на экранах с разной диагональю, а мобильные – на всех поддерживаемых платформах и для всех поддерживаемых размеров устройств. Большинство сотрудников в технологических компаниях используют Chrome на Mac, но реальные пользователи выбирают и другие платформы. Поэтому проследите за тем, чтобы также были протестированы Safari, Firefox и Edge.

• Интернационализация: как правило, проводят тест для немецкого (отображение длинных слов), японского (отображение двухбайтовых символов) и арабского языков (отображение языков с написанием справа налево). Также не лишне проверить расстановку диакритических знаков и отображение эмодзи.

ЭТО МОГЛО ПЛОХО ЗАКОНЧИТЬСЯ!

Наталья Барышникова, бывший руководитель отдела PM в SmartRecruiters, когда-то отвечала за развертывание продукта для одной крупной австралийской компании. Все мероприятия QA были успешно пройдены, но она заметила, что при закрытии приложения появлялась фраза: «Congratulations, we’re rooting for you!» (Поздравляем и болеем за вас!)

Поработав в разных культурах, Наталья знала, что с разговорными выражениями могут возникнуть проблемы, и решила еще раз уточнить у клиента, можно ли использовать эту фразу для продукта. Как оказалось, на австралийском сленге эта фраза звучит немного непристойно. Хорошо, что она ее заметила!

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

РЕШАТЬ ЛЮБЫЕ ПРОБЛЕМЫ С ЗАПУСКОМ

Представьте, что сегодня день запуска, и что-то пошло не так! Приложение дает сбой. Кнопка скачивания переводит на пустую страницу. Пользователи пишут гневные твиты. Черт!

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

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

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

• Уведомьте руководство. Инициативный подход с вашей стороны поможет укрепить доверие к вам и позволит руководителям оказать вам помощь.

• Подумайте, можете ли вы откатить изменения. Насколько серьезны проблемы? Можно ли отменить обновления, не навредив пользователям? Разосланы ли маркетинговые материалы тем клиентам, кто будет ждать обновления? Если вы решите откатить продукт до предыдущей версии, проследите за тем, чтобы все мероприятия по продвижению продукта, такие как анонсы и email-рассылки, были приостановлены.

• Можно ли выборочно внести исправления? Спросите инженеров, существует ли способ обойти какие-то стандартные процессы для быстрого решения проблемы. Но будьте осторожны: если часто отказываться от тестирования изменений, чтобы исправить мелкий баг, можно случайно вызвать более серьезный баг. Если приложение уже разместили в магазине, вы можете попробовать обратиться к его владельцам с просьбой ускорить одобрение вашего нового релиза.

• Вместе со службой маркетинга продумайте ответ, который вы будете давать клиентам. Удостоверьтесь, что формулировки службы поддержки клиентов и SMM-специалистов совпадают.

• Как только все будет улажено, проведите ретроспективу или используйте метод «Пять почему» (с. 88), чтобы определить основную причину возникновения проблем и понять, как предотвратить такую ситуацию в будущем.

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

ОТМЕТИТЬ УСПЕХ И ДЕРЖАТЬ КОЛЛЕГ В КУРСЕ СОБЫТИЙ

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

Предлагаем вам несколько вариантов того, как можно донести до людей нужную информацию и отпраздновать успех:

• Анонс запуска: в день запуска отправьте всем сотрудникам компании сообщение с рассказом о том, какой продукт вы запустили (тут помогут скриншоты), и благодарностью всем, кто внес свой вклад в это дело (включая кросс-функциональных партнеров). Если вы точно не знаете, кого лично стоит поблагодарить, попросите ключевых сотрудников из каждого подразделения подготовить для вас список. Будет неплохо поделиться в сообщении первыми результатами запуска, если таковые имеются, или разбавить текст шуткой.

• Вечеринка по случаю запуска: можно просто накупить кексов и пригласить коллег в конференц-зал на угощение (или доставить угощение тем, кто работает вне офиса). Для более значимых запусков может потребоваться масштабное мероприятие. Обсудите с администратором или офис-менеджером, как это лучше устроить. Чтобы вечеринка стала особенной, подготовьте тост или короткую речь и выступите перед своей командой.

• Информирование после запуска: как только у вас появятся реальные данные об успешном запуске и вы проведете ретроспективу, организуйте еще одну рассылку. Сделайте так, чтобы все узнали хорошие новости. Если похвастаться особо нечем, поделитесь, какие выводы вы сделали на основании результатов и как это может повлиять на дальнейшую работу.

Особенность таких празднеств и сообщений заключается в том, что большинство людей в компании не знают, как относиться к проведенному запуску, пока вы им об этом не скажете. Правильное празднование успеха поднимает моральный дух компании. Честно делясь результатами запуска, вы можете помешать тому, чтобы у людей сложилось неправильное впечатление или появились ошибочные выводы.