Как анонсировать новую функцию (без тишины)

Большинство анонсов функций умирает в канале, который никто не читает дважды: твит, пролетевший мимо, письмо дня релиза, погребённое под двенадцатью другими, которые подписчица получила на той неделе, сообщение в Slack в канале, который половина команды заглушила месяцы назад. Функцию выпустили. Почти никто из тех, кто бы ей пользовался, об этом не узнал. Исправить это — меньше о написании лучшего анонса, и больше о выборе правильного канала для правильной читательницы, и о том, чтобы напрямую достучаться до тех, кто явно об этом просил, вместо того чтобы полагаться на то, что они заметят общее сообщение.

Где на самом деле должна анонсироваться новая функция?

В более чем одном месте, потому что «все читают один и тот же канал» никогда не бывает правдой. Запись changelog или feed обслуживает читательницу, которая проверяет по собственному расписанию и хочет постоянную, датированную запись. Уведомление в приложении обслуживает читательницу, которая уже пользуется продуктом и воспользовалась бы функцией сегодня, если бы знала о её существовании. Письмо обслуживает читательницу, которая сейчас не в продукте, но вернулась бы ради нужного обновления. Соцсети обслуживают охват за пределами существующих пользователей, почти без таргетинга.

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

Что анонс должен сказать первым?

Результат, не механизм. «Мы добавили слой кэша к endpoint отчётов» описывает, что построила команда. «Отчёты теперь загружаются меньше чем за секунду» описывает, что изменилось для читательницы, и именно это предложение получает клик, потому что отвечает на «что мне с этого» в первой фразе, а не в третьей. Механизм принадлежит записи changelog или странице деталей, а не заголовку.

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

Чем это отличается от письма с обновлением продукта?

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

Как добраться до конкретных людей, которые об этом просили?

Это анонс с лучшим соотношением усилий и отдачи, и почти все команды его пропускают. Если десять клиентов запросили функцию по имени, эти десять человек заслуживают прямую, личную заметку в момент выпуска, независимо от того, какой более широкий анонс выходит. Замыкание цикла обратной связи с клиентом разбирает механику целиком; резюме здесь в том, что это работает только если исходный запрос остался связан с попросившим, что скорее проблема отслеживания, чем проблема анонса. В changeloop, когда отзыв из виджета стал GitHub issue, а объединённый pull request его закрывает (fixes #142), одобрение записи changelog один раз публикует в этом issue комментарий «Shipped —

Как написать саму запись?

Та же дисциплина, что и в любой другой записи release notes: начать с того, что читательница теперь может делать, продолжить нужной настройкой, пропустить внутреннее обоснование. Как писать release notes разбирает полный метод; анонс новой функции — случай с самой высокой ставкой, потому что это запись, наиболее вероятно заскриншоченная, переслана и прочитана кем-то, кто никогда не видел changelog продукта.

Когда не стоит анонсировать широко?

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

FAQ

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

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

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

Нужен ли анонсу функции скриншот? Для всего визуального — да; описанную, но не увиденную функцию пропускают гораздо чаще, чем ту, для которой читательницы могут увидеть превью. Для API или backend-возможности короткий пример кода делает ту же работу, что скриншот для изменения UI.

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

По теме на changeloop: Примеры changelog, Документация для разработчиков