Факт: коммуникация о выпуске продукта вызывает проблемы

Цель заметок о выпуске продукта - сообщить вашим внутренним командам (от инженерии до клиентской поддержки) и вашим внешним заинтересованным сторонам (клиентам и партнерам) о том, что произошли изменения в продукте. В технологии, где всё движется со световой скоростью, передача обновлений продукта через заметки о выпуске является практически древней проблемой.

Каждая компания, в которой я работал, сталкивалась с трудностями в том, чтобы сделать заметки о выпуске «правильными». Но это трудно сделать правильно; важность каждого изменения или запуска продукта варьируется в зависимости от аудитории, от того, как это изменение изменяет взаимодействие конкретной группы с функцией, и от того, как эта группа использует общий продукт каждый день.

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

• Команды продуктов/дизайна/инженерии
• Команда продаж (операции продаж, внутренняя продажа, менеджеры по работе с клиентами по сегментам)
• Опыт клиентов (менеджеры по успеху и представители поддержки)
• Команда маркетинга (маркетинг продуктов, маркетинг роста, бренд, контент, которые будут вести стратегию выхода на рынок и пресс-обращение для продукта)
• Бизнес-развитие и партнеры

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

Человек (или команда), создающий коммуникации о выпуске, должен учитывать все аудитории, которые будут потреблять знания о продукте. Каковы последствия выпуска для инженера-наблюдателя по сравнению с потенциальным клиентом в розничной торговле?

Как Не подойти к заметкам о выпуске

Хотя трудно учитывать потребности разных аудиторий, Product Manager или Product Marketing Manager (PMM) также просто не могут написать пять разных версий внутренних заметок о выпуске. По моему опыту, заметки о выпуске либо слишком длинные и не по теме, либо не имеют достаточно технических деталей. Статические заметки о выпуске не предоставляют нам этой информации и часто пишутся для автора, а не для человека, которому нужно понять, что изменилось. Честно говоря, это обычно упускаемые возможности.  

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

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

Секрет написания отличных заметок о выпуске программного обеспечения

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

1. Разработать внутренний глоссарий

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

Пример: Наша команда маркетинга использует термин “запуск”, чтобы описать, когда и как мы собираемся выйти на рынок с функцией. Команда инженерии же использует слово “запуск”, чтобы описать, когда функция была выпущена в нашу тестовую среду. Конкретный запуск функции считается “завершенным” для инженерии раньше, чем наши клиенты узнают о нем. Это было запутывающе и внутренне противоречиво.

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

Примечание: Если какие-либо карты не загружаются, просто обновите страницу!

2. Что включить в ваши заметки о выпуске

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

В минимуме, хорошие заметки о выпуске включают:

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

Тем не менее, отличные заметки о выпуске также включают:

• Предполагаемые часто задаваемые вопросы (FAQs)
• Ссылка на новую публичную документацию, если доступна
• Для функций:
• Имя функции
• Скриншоты того, как выглядит функция
• Видео о том, как продемонстрировать функцию
• Почему функция существует
• Как это влияет на соответствующие покупатели/персоны клиентов

Вот шаблон, который мы используем внутри (не стесняйтесь копировать!):

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

Реализация стратегии процесса доставки продукта

Создайте единый формат коммуникации

Теперь, когда вы объединили терминологию и написали свой шаблон, следующий шаг - договориться о едином средстве доставки (т.е. Slack, электронная почта, Loom, Guru, Google Docs) и методологии. Единое средство доставки гарантирует, что ваши заинтересованные стороны знают куда им следует идти или смотреть или подписаться (для получения информации), чтобы быть в курсе выпуска.

Это также важно для управления изменениями, потому что вам обычно нужно сказать кому-то о чем-то несколько раз, чтобы гарантировать, что они полностью усвоили это. В зависимости от типа выпуска изменения в UI/UX (пользовательский интерфейс и пользовательский опыт) и влияние на клиента, ваша аудитория заметок о выпуске должна быть направлена на получение знаний о продукте (нажать). В Guru мы применяем как методологии нажатия, так и вытягивания.

Вытягивание: Где найти знания

Для нас заинтересованные стороны могут следить за нами в нашем Slack #release-notes канале, где есть единый и усвояемый формат для всего, от исправления ошибок до совершенно новых функций. Имейте в виду, что ваши соответственно аудитории должны не только знать о том, что выпуски происходят (через вытягивание в Slack или электронной почте), но, что более важно, им нужно знать, почему этот выпуск имеет значение в контексте.

Знание того, что выпуск просто произойдет или произошел, не имеет ценности, если ваша команда не может с этим что-то сделать. Чтобы разработать единый формат, который обеспечит соответствующий контекст, я опросил представителей продаж, менеджеров по развитию аккаунтов, специалистов по бизнес-развитию (и т.д.), чтобы установить наш шаблон для доставки продукта, который мы называем “Карточка разбивки функций”, которую вы можете найти выше.

Когда менеджер инженерии начинает разработку новой функции, ответственные лица получают уведомление через Asana, чтобы создать карточку разбивки функций, конкретно относящуюся к версии заметок о выпуске. Новая карточка разбивки функций становится надежным единственным источником правды или «мозгом функции», которую мы выпускаем. Эксперты по предмету (SME) — такие как PMM и инженеры по продажам — включают детали о том, почему выпуск важен, для кого он имеет наибольшее значение и, в случае необходимости, инструкции о том, как продемонстрировать функцию как часть более широкой истории.

Заинтересованные стороны по заметкам о выпуске, в частности, менеджеры по работе с клиентами, возвращаются к одним и тем же карточкам снова и снова, потому что они поняли, что динамичные знания на карточке разбивки функций проверенные, актуальные и применимые. Аудитории теперь говорят на одном и том же языке и читают из одной (динамичной) книги. Возврат к карточке разбивки функций все еще является частью метода «вытяжки», поскольку это выполняется на само-paced, и сделано для подготовки к продажам или поддержке звонку, или если потенциальный клиент имеет вопрос о дорожной карте.

Нажатие: Проактивная подача знаний

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

Почему культура, основанная на знаниях, является ключом 🗝

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

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

Мы также делаем все наши заметки о выпуске легко доступными, помещая их либо в разделы «предстоящие», либо «выпущенные» нашей доски разбивки функций, где они могут быть дополнительно организованы внутри. Таким образом, их легко следить за ними на первый взгляд. Если вы не используете Guru, мы рекомендуем попытаться создать страницу заметок о выпуске или связанную историю изменений.

Как и с любым другим процессом, этот постоянно эволюционирует. Доставка продуктов и заметки о выпуске никогда не бывают простыми, как один раз и всё. Поскольку потребности вашего бизнеса изменяются, ваши процессы, обязанности и шаблоны должны изменяться вместе с ними. Но стремление к легкому пониманию, контексту и удобству использования не может быть потеряно.