Зачем деврелу продуктовый подход: разбираем на примере про внутренние митапы
Автор: Настя Уланова
Узнавать о новых статьях блога в ТГ: @devrel_ru
Представьте, что ваше приложение работает так медленно, что пользователи ждут 30 секунд загрузки каждого экрана. Что бы произошло? Они бы просто его удалили и скачали другое. Но когда сотрудники каждый день сталкиваются с медленными корпоративными системами и сломанными процессами, кажется, что это обычный порядок дел, с которым надо мириться.
Современные компании тратят миллиарды на создание продуктов для клиентов, тщательно продумывая каждый элемент пользовательского опыта. Они разрабатывают персонализированные customer journey maps, изучают поведение пользователей, проводят A/B-тестирование каждой кнопки, создают seamless onboarding flow с прогрессивным раскрытием информации. Делают всё, чтобы пользовательский опыт был приятным и интуитивно понятным.
Для клиентов — интерфейсы, фичи, исследования, continuous feedback loops; а для сотрудников — опросные формы раз в квартал, которые уже почти никто не заполняет, performance review раз в год, где с удивлением можно узнать что-то новое о себе, и бесконечные согласования.
Чувствуется какая-то диспропорция в подходах к внешний и внутренней аудитории.
Возникает резонный вопрос, почему бы не переложить продуктовые практики на внутренних пользователей (=сотрудников) и относиться к их опыту внутри компании, так же трепетно, как и к пользовательскому?
Звучит хорошо, но на практике не всегда бывает просто разобраться, что конкретно нужно сделать руками для реализации этой концепции. Давайте посмотрим на примере.
Современные компании тратят миллиарды на создание продуктов для клиентов, тщательно продумывая каждый элемент пользовательского опыта. Они разрабатывают персонализированные customer journey maps, изучают поведение пользователей, проводят A/B-тестирование каждой кнопки, создают seamless onboarding flow с прогрессивным раскрытием информации. Делают всё, чтобы пользовательский опыт был приятным и интуитивно понятным.
Для клиентов — интерфейсы, фичи, исследования, continuous feedback loops; а для сотрудников — опросные формы раз в квартал, которые уже почти никто не заполняет, performance review раз в год, где с удивлением можно узнать что-то новое о себе, и бесконечные согласования.
Чувствуется какая-то диспропорция в подходах к внешний и внутренней аудитории.
Возникает резонный вопрос, почему бы не переложить продуктовые практики на внутренних пользователей (=сотрудников) и относиться к их опыту внутри компании, так же трепетно, как и к пользовательскому?
Звучит хорошо, но на практике не всегда бывает просто разобраться, что конкретно нужно сделать руками для реализации этой концепции. Давайте посмотрим на примере.
Как подойти к внутренним митапам с продуктовой точки зрения
Давайте подумаем, как можно внедрить продуктовый подход в девреле.
В качестве примера возьмем внутренние сессии по обмену знаниями в компании.
В большинстве команд внутренние митапы среди разработчиков проводятся по инициативе отдельных энтузиастов: кто-то поднимает руку, что готов выступить. Тема выбирается по принципу, что ближе и интереснее спикеру. Регулярность этих мероприятий обычно непредсказуема – то пусто, то густо. Выступающие чаще всего одни и те же люди.
В этой ситуации не деврел управляет процессом и результатом, а обстоятельства.
Понятное дело, что в таком случае говорить о том, какой был эффект, изменились ли процессы внутри компании, стали ли команды больше делиться друг с другом знаниями или реже изобретать велосипед – не приходится.
Теперь давайте посмотрим на эту задачу как на внутренний продукт и разберем, что изменится при этом подходе.
Шаг ноль: разобраться, какие задачи мы решаем
Например:
Jobs-to-be-Done
Здесь на первый план выходит подход Jobs-to-be-Done. Нужно разобраться, какие реальные задачи (jobs) стоят за потребностью обмениваться опытом.
Скорее всего задачи заключаются не просто в “получить информацию”, а глубже.
Для аудитории слушателей это может быть: "Я хочу быстро разобраться, как всё устроено, чтобы не тратить недели на самостоятельный поиск”, “Хочу быть в курсе последних технологий, чтобы развиваться в своей профессии”, “Почувствовать сопричастность к сообществу экспертов”, “Быстрее освоиться с новыми инструментами”, “Избежать ошибок”.
У спикеров тоже будут свои задачи: “Быть полезным, чтобы другие не совершали моих ошибок”, “Делиться своим опытом и знаниями, чтобы мы вместе быстрее и эффективнее закрывали задачи”, "Чувствовать себя частью большой движухи и понимать, что моя работа не бесполезна".
У тех, кто еще не стал спикером, но потенциально мог бы, потребность может заключаться в: “Безопасно потренироваться на небольшой аудитории”, “Понять, поможет ли моя история другим и достаточно ли интересна тема”.
Поэтому задача деврела на этом этапе – не просто собрать список тем, а ответить на вопрос, какую реальную задачу закрывают внутренние мероприятия для конкретных ЦА.
(Очень детально и с понятными примерами про подход JTBD пишет и рассказывает Ваня Замесин).
Исследование и User research на самом старте
В дополнение к этому проводим исследования: говорим со специалистами разных ролей и разного уровня (от джунов до сеньоров), задаем глубинные вопросы. “Когда ты последний раз вышел с митапа с информацией, который применил?”, “Почему ты не ходишь на внутренние сессии?”, “О чём ты стесняешься спросить?”.
Надо понять не просто их пожелания ("Рассказывайте больше про Kubernetes!"), а что болит, почему они бывают вне процесса, чего реально стесняются или ждут.
Customer journey mapping
Четко выстраиваем путь и спикера, и слушателя: когда и как сотрудник узнает про ивент, как принимает решение идти или нет, выступать или нет, в какой момент процесса спикер может “потеряться”, где теряется интерес у слушателей. Это помогает выявить и проработать узкие места.
Сегментация и персоны
Внутренняя аудитория также неоднородна: джуны и тимлиды, Frontend и DevOps, DS и Design. Они по-разному делают выбор, нужен разный уровень погружения. Для каждой персоны свой формат, темп, детализация.
Метрики успеха и аналитика
Помимо классических метрик как NPS, можно еще смотреть долю уникальных слушателей против «ядра» или количество новых спикеров за квартал.
Продумайте качественные метрики, а не только количественные. Важно не то, сколько мероприятий вы провели или сколько людей было на митапе, а что реально меняется в проектах и командах после появления такого формата по обмену знаниями.
Пробовал ли кто-то что-либо внедрить по следам внутренней сессии? Какие результаты получились?
Активация
Нам важно тестировать разные форматы, чтобы найти наиболее подходящий под наши цели и задачи нашей аудитории. Экспериментируем с live demo, воркшопами, код-ревью в реальном времени, анонимным Q&A, Ted talk, Fail meetups.
Некоторые наиболее острые темы можно поднять через анонимный вопрос: каждый может до встречи закинуть кейс, а во время мероприятия он обсуждается вслепую.
Для того, чтобы развивать культуру выступлений и обмена знаниями, можно в параллель сделать небольшие форматы. Например, ответить развернуто на один вопрос. Можно голосом, можно письменно. Можно устроить челлендж по обмену лайфхаками в чате.
Рассказывайте кейсы ребят, которые успешно преодолели страхи и теперь стали спикерами.
Организуйте буткемп для новичков, где в безопасной обстановке можно подготовить презентацию для последующего выступления.
Жизненный цикл
Помните, что у любого продукта есть жизненный цикл. Если формат изжил себя, не бойтесь его менять или искать новый.
Классный внутренний обмен знаниями — это не просто количественная ачивка. Из этого надо выстраивать такой же продукт, как и основной сервис. Здесь все то же самое: есть пользователи, задачи, боли, свой цикл и механики активации.
В качестве примера возьмем внутренние сессии по обмену знаниями в компании.
В большинстве команд внутренние митапы среди разработчиков проводятся по инициативе отдельных энтузиастов: кто-то поднимает руку, что готов выступить. Тема выбирается по принципу, что ближе и интереснее спикеру. Регулярность этих мероприятий обычно непредсказуема – то пусто, то густо. Выступающие чаще всего одни и те же люди.
В этой ситуации не деврел управляет процессом и результатом, а обстоятельства.
Понятное дело, что в таком случае говорить о том, какой был эффект, изменились ли процессы внутри компании, стали ли команды больше делиться друг с другом знаниями или реже изобретать велосипед – не приходится.
Теперь давайте посмотрим на эту задачу как на внутренний продукт и разберем, что изменится при этом подходе.
Шаг ноль: разобраться, какие задачи мы решаем
- Для кого мы это делаем?
- Кто заказчик и бенефициар этой инициативы?
- Какую цель преследуем?
Например:
- Команды не разговаривают между собой. Одни делают свой сервис в изоляции от других. В результате происходит многократное дублирование решений и отсутствие единого технического стека.
- Надо расширять переиспользование технологий, но нет прозрачной коммуникации: проще скопировать чужой сервис или заново писать библиотеку, чем начать диалог.
- Иногда заказчик инициативы – CTO, который видит разницу в продуктивности команд, задаётся вопросом: почему команда А выкатывает фичи быстрее команды Б и можно ли этот успешный кейс раскатить на всю компанию?
Jobs-to-be-Done
Здесь на первый план выходит подход Jobs-to-be-Done. Нужно разобраться, какие реальные задачи (jobs) стоят за потребностью обмениваться опытом.
Скорее всего задачи заключаются не просто в “получить информацию”, а глубже.
Для аудитории слушателей это может быть: "Я хочу быстро разобраться, как всё устроено, чтобы не тратить недели на самостоятельный поиск”, “Хочу быть в курсе последних технологий, чтобы развиваться в своей профессии”, “Почувствовать сопричастность к сообществу экспертов”, “Быстрее освоиться с новыми инструментами”, “Избежать ошибок”.
У спикеров тоже будут свои задачи: “Быть полезным, чтобы другие не совершали моих ошибок”, “Делиться своим опытом и знаниями, чтобы мы вместе быстрее и эффективнее закрывали задачи”, "Чувствовать себя частью большой движухи и понимать, что моя работа не бесполезна".
У тех, кто еще не стал спикером, но потенциально мог бы, потребность может заключаться в: “Безопасно потренироваться на небольшой аудитории”, “Понять, поможет ли моя история другим и достаточно ли интересна тема”.
Поэтому задача деврела на этом этапе – не просто собрать список тем, а ответить на вопрос, какую реальную задачу закрывают внутренние мероприятия для конкретных ЦА.
(Очень детально и с понятными примерами про подход JTBD пишет и рассказывает Ваня Замесин).
Исследование и User research на самом старте
В дополнение к этому проводим исследования: говорим со специалистами разных ролей и разного уровня (от джунов до сеньоров), задаем глубинные вопросы. “Когда ты последний раз вышел с митапа с информацией, который применил?”, “Почему ты не ходишь на внутренние сессии?”, “О чём ты стесняешься спросить?”.
Надо понять не просто их пожелания ("Рассказывайте больше про Kubernetes!"), а что болит, почему они бывают вне процесса, чего реально стесняются или ждут.
Customer journey mapping
Четко выстраиваем путь и спикера, и слушателя: когда и как сотрудник узнает про ивент, как принимает решение идти или нет, выступать или нет, в какой момент процесса спикер может “потеряться”, где теряется интерес у слушателей. Это помогает выявить и проработать узкие места.
Сегментация и персоны
Внутренняя аудитория также неоднородна: джуны и тимлиды, Frontend и DevOps, DS и Design. Они по-разному делают выбор, нужен разный уровень погружения. Для каждой персоны свой формат, темп, детализация.
Метрики успеха и аналитика
Помимо классических метрик как NPS, можно еще смотреть долю уникальных слушателей против «ядра» или количество новых спикеров за квартал.
Продумайте качественные метрики, а не только количественные. Важно не то, сколько мероприятий вы провели или сколько людей было на митапе, а что реально меняется в проектах и командах после появления такого формата по обмену знаниями.
Пробовал ли кто-то что-либо внедрить по следам внутренней сессии? Какие результаты получились?
Активация
Нам важно тестировать разные форматы, чтобы найти наиболее подходящий под наши цели и задачи нашей аудитории. Экспериментируем с live demo, воркшопами, код-ревью в реальном времени, анонимным Q&A, Ted talk, Fail meetups.
Некоторые наиболее острые темы можно поднять через анонимный вопрос: каждый может до встречи закинуть кейс, а во время мероприятия он обсуждается вслепую.
Для того, чтобы развивать культуру выступлений и обмена знаниями, можно в параллель сделать небольшие форматы. Например, ответить развернуто на один вопрос. Можно голосом, можно письменно. Можно устроить челлендж по обмену лайфхаками в чате.
Рассказывайте кейсы ребят, которые успешно преодолели страхи и теперь стали спикерами.
Организуйте буткемп для новичков, где в безопасной обстановке можно подготовить презентацию для последующего выступления.
Жизненный цикл
Помните, что у любого продукта есть жизненный цикл. Если формат изжил себя, не бойтесь его менять или искать новый.
Классный внутренний обмен знаниями — это не просто количественная ачивка. Из этого надо выстраивать такой же продукт, как и основной сервис. Здесь все то же самое: есть пользователи, задачи, боли, свой цикл и механики активации.
А теперь главный вопрос: “Зачем так заморачиваться?”
“Мы же делаем это для наших сотрудников. Внутренний движ. И так сойдет!”
С пользователями продукта всё понятно: они приносят деньги, можно посчитать ROI от каждой активности. Если не они, то и самого бизнеса бы не было. Тут любые танцы с бубнами продуктового подхода станцуешь.
С сотрудниками же эффект от таких трудозатрат сложно просчитать.
Согласно исследованию института Gallup (2025), замена руководителей и менеджеров обходится компании примерно в 200% их годового оклада, замена специалистов на технических должностях – около 80% их годовой зарплаты.
Скорее всего тут еще не учтены косвенные затраты. Например, потенциальная упущенная выгода от ухода ключевых сотрудников и возможные риски для продукта, стоимость маркетинговых кампаний по привлечению кандидатов, а также времени команды по онбордингу нового сотрудника.
А возможно дело еще и в парадигме, в которой думать о повышении прибыли компании гораздо приятнее, чем о сокращении расходов и экономии ресурсов. Но исключает ли одно другое?
С пользователями продукта всё понятно: они приносят деньги, можно посчитать ROI от каждой активности. Если не они, то и самого бизнеса бы не было. Тут любые танцы с бубнами продуктового подхода станцуешь.
С сотрудниками же эффект от таких трудозатрат сложно просчитать.
Согласно исследованию института Gallup (2025), замена руководителей и менеджеров обходится компании примерно в 200% их годового оклада, замена специалистов на технических должностях – около 80% их годовой зарплаты.
Скорее всего тут еще не учтены косвенные затраты. Например, потенциальная упущенная выгода от ухода ключевых сотрудников и возможные риски для продукта, стоимость маркетинговых кампаний по привлечению кандидатов, а также времени команды по онбордингу нового сотрудника.
А возможно дело еще и в парадигме, в которой думать о повышении прибыли компании гораздо приятнее, чем о сокращении расходов и экономии ресурсов. Но исключает ли одно другое?
Заключительные мысли
Каждый деврел – по определению “многорукий” эксперт, который жонглирует знаниями из абсолютно разных областей: от сугубо технических до гуманитарных. Мы и про ИТ, и про маркетинг, коммьюнити-менеджмент, контент и аналитику. Поэтому использовать практики из других областей в порядке вещей.
А продуктовый подход поможет:
А продуктовый подход поможет:
- Изменить отношение к тому, что и каким образом мы, деврелы, и одновременно владельцы своего продукта, делаем.
- Заодно систематизировать информацию, переложить знания из разряда интуитивных в плоскость обоснованных и подкрепленных данными.
- За счет этого повысить вероятность успеха нашего деврел-продукта и достижения поставленных целей.
Об авторе
Настя Уланова – лидер по коммуникациям, брендингу и PR.
Более 13 лет раскрывает уникальные стороны компаний и выстраивает эффективные коммуникации.
Возглавляла Employer Branding, Marketing и Tech PR на рынках CIS, EMEA, UKI, APAC, US – в GlaxoSmithKline, Deutsche Bank и FunCorp.
Связаться: @jonestasy
Более 13 лет раскрывает уникальные стороны компаний и выстраивает эффективные коммуникации.
Возглавляла Employer Branding, Marketing и Tech PR на рынках CIS, EMEA, UKI, APAC, US – в GlaxoSmithKline, Deutsche Bank и FunCorp.
Связаться: @jonestasy
Подписаться на деврел-дайджест
Если хочется узнавать о новых статьях и читать лонгриды в почте
Если хочется узнавать о новых статьях и читать лонгриды в почте