С тех пор как я присоединился к PostHog летом 2025 года, мы увеличили количество офлайн-мероприятий с 1 до более чем 100 в год. Примерно в 95% этих мероприятий входит общение с клиентами, и более 50% сотрудников компании выезжали в города по всему миру, чтобы проводить демо — и этот процент продолжает расти.

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

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

Вот как наша команда по организации офлайн-мероприятий в PostHog добивается этого (не выкручивая никому руки).

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

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

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

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

«Продуктовые инженеры общаются с пользователями. Они решают, что создавать. Они отвечают за ценообразование, выручку и пользовательский опыт. Они напрямую поддерживают клиентов. Они подотчетны в первую очередь своим пользователям и платящим клиентам. Они принимают продуктовые решения». (Источник: Наше руководство по продуктовой инженерии)

«Продуктовые инженеры общаются с пользователями. Они решают, что создавать. Они отвечают за ценообразование, выручку и пользовательский опыт. Они напрямую поддерживают клиентов. Они подотчетны в первую очередь своим пользователям и платящим клиентам. Они принимают продуктовые решения». (Источник: Наше руководство по продуктовой инженерии)

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

Этот отчет о мероприятии от Майкеля после его выступления на митапе разработчиков в Милане в начале этого лета показывает, как это выглядит, когда продуктовым инженерам нравится то, над чем они работают, и нравится делиться этим с пользователями:

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

Нашим еженедельным общим встречам (all-hands). Они заканчиваются 15–20 минутами, в течение которых сотрудники со всей компании делятся экранами (молясь богам демо).

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

Нашему каналу #demo-posthog-anything. Люди пишут сюда в любое время, чтобы демонстрации не прекращались всю неделю, а не только в преддверии очередной общей встречи.

Например, вот Сэм демонстрирует работу диаграмм рассеяния в нашем продукте для аналитики на SQL:

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

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

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

Мы верим, что наши инженеры знают, как проводить демо, поскольку они являются экспертами в своей теме, раз уж они ее создали. Мы не делаем для них слайды, мы не проводим генеральные репетиции, мы просто даем им делать свою работу. Это также связано с другой нашей ценностью под названием «ты — водитель» (you're the driver). Никто здесь не указывает вам, что делать.

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

Кто, что, где, когда. Детали мероприятия — это первое, чем мы делимся со всеми спикерами.

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

Бюджет на поездки. Часть бюджета на мероприятия выделяется на поездки при необходимости.

Официальные брендированные слайды, логотипы, кабанчики (hogs). Всё, что связано с активами бренда, находится в свободном доступе.

Рекомендации и советы. У нас есть страницы в руководстве и информационная рассылка о том, как проводить потрясающие демо на основе того, что хорошо работало в прошлом.

Еще до того, как обращаться к спикерам с предложениями, мы используем специальный навык анализа экспертности спикеров, который создал наш коллега из команды по работе с разработчиками Климент. Он берет GitHub-аккаунт сотрудника, анализирует его замердженные PR-запросы во всей организации PostHog за последние 6 месяцев, а затем выдает план его работы, подробные темы для потенциальных технических выступлений и оценку актуальности темы по 10-балльной шкале. Это помогает нам приходить к сотрудникам с готовыми идеями, а не перекладывать это на них.

Вот выдержка из результатов работы этого инструмента после анализа деятельности Алексея Лебедева:

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

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

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

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

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

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

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

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