Я работаю в сфере отношений с разработчиками уже 5 лет и видел множество попыток измерить деятельность команд DevRel. Часто возникает много неясностей по поводу того, как лучше всего измерить работу, которую выполняет DevRel. Используете ли вы модель AAARRRP от Фила Леггеттера, модель Orbit от команды Orbit, традиционную воронку продаж или что-то другое?
Независимо от того, приняла ли ваша команда DevRel модель AAARRP или Orbit для внутренней оценки своей работы, есть вероятность, что другие элементы бизнеса, от лиц, принимающих решения, до других вертикалей, таких как продажи и маркетинг, рассматривают вашу функцию как часть воронки.
Это глубоко проблематично.
Прежде чем я объясню, почему, позвольте мне на минуту отвлечься и объяснить, что такое воронка продаж.
Что такое воронка продаж?
Воронка продаж — это, по сути, визуализация для описания процессов, через которые проходит потенциальный клиент, пока не станет подтвержденным покупателем. Верхняя часть воронки» является самым широким отверстием и содержит всех людей, которые узнают о продукте. Затем она проходит через различные стадии в «середине воронки», такие как интерес, оценка и желание, пока не достигнет самого «дна воронки», то есть принятия решения о покупке.
Очень заманчиво поместить деятельность DevRel на вершину воронки или рядом с ней. В конце концов, для чего проводятся все мероприятия сообщества, презентации на конференциях, создаются учебные пособия и многое другое, если не для того, чтобы вызвать осведомленность, интерес, оценку и желание?
Однако это не совсем верно, и давайте опишем почему. Начнем с краткого изложения разницы между двумя часто смешиваемыми дисциплинами — маркетингом разработчиков и отношениями с разработчиками.
Маркетинг разработчиков и отношения с разработчиками: в чем разница?
Маркетинг для разработчиков — это создание привлекательного рекламного контента с явной целью привлечения новых клиентов из числа разработчиков.
Как делится Пратим в этом твиттере, сами термины проясняют разницу. Маркетинг — это транзакция, в то время как отношения — это долгосрочные инвестиции, основанные на взаимности.
Маркетинговая кампания для разработчиков всегда будет иметь цель призыва к действию (CTA), напрямую связанную с увеличением количества покупок, регистраций, ввода данных или любой другой финансовой метрики для бизнеса. Рекламная кампания в целевых подкастах для разработчиков будет измеряться по таким показателям, как привлечение новых клиентов, и путь клиента может быть очень четко привязан от прослушивания кампании в подкасте до совершения новой покупки.
Отношения с разработчиками существуют в сотрудничестве с маркетингом разработчиков, но это не маркетинг разработчиков.
Отношения с разработчиками направлены на создание вовлеченности и катализацию роста сообщества. Само вовлечение — это цель. Катализатор развития сообщества — это цель. Это не стратегии для достижения цели, это сами цели.
CTA для маркетинга разработчиков может звучать так: «Создайте аккаунт сегодня!», в то время как CTA для отношений с разработчиками может звучать так: «Изучите наши проблемы с открытым исходным кодом, в которые вы можете внести свой вклад сегодня!». Разница очевидна.
Однако зачем бизнесу вкладывать значительные ресурсы в организацию, которая измеряется не напрямую новыми клиентами и ростом доходов? В чем ценность для компании?
Почему компании (должны) создавать команды по связям с разработчиками
Джеффри Буссганг и Джоно Бэкон в своей статье в Harvard Business Review еще в 2020 году объяснили, почему компании должны инвестировать в создание сообществ:
Хотя сообщества генерируют материальные ценности для бизнеса — такие как контент, события, онлайн-пропаганда и маркетинг, производство технологий, поддержка клиентов и образование — именно нематериальные ценности, которые участники получают от опыта, делают эту среду по-настоящему «липкой». Люди по своей сути являются социальными животными. Поведенческая экономика и психологические исследования научили нас тому, что мы жаждем ощущения связанности, принадлежности, миссии и смысла, особенно при выполнении своей работы. В книге Терезы Амабиле «Принцип прогресса» и книге Дэниела Пинка «Драйв» показано, что продвижение к общей миссии является наиболее мотивирующей силой для профессионала. Сообщества обеспечивают эти преимущества, создавая чувство общей ответственности и набор ценностей при сохранении индивидуальной автономии.
Бэкон и Буссганг продолжают, что такое использование врожденного стремления человека к общей ответственности, связанности и принадлежности приносит компаниям следующие результаты:
- Заинтересованные члены помогают привлекать новых членов, что приводит к снижению затрат на привлечение клиентов и плотной вирусной петле.
- Члены сообщества не желают покидать его, что приводит к увеличению удержания и, следовательно, повышению пожизненной ценности.
- Члены сообщества поддерживают друг друга, что приводит к высокой валовой прибыли за счет более низкой стоимости услуг.
То, что верно для людей в целом, безусловно, верно и для той части людей, которые работают разработчиками программного обеспечения.
Вот почему компании, ориентированные на разработчиков, должны создавать команды по связям с разработчиками. Это необходимо для создания «липкого» сообщества. То есть прочное, долговечное, устойчивое и долговечное сообщество.
Команды по связям с разработчиками делают это разными способами, и спецификация роли варьируется от команды к команде. Тем не менее, все они включают в себя определенное сочетание бесед 1 на 1, презентаций 1 на много, создание контента, улучшение опыта разработчиков в компании с помощью SDK и библиотек поддержки, а также построение тесной обратной связи между пользователями и командами, создающими само устройство.
Как же измерить эту работу, если она настолько важна для бизнеса, но не связана с воронкой продаж, как маркетинг для разработчиков?
Измерение отношений с разработчиками
Работа по связям с разработчиками должна измеряться в соответствии с ее целью и задачами. Действительно, каждая организация в бизнесе должна оцениваться по своим целям. Проблема возникает, когда компания решает навязать одну и ту же меру успеха для каждого аспекта бизнеса. Иногда с DevRel возникают сложности, потому что он часто существует внутри устоявшейся организации, например, отдела продукта или маркетинга, и довольно просто применить меру успеха родительской организации к инициативе DevRel. Постарайтесь избежать этого, если хотите, чтобы ваша команда DevRel была такой же «липкой», как и сообщество, которое, как вы надеетесь, она будет развивать.
Что значит измерять отношения с разработчиками в соответствии с их целью и задачами? Это значит вернуться к первым принципам DevRel в вашем бизнесе и вывести оттуда показатели успеха. Каковы самые большие потребности команды DevRel в вашем бизнесе?
- Улучшение опыта работы разработчиков с продуктом?
- Расширение участия в проектах с открытым исходным кодом?
- Повышение осведомленности о компании в конкретных сообществах разработчиков?
- Создание библиотеки полезного контента, который поможет разблокировать разработчиков, создающих продукт?
- Что-то еще? Какая-то комбинация вышеперечисленного?
Определите, каковы ваши наивысшие приоритеты в области построения сообщества, а затем наметьте конкретные, измеримые, реалистичные и ограниченные по времени цели, начиная с этого места.
Что бы вы ни делали, не связывайте напрямую успех вашей команды DevRel с потраченными деньгами, увеличением объема поступающих данных или другими подобными показателями. Это, несомненно, важные цели, но работа по связям с разработчиками не выстраивается таким образом, чтобы можно было легко и точно отследить активность X до потраченных долларов. Попытки сделать это только расстроят профессионалов, работающих в команде, заставив их сместить работу с того, чем они должны заниматься, и вместо этого работать над тем, чтобы «казаться успешными», что в конечном итоге приведет к выгоранию и высокому уровню неустойчивости сотрудников.
Делиться хорошими новостями
Именно потому, что создание сообщества разработчиков — это долгосрочная инвестиция, которая не попадает в параметры воронки продаж, слишком часто становится легко забыть о ее реальной бизнес-ценности. Руководство команды DevRel обязано последовательно и постоянно управлять процессом, четко и ясно показывая бизнес-руководству его ценность и успешность.
Специалисты DevRel не могут полагать, что руководство и команды вне их самих интуитивно понимают, какой вклад они вносят в общий успех бизнеса. Эти линии должны быть проведены для всех остальных, и руководство команды DevRel должно постоянно доводить это до сведения бизнеса. Во многих случаях это означает создание множества красочных слайдов с графиками, диаграммами и текстом, набранным очень крупным шрифтом. Чем больше команда DevRel и ее руководство будут делать это, тем лучше их будут понимать внутри компании, и тем больше они смогут процветать.
Компании, основной аудиторией которых являются разработчики, обычно стремятся создать команду по связям с разработчиками на ранней стадии, потому что они слышали, что она необходима для достижения успеха. Тем не менее, они часто приступают к этой работе без четкого понимания того, что эта команда должна делать помимо «посещения мероприятий» и «общения с разработчиками». Такая неопределенность в конечном итоге может привести к разочарованию, поскольку расходы на команду продолжают расти, и становится трудно измерить ее результаты для бизнеса. Сообщение с самого начала целей команды, создание четко определенных измерений, основанных на этих целях, и постоянный обмен как этими целями, так и результатами этих измерений с бизнесом в целом, поможет в значительной степени создать ясность и общее согласование функции DevRel в бизнесе.