Русский
  • product
  • developers
  • growth

5 уроков выхода на рынок, которые я извлёк из продвижения продукта с акцентом на разработчиков

Уроки и практики, извлечённые из продвижения роста Logto среди разработчиков.

Guamian
Guamian
Product & Design

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

  1. Мы выпустили версию с открытым исходным кодом в июле 2022 года.
  2. В январе 2023 года мы запустили облачный предварительный просмотр (бета-облако).
  3. К июлю 2023 года продукт был готов к эксплуатации с полной ценовой политикой.

Имея опыт в продуктово-ориентированном росте для инструментов повышения производительности, команды и я пробовали различные стратегии выхода на рынок для Logto. После двух лет я проанализировал эти усилия и шаги, которые мы предприняли. Я хочу поделиться частью этого пути и объяснить, почему некоторые вещи не работали в то время. Это не "ошибки", а ценные уроки из нашего опыта. Я надеюсь, что эти инсайты помогут другим, работающим над подобными проектами или стартапами.

Традиционные стратегии онбординга могут не работать

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

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

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

  1. Что именно является "задачей, которую нужно выполнить" для Logto? В отличие от простых продуктов, таких как инструменты повышения производительности (например, написание документов или создание произведений искусства), Logto занимается созданием систем аутентификации или управлением идентичностями пользователей. Но как пользователи могут этого достичь всего за один день?
  2. Да, мы добавили ссылку Calendly для бронирования звонков, но не получили много бронирований, и это не увеличило наш коэффициент конверсии, как ожидалось.

Earn early credit - Logto Cloud.png

Почему №1 не работает

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

Почему №2 не работает

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

Freemium или бесплатная пробная версия? Прежде чем разбираться, поймите свой продукт

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

При создании SaaS-продукта одним из ключевых вопросов для выхода на рынок (GTM) является выбор между freemium или бесплатной пробной версией. Общепринятое мнение предполагает:

  1. Бесплатная пробная версия: пользователи получают полный доступ на ограниченное время, а затем должны платить, чтобы продолжить.
    • Лучше всего для: сложных или премиум-продуктов, где пользователям необходимо испытать все функции, чтобы увидеть ценность.
  2. Freemium: пользователи получают доступ к базовой версии бесплатно, с платными обновлениями для расширенных функций.
    • Лучше всего для: продуктов с широким спектром функций, где бесплатные пользователи могут обновиться по мере роста их потребностей.

Мы изначально выбрали модель freemium для быстрого запуска, поставив жёсткий платный барьер между бесплатными и платными планами. Однако разработчики не могли получить доступ к расширенным функциям, таким как SSO или Organization, в бесплатной категории.

Хотя в интернете ведется много споров о том, какая модель лучше, важно сделать шаг назад и учесть время активации вашего продукта. Для Logto мы наблюдали, что в реальном мире тестовая фаза может длиться до 6 месяцев. Это не из-за сложности Logto, а в основном из-за рабочего графика инженеров, планирования проектов, рабочих процессов команды и других факторов, которые мы не предвидели.

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

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

Если ты не понимаешь своих клиентов, твой контент будет казаться эгоцентричным

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

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

"В этой статье мы рассмотрим историю пользовательского опыта входа, включая его концепцию, решения по проектированию и компромиссы продукта. Вы также лучше поймёте, как создать успешный и безупречный опыт входа или регистрации." - Наш блог пост 2 года назад Соображения по проектированию безупречного опыта входа (Первая глава)

Я был полон энтузиазма поделиться своими мыслями о наших функциях и дизайне, потому что я приложил много усилий в них. Но, оглядываясь назад, я понимаю, что это то, что можно назвать "самовлюблённым" контентом. Это распространено в устоявшихся компаниях с сильной EPD-культурой (инженерия, продукт, дизайн).

Если вы занимаетесь продуктово-ориентированным ростом (PLG), особенно когда ваш продукт ещё не достиг стадии, когда "о вас говорят люди", необходимо убедиться, что у вашего контента есть чёткая ценность и цель для вашей аудитории. Избегайте быть слишком сосредоточенным на себе.

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

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

Особенности или лучшие практики

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

Два года назад я сосредоточился на построении предложений ценности и создании большого нарратива для нашего продукта. Однако этот подход не всегда находил отклик у аудитории разработчиков.

Early homepage

Посмотрите на страницу, которую у нас была 2 года назад — "Формируя будущее"... Вау!

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

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

Является ли версия с открытым исходным кодом угрозой для коммерческой версии?

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

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

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

Спасибо за чтение, и не стесняйтесь делиться своими впечатлениями и мыслями, если вы работаете над чем-то подобным!