Web3 DevRel для момента, когда разработчик пробует ваш SDK

Где DevRel маркетинг может помочь вашим разработчикам продвинуться?

DevRel маркетинг полезен, когда разработчикам нужен более понятный путь от обнаружения вашего продукта. Он помогает им сделать следующий шаг и попробовать SDK. Он связывает объяснения продукта, технические материалы и места для вопросов. Ваша команда может сосредоточиться на препятствиях, которые важны сейчас.

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

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

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

Пресс-релиз может выявить пробел в приветствии разработчиков

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

Представьте Discord сервер с администратором на полставки, готовящим первый пресс-релиз. Участники спрашивают, где начинается SDK. Администратору все равно нужно поддерживать повседневные вопросы. Мы бы проследили эти вопросы до текущей документации. Затем мы бы согласовали, кто может проверить ответы, и подготовили короткую памятку перед публикацией пресс-релиза.

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

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

Что мы можем сделать более удобным?

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

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

В зависимости от ваших приоритетов работа может включать:

• Анализ пути от знакомства с продуктом до первого использования SDK.
• Более понятные инструкции по настройке, объяснения рабочих процессов или примеры для разработчиков.
• Приоритизированный список пробелов в документации для вашей команды.
• Рекомендации по ответам сообществу, включая владение вопросами и эскалацию.
• Материалы для хакатона, такие как бриф задания, заметки по настройке и руководство по подаче заявок.

Ваша команда по продукту или инженерии проверяет технические детали. Мы помогаем формировать опыт и координировать работу. Для каждого элемента мы согласуем, кто его проверяет. Мы также определяем, что значит «готово» перед публикацией. Это сохраняет материал основанным на том, что продукт может поддержать сегодня.

Простой рабочий ритм сохраняет детали видимыми

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

Мы используем 3 контрольные точки для поддержания работы. Сначала мы анализируем текущий путь разработчика. Затем мы согласуем приоритеты и ответственных. После этого ваша техническая команда проверяет готовые материалы. Мы также назначаем 1 человека с вашей стороны для сбора решений и предотвращения потери вопросов.

Мы согласуем 2 точки технического обзора, когда требуется участие инженерии. Первая — перед составлением утверждений о том, как что-то работает. Вторая — перед публикацией примеров или инструкций. Общая заметка о прогрессе фиксирует выполненные элементы, открытые вопросы и следующее решение. Если ваша работа по запуску продолжается после релиза, поддержка после запуска может сохранить связь обучения разработчиков с этим следующим этапом.

Предоставьте контекст продукта, о котором ваши разработчики уже спрашивают

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

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

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

Отправьте Brand Community обзор вашего продукта, текущую документацию и этап, к которому вы готовитесь. Мы проанализируем эти материалы и определим наиболее полезную первую задачу. Затем мы вернемся с четким планом для вашей команды.

Как мы работаем

1. Поделитесь картиной продуктаОтправьте обзор SDK или продукта, текущую документацию и целевую аудиторию разработчиков. Добавьте этап или задачу, которую работа должна поддержать.
2. Пройдите путь разработчикаМы прослеживаем, как кто-то обнаруживает продукт, начинает онбординг и находит помощь. Мы отмечаем неясные шаги и вопросы для ваших технических ответственных.
3. Согласуйте приоритеты и ответственныхВместе мы выбираем работу для начала и назначаем людей, которые проверяют материалы, отвечают на вопросы или координируют мероприятие.
4. Подготовьте и проверьте материалыМы создаем или улучшаем согласованные документы, рекомендации для сообщества или ресурсы для хакатона. Ваша команда по продукту или инженерии проверяет технические детали.
5. Поделитесь прогрессом и следующими действиямиМы фиксируем, что завершено, что еще требует решения и какие практические улучшения относятся к следующему циклу.