Привет, Хабр! Очередной пост в серии публикаций о продакт-менеджменте от компании Acronis посвящен этапам запуска продукта. В этом материале я расскажу о том, какие команды должны быть задействованы в запуске релиза, какие необходимо пройти этапы, почему вам обязательно нужен маркетинг и внешние активности.
1. Роль менеджера по продукту и фреймворк
2. Сегментирование рынка и конкурентный анализ
3. Пользовательские персоны
4. Проверка гипотез
5. Позиционирование продукта
6. Дорожная карта продукта
7. Составление требований для разработки
8. Бизнес-модель и Бизнес-план
9. Финансовый план и ценообразование
10. Запуск ИТ-продукта и проведение маркетинговой кампании < — Вы здесь
11. Партнерские отношения, каналы дистрибьюции и продажи продукта
12. Этапы развития компании и продукта
На разработку каждого релиза и каждого нового продукта мы тратим ресурсы внутренних команд, деньги и время. Поэтому ни одна версия не должна выходить в свет тихо и незаметно. Одной из задач менеджера по продукту является координация запуска, чтобы выход новой версии принес компании максимум прибыли, лидов и узнаваемости на рынке.
В схеме, рекомендуемой фреймворком Software Product Management, запуск продукта должен проходить через следующие 6 стадий:
Стадия А. Внутренние коммуникации
Внутренние коммуникации перед запуском нужны для того, чтобы проинформировать все заинтересованные стороны внутри компании о том, что готовится релиз. Вы можете запустить email-рассылку или создать сообщение в мессенджере, чтобы рассказать всем стейкхолдерам о дате релиза, об изменениях в продукте и новых разработанных фичах. Обычно в такое сообщение вкладывается ссылка для загрузки ПО, обозначаются даты тренингов и другая полезная информация. Такую коммуникацию можно сделать за 1-4 недель до публичного запуска. Точное время зависит от вашего цикла разработки — чем он дольше, тем за больший срок надо уведомить внутренних сотрудников о планируемом релизе.
Формальное одобрение нужно для того, чтобы гарантировать максимальное качество релиза. Перед тем, как выводить что-то на рынок, необходимо, чтобы все команды и руководители дали продукту “зеленый свет”. Выполнение этого пункта позволяет избежать мелких неприятностей, связанных с тем, что кто-то был “не в курсе” и что-то не доделал. В такое согласование включают и техническую часть и маркетинговую: R&D тим лиды «подписываются», что все фичи готовы; QA лиды заверяют, что весь функционал протестирован и работает как надо; технические писатели уведомляют, что документация готовая; веб-команда сообщает, что контент для обновления веб-сайта подготовлен; отдел продаж информирует, что сотрудники готовы продавать новую версию; и так далее.
Внешние коммуникации во многом повторяют внутренние, за небольшой разницей в подаче. В этот раз рассылку получают ваши партнеры и основные клиенты. Эта рассылка чаще всего происходит в день релиза, либо за один-два дня, чтобы создать ажиотаж и чувство ожидания. Вы информируете получателей об основных изменениях, дате релиза, предоставляете ссылку на страницу загрузки продукта, объявляете даты тренингов и вебинаров, и так далее.
Тренинги нужны для того, чтобы переход на новую версию был гладким, чтобы все заинтересованные лица понимали, как пользоваться новыми фичами, знали, в чем их преимущества. Обычно в тренингах принимают участие как внутренние службы, включая техподдержку и разработчиков, так и внешние пользователи — партнеры и заказчики.
Для качественного запуска продукта нужны как технические, так маркетинговые тренинги. Например, отделу поддержки нужно знать все подробности о работе фичей, а отделу эксплуатации (DevOps, Data Center team) – особенности развертывания продукта. Sales команды и маркетинг должны четко знать, какие бизнес проблемы решает новая версия и как правильно позиционировать продукт.
Анализ проведенного запуска нужен для того, чтобы оценить, был ли смысл в релизе, какие он дал технические и финансовые преимущества. На этом этапе происходит сопоставление затрат и прибыли, анализ количества обращений в техподдержку и оценка других параметров, чтобы сделать выводы на будущее.
В числе метрик, которые можно оценить — переходы по ссылкам и отклики пользователей, география интереса на новую версию, реакции на “call to action”, обращения в support по новой версии, увеличение трафика в дата-центр для продуктов SaaS и, конечно, продажи/выручка.
Поддержка на уровне маркетинга и 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).
Чтобы ничего не забыть при координации запуска продукта необходимо вести чек-листы. Технический чек-лист включает в себя проверку готовности продукта к выпуску с технической точки зрения. Маркетинговый чек-лист включает в себя весь набор маркетинговой и контентной активности, запланированных коммуникаций. Выпускать продукт можно только тогда, когда “галочки” поставлены напротив всех пунктов этих списков.
Этапы технического чек-листа:
В маркетинговый чек-лист могут входить:
Подготовка маркетинговых материалов — это большая и кропотливая работа, которую нужно проводить очень тщательно. Опытные PR-менеджеры и маркетологи знают, как именно нужно преподносить информацию, чтобы целевая аудитория услышала и запомнила главные месседжи.
Вот основные формы маркетинговых материалов, которые используются при выпуске релиза программного продукта:
Это краткий документ на 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-целях.
Конференции, митапы, выставки, хакатоны — все это прекрасные площадки для продвижения нового продукта или новой версии. Старайтесь проводить живые демонстрации продукта, распространяйте ваши материалы. Сегодня большой популярностью пользуются вебинары, так что вы можете запускать свои собственные, а также участвовать в партнерских. Кстати, тема партнерства очень важна для менеджера по продукту, и в следующем посте мы как раз поговорим о партнерских взаимоотношениях и каналах распространения для ваших разработок.
→ Видео-запись всех лекций курса доступна на YouTube
Лекция про подготовку релиза и запуск продукта:
Хотите анализ вашего продукта по готовности к запуску? Нужна помощь с составлением чек-листа? Нужны специалисты, чтобы покрыть те области, где у вас не хватает рук? Пишите в личку, обсудим.
Оглавление курса
1. Роль менеджера по продукту и фреймворк
2. Сегментирование рынка и конкурентный анализ
3. Пользовательские персоны
4. Проверка гипотез
5. Позиционирование продукта
6. Дорожная карта продукта
7. Составление требований для разработки
8. Бизнес-модель и Бизнес-план
9. Финансовый план и ценообразование
10. Запуск ИТ-продукта и проведение маркетинговой кампании < — Вы здесь
11. Партнерские отношения, каналы дистрибьюции и продажи продукта
12. Этапы развития компании и продукта
На разработку каждого релиза и каждого нового продукта мы тратим ресурсы внутренних команд, деньги и время. Поэтому ни одна версия не должна выходить в свет тихо и незаметно. Одной из задач менеджера по продукту является координация запуска, чтобы выход новой версии принес компании максимум прибыли, лидов и узнаваемости на рынке.
В схеме, рекомендуемой фреймворком Software Product Management, запуск продукта должен проходить через следующие 6 стадий:
- A. Internal communication — Внутренние коммуникации;
- B. Formal approval — Формальное согласование;
- C. External communication — Внешние коммуникации;
- D. Training — Обучение;
- E. Launch impact analysis — Анализ проведенного запуска;
- F. Sales and Marketing support — Поддержка продаж и маркетинга.
Стадия А. Внутренние коммуникации
Внутренние коммуникации перед запуском нужны для того, чтобы проинформировать все заинтересованные стороны внутри компании о том, что готовится релиз. Вы можете запустить 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 — это естественный триггер для генерации лидов, которые впоследствии становятся продажами и приносят компании деньги.
Команды для релиза
Изнутри, со стороны разработчиков, может казаться, что работа с релизом продукта — это их прерогатива. Но на самом деле при системном подходе с каждым релизом работает КАЖДЫЙ отдел компании!
- Quality Assurance (QA) обеспечивает проверку качества продукта перед его запуском.
- Команды DevOps / DataCenter operations подготавливают инфраструктуру для запуска сервисов SaaS.
- Support оказывает поддержку пользователям, которые не разобрались сразу с новыми фичами.
- Security проводит аудит безопасности, чтобы убедиться в отсутствии уязвимостей.
- Technical Writers готовят пользовательскую документацию, которая должна быть обновлена до момента релиза.
- Localization team обеспечивает перевод интерфейса продукта и документации на различные языки.
- Product Marketing создает контент и готовит официальные сообщения для продвижения.
- Legal пересматривает контракты и обязательства, приводит их в соответствие с обновленным продуктом.
- Content/Designers обновляют сайт, выкладывают контент, соответствующий новой версии.
- Sales Managers работают с клиентами, вызывая интерес к новому продукту, привлекают экспертов для обсуждения потребностей заказчиков, готовят продажи.
- Sales Engineers / Solution Architects разрабатывают технические и интеграционные решения для конкретных заказчиков.
- Professional Services ведут сопровождение продукта.
- Finance составляют финансовый план для продукта, который должен учитывать изменения последнего релиза.
- PR and Media работают над повышением 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).
Чек-листы
Чтобы ничего не забыть при координации запуска продукта необходимо вести чек-листы. Технический чек-лист включает в себя проверку готовности продукта к выпуску с технической точки зрения. Маркетинговый чек-лист включает в себя весь набор маркетинговой и контентной активности, запланированных коммуникаций. Выпускать продукт можно только тогда, когда “галочки” поставлены напротив всех пунктов этих списков.
Этапы технического чек-листа:
- Все фичи релиза разработаны, проверены и соответствуют требованиям качества.
- Нагрузочное и стресс-тестирование пройдены.
- Документация написана, произведен ее proofreading, готова локализация.
- Билд продукта готов и выложен в репозиторий.
- Пройден аудит безопасности.
- Подготовлены Release notes.
В маркетинговый чек-лист могут входить:
- Подготовка White papers.
- Подготовка Datasheets.
- Публикация контента на сайте.
- Проработка текстов с SEO (search engine optimization).
- Написание пресс-релиза.
- Создание презентаций продукта.
- Подготовка “Battle cards”.
- Написание постов в блоги.
- Организация коммуникаций (рассылки e-mail, статьи).
- Проведение вебинаров.
- Организация тренингов.
Маркетинговые материалы
Подготовка маркетинговых материалов — это большая и кропотливая работа, которую нужно проводить очень тщательно. Опытные 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-целях.
Конференции, митапы, выставки, хакатоны — все это прекрасные площадки для продвижения нового продукта или новой версии. Старайтесь проводить живые демонстрации продукта, распространяйте ваши материалы. Сегодня большой популярностью пользуются вебинары, так что вы можете запускать свои собственные, а также участвовать в партнерских. Кстати, тема партнерства очень важна для менеджера по продукту, и в следующем посте мы как раз поговорим о партнерских взаимоотношениях и каналах распространения для ваших разработок.
→ Видео-запись всех лекций курса доступна на YouTube
Лекция про подготовку релиза и запуск продукта:
Хотите анализ вашего продукта по готовности к запуску? Нужна помощь с составлением чек-листа? Нужны специалисты, чтобы покрыть те области, где у вас не хватает рук? Пишите в личку, обсудим.
