Digest as a Product: как рассказывать про новые фичи регулярно, много, френдли — и без подвигов

Привет! Я Александр Судаков — главный редактор Timeweb Cloud. Если вы кайфуете от букв, которые доносятся от нашей компании; или наоборот, вас раздражают все эти «сорри», «комп» и «гоу в панель» — то, скорее всего, за этим стою я. На самом деле, конечно, не только я — но если хотите выругаться, то пишите мне в личку ;-)

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

Про ресурсный подход, фичеризм, внутрянку и вот этот вот всё. И ни слова про скрам, аджайл, канбан и диаграмму Ганта. А еще это, кажется, единственный в своем роде кейс про написание дайджеста (во всяком случае, я других не видел).

Digest as a Product — что за зверь

Digest as a Product или DaaP — это такая отсылка к знакомым всем айтишникам аббревиатурам IaaS, PaaS, SaaS, FaaS, DaaS. Означает она то, что мы подходим к написанию и выпуску дайджеста, словно к запуску IT-продукта, который должен обновляться в начале каждого месяца — и не волнует.

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

Термин Digest as a Product придумал не я, а наш директор по маркетингу Денис Почтаренко. Я спросил, что он думает по этому поводу и как это придумал — вот его ответ:

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

Денис Почтаренко, директор по маркетингу Timeweb Cloud

Словом: чтобы делать контент, как айтишник, — нужно думать, как айтишник.

Чем вообще хорош дайджест Клауда

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

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

<a href="https://docs.google.com/document/d/1xeuOeZmx0oqrkOQjl8DgSUN6VnfB483WTzwYgKG6kiE/edit#" rel="nofollow noreferrer noopener" target="_blank">Статья</a> в блоге, <a href="https://codepen.io/Sevkosyan/full/GRwaLRr" rel="nofollow noreferrer noopener" target="_blank">рассылка</a> и <a href="https://t.me/timewebru/1256?single" rel="nofollow noreferrer noopener" target="_blank">карточки</a> в соцсетях.
Статья в блоге, рассылка и карточки в соцсетях.

Перед дайджестом мы ставим следующие цели:

  • Полноценность и самодостаточность каждого формата одновременно. Каждый из трех форматов должен быть интересен и уникален. Контент в форматах один и тот же, но если я прочитал карточки в соцсети — это не означает, что мне ничего не даст прочтение блога на сайте.
  • Акцент на фичеризм без лишних вебинаров и минимумом чисто внутренних новостей компании — прочитал и в курсе всех важных обновлений в продуктах. Да, иногда есть новости про то, что мы заняли очередное топовое место на CNews, или выпуски подкаста. Но главное — чтобы пользователь прочитал дайджест и понял, что нового он теперь может делать в наших сервисах.
  • Идеи клиентов. Наша команда разработки очень много делает обновлений по тем идеям, которые предлагают наши клиенты. В дайджесте мы также делаем акцент на этом и даже дарим за каждую внедренную идею телеграм-премиумы.

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

Про ресурсный подход

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

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

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

1. Организация и процесс

2. Рабочий чейнджлог

3. Редактор уже в контексте

4. Сразу двух и более зайцев

5. Ресурс тим-лида разработки

6. Взаимодоверие в команде

Теперь по порядку по каждому пункту

1. Организация и процесс. На каждом этапе подготовки дайджеста есть свой человек, который на низком старте в начале каждого месяца. Интернет-маркетолог ставит задачу и выбирает, о чем рассказываем в дайджесте — редактор пишет — CRM-маркетолог подхватывает рассылку и отправляет — карточки в соцсети уже готовы и ждут своей очереди, а статья написана и готовятся скриншоты — скоро все будет «на проде».

2. Рабочий чейнджлог. Это такой внутренний канал в Телеграме, в котором вся команда, включая фаундеров и директоров, следит за всеми обновлениями в продуктах. О нем мы уже рассказывали в кейсе про «300 релизов каждый месяц».

Digest as a Product: как рассказывать про новые фичи регулярно, много, френдли — и без подвигов

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

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

Digest as a Product: как рассказывать про новые фичи регулярно, много, френдли — и без подвигов

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

4. Сразу двух и более зайцев. Это вытекает из пункта 3. Есть фичи в рабочем чате — есть посты в соцсети. Есть посты в соцсети — потихоньку собирается и контент для дайджеста.

5. Ресурс тим-лида разработки. Без этого никуда: мы договорились, что мы всегда можем приходить с любыми вопросами к Мише Шпакову, а он терпеливо на них отвечает, как бы много их ни было, какими глупыми они бы ни были — и как бы занят он ни был :-)

Digest as a Product: как рассказывать про новые фичи регулярно, много, френдли — и без подвигов

6. Взаимодоверие в команде. Конечно, мы не будем оригинальными, если скажем, что важно грамотно распределять ответственность. Каждый отвечает за свое «поле деятельности» и не лезет в чужие: интернет-маркетолог решает, какие инфоповоды нужно подсветить, редактор и главред — как именно о них рассказать, есть человек, который делает нужные скриншоты по заранее сформированному и согласованному шаблону и так далее.

Cсылки и колл-ту-экшн

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

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

4
3 комментария

Эх, лучше бы RabbitMQ наконец-то запустили, я увидел что новость вышла, только хотел обрадоваться :(

p.s. А статья интересная :)

1
Ответить

Релиз RabbitMQ будет в ближайшее время. Скоро расскажем :)
А за статью спасибо!

Ответить

А будут ли GPU сервера?

Ответить