Онлайн книга по продакт‑менеджменту
Глава 10

Запуск ИТ-продукта и проведение маркетинговой кампании

Заполните форму и получите ссылку с презентациями, и подробными видео‑лекциями на свою почту!
В этой главе я расскажу о том, какие команды должны быть задействованы в запуске релиза, какие необходимо пройти этапы, почему вам обязательно нужен маркетинг и внешние активно­сти.
В схеме, рекомендуемой фрейм­ворком Software Product Ma­nagement, запуск продукта должен проходить через следую­щие 6 стадий:

Стадия А. Внутренние коммуникации

Внутренние коммуникации пе­ред запуском нужны для того, чтобы проинформировать все заинтересованные стороны вну­три компании о том, что готовится релиз. Вы можете запустить email-рассылку или создать сообщение в мессенд­жере, чтобы рассказать всем стейкхолдерам о дате релиза, об изменениях в продукте и новых разработанных фичах. Обычно в такое сообщение вкладывается ссылка для загрузки ПО, обозначаются даты тренингов и другая полезная информация. Такую коммуникацию можно сделать за 1-4 недель до публичного запуска. Точное время зависит от вашего цикла разработки — чем он дольше, тем за больший срок надо уведомить внутренних сотруд­ников о планируемом релизе.

Стадия B. Формальное согласование

Формальное одобрение нужно для того, чтобы гарантировать максимальное качество релиза. Перед тем, как выводить что-то на рынок, необходимо, чтобы все команды и руководители дали продукту “зеленый свет”. Выпол­нение этого пункта позволяет избежать мелких неприятностей, связанных с тем, что кто-то был “не в курсе” и что-то не доделал. В такое согласование включают и техническую часть и маркетин­говую: R&D тим лиды «подпи­сываются», что все фичи готовы; QA лиды заверяют, что весь функционал протестирован и работает как надо; технические писатели уведомляют, что доку­ментация готовая; веб-команда сообщает, что контент для об­новления веб-сайта подготовлен; отдел продаж информирует, что сотрудники готовы продавать новую версию; и так далее.

Стадия C. Внешние коммуникации

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

Стадия D. Обучение

Тренинги нужны для того, чтобы переход на новую версию был гладким, чтобы все заинтере­сованные лица понимали, как пользоваться новыми фичами, знали, в чем их преимущества. Обычно в тренингах принимают участие как внутренние службы, включая техподдержку и разра­ботчиков, так и внешние поль­зователи — партнеры и заказ­чики.
Для качественного запуска про­дукта нужны как технические, так маркетинговые тренинги. Напри­мер, отделу поддержки нужно знать все подробности о работе фичей, а отделу эксплуатации (DevOps, Data Center team) – особенности развертывания продукта. Sales команды и маркетинг должны четко знать, какие бизнес проблемы решает новая версия и как правильно позиционировать продукт.

Стадия E. Анализ проведенного запуска

Анализ проведенного запуска нужен для того, чтобы оценить, был ли смысл в релизе, какие он дал технические и финансовые преимущества. На этом этапе происходит сопоставление за­трат и прибыли, анализ коли­чества обращений в техпод­держку и оценка других пара­метров, чтобы сделать выводы на будущее.
В числе метрик, которые можно оценить — переходы по ссылкам и отклики пользователей, геогра­фия интереса на новую версию, реакции на “call to action”, обращения в support по новой версии, увеличение трафика в дата-центр для продуктов SaaS и, конечно, продажи/выручка.

Стадия F. Поддержка продаж и маркетинга

Поддержка на уровне марке­тинга и PR очень важна. После запуска продукта нужно убе­диться в том, что внешние высказывания о нем корректны, что они отражают видение и стратегию компании, а публич­ная информация ориентирована на нужную целевую аудиторию и подается под “правильным соу­сом”.
На этом этапе необходимо убе­диться в том, что все важные документы о вашем продукте были обновлены (или созданы) и соответствуют параметрам рели­за. Пересмотру подлежат пре­зентации, спецификации, разде­лы сайтов и так далее.
Как уже было сказано, маркетинг — это очень важная активность для компании-разработчика ПО. Сегодня продукты не “продаются сами, потому что они хорошие”, и затраты на продвижение долж­ны соответствовать расходам на R&D. Другими словами, если стартап тратит на разработку 500 тысяч рублей в месяц, то на маркетинг и продажи нужно предусматривать сравнимую сум­му, иначе вы рискуете остаться с хорошим по качеству и функционалу, но никому неиз­вестным продуктом.

Product Awareness

Product Awareness (осведом­ленность о продукте) — путь к долгосрочному успеху продукта и компании! Можно сказать, что у вас хороший уровень Product Awareness, если люди в индустрии знают о вашем продукте и понимают, для каких целей он создан. При этом знать о продукте могут не только сами пользователи, но так же те, кто сейчас не пользуется вашим продуктом.
Например, есть у вас автомобиль или нет, вы, конечно же, слышали про марку Audi. В целом существует мнение, что машины Audi достаточно надежные, и вы знаете об этом, если даже у вас автомобиль другой марки, и вы пока не планируете покупать Audi. Такой эффект достигается за счет тщательной и кропотливой рабо­ты по построению осведомлен­ности о продукте.
Кстати, запуск новой версии продукта – отличный способ повысить Product awareness, и поэтому важно как можно шире рассказать о новинке, напомнить о себе или сформировать пер­вичный имидж. В остальное время, когда вы не выпускаете новые версии, блоги и аккаунты в соцсетях помогают поддер­живать Product awareness на постоянном уровне за счет публикации историй и новостей о продукте, компании и индус­трии. Также полезно поддержи­вать упоминаемость в СМИ, рассказывать о своей экспер­тизе. Ведь Product awareness — это естественный триггер для генерации лидов, которые впоследствии становятся прода­жами и приносят компании деньги.

Команды для релиза

Изнутри, со стороны разра­ботчиков, может казаться, что работа с релизом продукта — это их прерогатива. Но на самом деле при системном подходе с каждым релизом работает КАЖДЫЙ отдел компании!
Таким образом, практически вся компания так или иначе прини­мает участие в подготовке к запуску продукта или его версии.

Этапы запуска продукта

В процессе подготовки запуска продукта к работе над ним по­степенно подключается каждый из отделов. Например, сначала в игру вступают менеджеры по продукту. По результату сделан­ного анализа рынка, конкурен­тов, потенциальных пользова­телей и индустрии, они иници­ируют работу над новым релизом. На их плечи ложится переход от стадии “Not started” к сбору и формализации требова­ний к разработке.
Далее следует подключение разработчиков, которые оцени­вают фичи в скоупе, проектируют архитектуру, пишут код и авто­тесты, выпускают бета-версии, а потом — релиз-кандидата.
По итогам этого этапа каждая новая фича продукта должна быть готова для review на стороне продакт менеджера, а инженеры должны подготовить демо стенд с новой версией продукта, чтобы можно было снимать скриншоты, готовить документацию, маркетинговый контент и вести демо-показы.
Отдел тестирования выставляет Quality Rating (QR), чтобы определить, насколько та или иная фича готова к выпуску. Может оказаться, что какой-то функционал не готов к релизу и его придется исключить из маркетинговых материалов. QA также отвечает за нагрузочное, интеграционное и другие типы тестирования, а также проверяет корректность обновления про­дукта с самой первой версии до последней.
Отдел безопасности проводит проверку векторов атак, выяв­ляет уязвимости, тестирует работу систем хранения данных, убеждается, что в продукте нет API, работающих без автори­зации, и других брешей в защите. При необходимости про­изводится сертификация на предмет соответствия норматив­ным актами по ИБ (информа­ционной безопасности).
После завершения всех техни­ческих этапов мы получаем сначала версию Ready-to-market (RTM).
Далее
к работе подключаются юриди­ческийфинансовый и марке­тинговый отделы.
Юристы разрабатывают End-user license agreement (EULA), описывают типы лицензирова­ния, готовят или корректируют контракты с партнерами, а также новые параметры в Service Level Agreement (SLA). Также нередко новый релиз подразумевает изменение условий End of Life продукта.
От финансового отдела требу­ется составить финансовый план по новым фичам. В частности, они учитывают, как новые фичи влияют на текущие цели, как должны измениться продажи, чтобы оправдать затраты на разработку, и как новые фичи влияют на расходы компании. Финансовый отдел уточняет, может ли новая функциональ­ность потребовать дополнитель­ные ресурсы и нужен ли пересмотр прайс-листа при выхода новой версии.
На плечи маркетинга ложится выбор даты релиза, исходя не только из технической готов­ности, но и проработки сайта, контента и маркетинговых мате­риалов (о них читайте ниже). И только после отработки всех этих задач мы получаем готовый продукт в стадии General Available (GA).

Чек-листы

Чтобы ничего не забыть при координации запуска продукта необходимо вести чек-листы. Технический чек-лист вклю­чает в себя проверку готовности продукта к выпуску с технич­еской точки зрения. Маркетинговый чек-лист вклю­чает в себя весь набор марке­тинговой и контентной актив­ности, запланированных комму­никаций. Выпускать продукт можно только тогда, когда “галочки” поставлены напротив всех пунктов этих списков.
Этапы технического чек-листа:
  1. Все фичи релиза разрабо­таны, проверены и соответ­ствуют требованиям каче­ства.
  2. Нагрузочное и стресс-тести­рование пройдены.
  3. Документация написана, произведен ее proofread­ing, готова локализация.
  4. Билд продукта готов и выложен в репозиторий.
  5. Пройден аудит безопас­ности.
  6. Подготовлены Release notes.
В маркетинговый чек-лист могут входить:
  1. Подготовка White papers.
  2. Подготовка Datasheets.
  3. Публикация контента на сайте.
  4. Проработка текстов с SEO (search engine optimization).
  5. Написание пресс-релиза.
  6. Создание презентаций про­дукта.
  7. Подготовка “Battle cards”.
  8. Написание постов в блоги.
  9. Организация коммуникаций (рассылки e-mail, статьи).
  10. Проведение вебинаров.
  11. Организация тренингов.

Маркетинговые материалы

Подготовка маркетинговых мате­риалов — это большая и кропотливая работа, которую нужно проводить очень тща­тельно. Опытные PR-менеджеры и маркетологи знают, как именно нужно преподносить информа­цию, чтобы целевая аудитория услышала и запомнила главные месседжи.
Вот основные формы маркетин­говых материалов, которые используются при выпуске релиза программного продукта:

Datasheet

Это краткий документ на 1-3 страницы, в котором мы раскры­ваем назначение продукта, опи­сываем его характеристики, область применения и преиму­щества. В дословном переводе с английского Datasheet означает “лист с данными”, так что в нем нужны только основные коли­чественные характеристики, а также схемы и скриншоты.

White Paper

White Paper — это уже детальный технический документ на 10-20 страниц, который рассказывает, как ваш продукт может решать реальные задачи пользователей. В нем приветствуются факты, технические доказательства, срав­нения и логические обос­нования. Цель White Paper – предложить читателю готовое решение, с описанием его применения. Также в нем могут содержаться подробные данные о производительности или опи­сание схем интеграции продук­тов для решений конкретных задач.

Competitive Battle Cards

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

Case Study

Истории успеха демонстрируют состоятельность вашего продук­та. В этом кратком документе на 1-2 страницы должна содер­жаться информация о том, как продукт используется реальным клиентом. Такой текст готовится совместно с клиентом, включает описание проблемы и её решения с помощью продукта. Преимущества Case Study — наличие цитат и субъективных (естественно, положительных) оценок клиента.

Активная позиция

Если у вас готова новая версия продукта, вы проверили ее работоспособность и уверены в готовности внутренних команд, не ждите, пока продукт сам себя продаст. Контактируйте с СМИ, блогерами, инфлюенсерами. Не забывайте публиковать всё важное и интересное в социальных сетях, например, в Facebook, Twitter, LinkedIn, Instagram, Reddit. Также очень хорошо, если вы будете использовать обратную связь от earlier adopters в своих PR-целях.

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

Хотите просмотреть подробную видео-лекцию по этой теме? Доступ к платной записи (1,5 часа) предоставляется после оплаты.

Хотите анализ вашего продукта по готовности к запуску? Нужна помощь с составлением чек-листа? Нужны специалисты, чтобы покрыть те области, где у вас не хватает рук? Свяжитесь со мной, обсудим.
СОГЛАСИЕ НА ОБРАБОТКУ ПЕРСОНАЛЬНЫХ ДАННЫХ
Настоящим в соответствии с Федеральным законом № 152-ФЗ «О персональных данных» от 27.07.2006 года свободно, своей волей и в своем интересе выражаю свое безусловное согласие на обработку моих персональных данных, переданных через сайт «https://productdevelopment.tech/», (далее по тексту – Оператор).

Настоящее Согласие выдано мною на обработку следующих персональных данных: фамилии; имени; отчества; телефона; e-mail; а также любой информации, предоставленной мной по собственному желанию.

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

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

Настоящее согласие действует до момента его отзыва путем направления соответствующего уведомления на электронный адрес info@rudomanov.ru.

В случае отзыва мною согласия на обработку персональных данных Оператор вправе продолжить обработку персональных данных без моего согласия при наличии оснований, указанных в пунктах 2 – 11 части 1 статьи 6, части 2 статьи 10 и части 2 статьи 11 Федерального закона №152-ФЗ «О персональных данных» от 26.06.2006 г.