Уроки и практики, извлечённые из продвижения роста Logto среди разработчиков.
Logto — это продукт с открытым исходным кодом, ориентированный на разработчиков. Вот наша хронология выхода на рынок:
Имея опыт в продуктово-ориентированном росте для инструментов повышения производительности, команды и я пробовали различные стратегии выхода на рынок для Logto. После двух лет я проанализировал эти усилия и шаги, которые мы предприняли. Я хочу поделиться частью этого пути и объяснить, почему некоторые вещи не работали в то время. Это не "ошибки", а ценные уроки из нашего опыта. Я надеюсь, что эти инсайты помогут другим, работающим над подобными проектами или стартапами.
Когда вы впервые запускаете свой продукт, особенно с продуктово-ориентированным мышлением или с определённым опытом, легко придумать всевозможные захватывающие идеи: изящные потоки онбординга, отличный демо-показ на сайте, классные способы подчеркнуть ценность для пользователей и быстро довести их до момента "ага". Чтобы сделать наш продукт более проработанным и готовым к коммерциализации, я внедрил две стратегии активации:
Эти стратегии были очень успешными в моём прошлом опыте. Поэтому, когда Logto запустил свою облачную версию, я применил их немедленно. Однако я столкнулся с некоторыми путаницами и проблемами:
Для разработческих продуктов сложно решить проблему за короткое время, даже если это действительно удобно для самообслуживания. Даже для одного разработчика процесс включает несколько этапов: интеграция с правильным технологическим стеком, создание концептуального доказательства, тестирование в среде разработки, а затем переход к эксплуатации. На любом этапе этого пути пользователи могут перейти на другой этап. "Задача, которую нужно выполнить" — это не простая, одношаговая задача. Потребности разработчиков часто складываются из сложных требований, нуждающихся в широкой функциональности или технических сценариях, которые требуют внимательного проектирования, учитывающего наши существующие возможности. Решение таких проблем требует времени и не может быть поспешным.
Оглядываясь назад, становится ясно, почему этот подход не удался. Когда мы впервые запустили продукт, наши ежедневные регистрации и органический трафик были довольно низкими. Большая часть нашего трафика поступала из сообщества с открытым исходным кодом, что естественным образом не привлекало крупных клиентов. Неудивительно, что на этом этапе мы не видели большого количества крупных клиентов, бронирующих звонки. Низкий трафик и источник наших пользователей сделали ожидания значительного числа бронирований звонков на раннем этапе нереалистичными.
Выберите модель, которая соответствует вашему продукту, основываясь на времени, необходимом для активации пользователей. Не позволяйте отраслевым нормам ограничивать вас.
При создании SaaS-продукта одним из ключевых вопросов для выхода на рынок (GTM) является выбор между freemium или бесплатной пробной версией. Общепринятое мнение предполагает:
Мы изначально выбрали модель freemium для быстрого запуска, поставив жёсткий платный барьер между бесплатными и платными планами. Однако разработчики не могли получить доступ к расширенным функциям, таким как SSO или Organization, в бесплатной категории.
Хотя в интернете ведется много споров о том, какая модель лучше, важно сделать шаг назад и учесть время активации вашего продукта. Для Logto мы наблюдали, что в реальном мире тестовая фаза может длиться до 6 месяцев. Это не из-за сложности Logto, а в основном из-за рабочего графика инженеров, планирования проектов, рабочих процессов команды и других факторов, которые мы не предвидели.
Учитывая этот длительный период активации, важно предоставить разработчикам полный доступ ко всем функциям для тестирования. Поэтому мы полностью используем среду развертывания для открытия всех возможностей продукта. Это распространенная практика для инструментов для разработчиков, но стоит отметить, так как она объясняет, почему традиционные стратегии freemium или бесплатной пробной версии могут не сработать для нас.
Выбор должен согласовываться с природой вашего продукта и его графиком принятия. Поймите уникальные характеристики вашего продукта и выбирайте модель, которая подходит — а не ту, которая пытается слишком быстро провести пользователей через вашу воронку конверсий.
Выполнение стратегии выхода на рынок с низу вверх часто включает SEO, маркетинг продукта и контентный маркетинг. Мы все знаем, что начинать важно на ранней стадии, поэтому мы начали создавать контент сразу после запуска версии с открытым исходным кодом. Но когда мы впервые решили писать статьи, у меня возник большой вопрос: О чём я должен писать?
Как продуктовый дизайнер, мой инстинкт говорил мне писать о том, почему мы создали определённые функции, объясняя процесс мышления и философию, стоящую за ними.
"В этой статье мы рассмотрим историю пользовательского опыта входа, включая его концепцию, решения по проектированию и компромиссы продукта. Вы также лучше поймёте, как создать успешный и безупречный опыт входа или регистрации." - Наш блог пост 2 года назад Соображения по проектированию безупречного опыта входа (Первая глава)
Я был полон энтузиазма поделиться своими мыслями о наших функциях и дизайне, потому что я приложил много усилий в них. Но, оглядываясь назад, я понимаю, что это то, что можно назвать "самовлюблённым" контентом. Это распространено в устоявшихся компаниях с сильной EPD-культурой (инженерия, продукт, дизайн).
Если вы занимаетесь продуктово-ориентированным ростом (PLG), особенно когда ваш продукт ещё не достиг стадии, когда "о вас говорят люди", необходимо убедиться, что у вашего контента есть чёткая ценность и цель для вашей аудитории. Избегайте быть слишком сосредоточенным на себе.
Например, вместо того чтобы сосредотачиваться на том, почему была разработана функция, создавайте образовательные статьи, которые объясняют конкретные термины, или учебные пособия, показывающие, как интегрировать классную технологию или инструмент для решения распространённой технической проблемы.
По мере того как вы больше узнаете о своём продукте и своих клиентах, вы естественным образом разработаете сильные мнения о том, что действительно важно для вашей аудитории. Сохранение "ориентированного на клиента" подхода поможет вам улучшить качество контента. Со временем вы сможете писать контент, который резонирует с вашей аудиторией. В противном случае ваш контент рискует показаться самовлюблённым.
Традиционный маркетинг часто подчеркивает "лучшие практики" или "решения" при продаже бизнесам или отдельным людям, основываясь на идее, что продукты SaaS в первую очередь способствуют эффективности и продуктивности. Многие стратегии сосредотачиваются на числах, показывающих экономию средств, чтобы подчеркнуть преимущества. Хотя это может хорошо работать для зрелых компаний с широкой клиентской базой, это может отталкивать разработчиков.
Два года назад я сосредоточился на построении предложений ценности и создании большого нарратива для нашего продукта. Однако этот подход не всегда находил отклик у аудитории разработчиков.
Посмотрите на страницу, которую у нас была 2 года назад — "Формируя будущее"... Вау!
Когда дело доходит до удовлетворения разработчиков и решения их проблем, нужно быть очень практичным и приземленным. Разработчики не поддаются влиянию высоких выгод; они заботятся о наличии функций и гибкости — в частности, насколько легко ваш продукт может интегрироваться в их существующий технологический стек. Если это не возможно, не пытайтесь его продавать.
Теперь наша стратегия контента стала намного более сфокусированной. Мы подчёркиваем конкретные функции, которые мы предоставляем, позволяя пользователям быстро понять, что мы предлагаем с первого экрана, без опоры на слова-модули или высокоуровневые сообщения.
Когда мы впервые запустили нашу хостинговую коммерческую версию, в команде всегда шли бурные обсуждения: нанесёт ли открытый исходный код вред нашей хостинговой версии, так как она бесплатна, а наша целевая аудитория — разработчики? Мы также обсуждали, стоит ли ограничивать некоторые из наших расширенных функций в версии с открытым исходным кодом.
На данный момент мы сохранили основные функции как в версии с открытым исходным кодом, так и в хостинговой версии почти одинаковыми. Рост нашего сообщества с открытым исходным кодом значительно укрепил доверие среди корпоративных клиентов, и всё больше крупных компаний присоединяются. Интересно, что некоторые из этих предприятий начинали как разработчики в нашем сообществе. Это придало нам большую уверенность. Пока мы продолжаем создавать отличные продукты, предоставлять превосходные услуги и помогать разработчикам решать их проблемы, будь то через самостоятельный рост или прямые корпоративные продажи, успех придет естественным образом.
В конце концов, всё сводится к решению проблем разработчиков, будь то через продукт или услугу. Оставайтесь терпеливыми и сосредоточенными, и всё само по себе встанет на свои места.
Спасибо за чтение, и не стесняйтесь делиться своими впечатлениями и мыслями, если вы работаете над чем-то подобным!