Я product-менеджер в онлайн-сервисе Sitechecker. Наша платформа помогает измерять и отслеживать эффективность продвижения сайтов в органическом поиске Google.
Мы работаем по SaaS-модели. SaaS (software as a service) – модель продажи программного обеспечения по подписке. В данной модели пользователь оплачивает доступ к программе не раз и навсегда, как например в Microsoft Office, а каждый месяц или год. Среди известных продуктов, которые работают по такой модели, – Evernote, Slack, Jira.
Ядро наших клиентов составляют владельцы сайтов, владельцы маркетинговых агентств и специалисты по поисковому продвижению сайтов. Платформой пользуются люди со всего мира, но основные клиенты приходят к нам с США, Великобритании, Нидерландов, Австралии, Бразилии, Франции, России, Канады и Германии.
Успех SaaS бизнесов в основном измеряют по двум ключевым метрикам:
- MRR (monthly recurring revenue) – доход за месяц от всех платящих пользователей, как тех, что пришли в новом месяце, так и тех, кто пришли в прошлые месяцы, но продолжает оплачивать подписку на ваш сервис.
- ARR (annual recurring revenue) – доход за год от всех платящих пользователей, как тех, что пришли в новом году, так и тех, кто пришли в прошлые годы, но продолжают оплачивать подписку на ваш сервис.
Только недавно мы стали платформой, которая объединяет пять инструментов в едином интерфейсе. А началось все 2 года назад с одного небольшого бесплатного инструмента.
Ежемесячный трафик на наш сайт составляет 250 тыс. уникальных посетителей. В команде работает 20 человек. Компания зарегистрирована в Эстонии. За 2 года нам удалось достигнуть отметки в $20 тыс. MRR и 500 платящих клиентов в месяц. Это небольшая цифра для такого типа продукта и для нашего рынка в целом – Gaps, например, весь рынок SEO оценивает в $80 млрд и больше, – но мы видим, за счет каких механизмов мы можем расти далее по выручке и вступить в соревнование с лидерами рынка.
Как зародилась идея продукта
Идеологом и первым менеджером продукта был один из наших SEO-специалистов, который создал на коленке пробную версию инструмента для своих повседневных задач. В процессе продвижения сайта SEO-специалистам часто нужно проводить детальный аудит отдельных страниц сайта по многим параметрам. Это занимает огромный кусок времени, если не использовать инструменты автоматизации. Из этой потребности автоматизации и родился инструмент SEO-анализа страницы.
Вот как выглядел его основной экран с результатами 2 года назад:
А вот в какую платформу превратился продукт:
Проблемы, с которыми мы столкнулись
Расскажу детальнее о проблемах, с которыми мы столкнулись в процессе развития нашего продукта, и как их лучше решать.
1. Длительный поиск бизнес-модели
Проблема. Наш продукт полгода был бесплатным. Мы быстро начали его продвигать и расти по трафику, но все еще не знали, на чем зарабатывать.
На этом этапе у нас было много вариантов, куда развернуть инструмент. Можно было:
- Зарабатывать на оказании SEO-услуг.
- Ограничить количество доступных проверок страниц для бесплатных пользователей и брать деньги за дополнительное количество проверок.
- Создать курс по SEO и продавать доступ к нему.
- Зарабатывать на партнерских программах других SEO-продуктов.
- Создать другой, более ценный продукт и продавать его, а инструмент для анализа страниц оставить бесплатным.
Решение. Мы пришли к последнему варианту, но спустя долгое время. Только в январе 2018 года мы получили первые продажи. А как видно на графике, в декабре 2017 года у нас уже было 32 тыс. уникальных посетителей в месяц. И мы этот потенциал никак не использовали.
Как только пошел первый трафик, нужно запускать параллельный процесс тестирования вашего прайсинга и получение обратной связи от пользователей (с помощью опросов, общения в чате и интервью один на один). Если же ресурс ограничен и вы не можете запустить такой параллельный процесс, то нужно перебросить силы с привлечения трафика на процесс поиска бизнес-модели.
2. Поиск регулярной потребности
Проблема. Первая наша модель, которая начала приносить продажи, была очень простой. Мы привлекали пользователей бесплатным инструментом для аудита отдельных страниц и продавали доступ к инструменту аудита всего сайта.
Вот так выглядела первая версия инструмента для аудита всего сайта:
Эта модель показывала хорошие результаты в плане привлечения новых клиентов, но она слабо подходит для SaaS продукта, где ключом к росту дохода является высокий показатель удержания клиентов. И он у нас был маленький из-за того, что пользователю достаточно проверить свой сайт на ошибки и исправить их. Новая потребность в таком инструменте появится только спустя 3-6 месяцев.
Решение. Мы придумали второй инструмент, потребность в котором для владельца сайта есть всегда – мониторинг сайтов.
Мы четыре раза в день проверяем сайт пользователя, сохраняем хронологию изменений на сайте и в случае критических изменений отправляем клиенту email-уведомление. Такой инструмент ценен сразу в нескольких задачах:
- Помогает увидеть, какие работы ведутся на сайте подчиненными или подрядчиками (и ведутся ли).
- Помогает быстро среагировать на ошибки (выпадение страниц из индекса поисковых систем, удаление или добавление неправильных страниц).
- Помогает оценить, как конкретные изменения на странице повлияли на ее позиции в поисковой выдаче.
3. Конфликт внутреннего и внешнего заказчика
Проблема. Так как инструмент изначально создавался для внутреннего заказчика (им же и оплачивался), с ростом количества внешних клиентов участились споры о том, чьи потребности удовлетворять первыми. Мы пытались их как-то комбинировать, чтобы удовлетворить обе аудитории. Но это только затормозило наш рост.
Решение. Спустя несколько месяцев попыток усидеть на двух стульях, мы приняли решение сфокусироваться только на внешних клиентах. После принятия такого решения и мотивация и результативность команды серьезно выросли, так как сотрудникам не нужно было постоянно разрываться между двумя часто противоположными направлениями. Если у вас возникает похожая ситуация, нужно поставить вопрос приоритетов перед командой как можно раньше.
4. Сложности с приоритезацией задач
Проблема. Гипотезы для экспериментов и задачи по продукту, маркетингу сыпятся с разных сторон (запросы клиентов, личное мнение членов команды, результаты исследований продуктов конкурентов). Сложно все эти задачи приоритизировать и синхронизировать всех членов команды для их поэтапного выполнения, так как большинство задач требует участия двух и больше членов команды: product-менеджер, маркетолог, аналитик, дизайнер, разработчик, тестировщик. Если кто-то медлит с выполнением, тормозится весь процесс.
Решение. Мы пришли к тому, что сначала принимаем решение – на какой высокоуровневой метрике нам стоит сконцентрировать свои усилия в этот месяц-квартал: привлечение клиентов, конвертация клиентов в первый заказ, удержание клиентов. После этого из всего бэклога задач выбираем только те, что помогают улучшить конкретную метрику, и собираемся менеджерами продукта для оценки ценности каждой задачи (от 10 до 100).
После этого project-менеджер, который управляет командой разработки, оценивает ресурсы для каждой задачи и мы вычисляем приоритет по известной формуле «ценность задачи / затраты на ее выполнение». Product-менеджеры ведут все задачи в Airtable, project-менеджер и разработчики ведут задачи в Jira.
5. Сложности с оценкой экспериментов
Проблема. При получении успешных результатов экспериментов часто возникает ситуация, что причина успешности новой версии страницы, дизайна, текста, функции – неизвестная. Чтобы выяснить эту причину, могут понадобиться дополнительные эксперименты – а это затраты ценных ресурсов времени и трафика. В итоге в каждой такой ситуации мы стоим перед выбором – быстрый рост без понимания, что послужило его причиной, или медленное развитие, но с пониманием, что принесло результат.
Решение. Мы приняли решение, что пока мы маленькие, скорость роста для нас важнее. В первые годы важнее скорость итераций. Продукт может много раз поменяться в самые разные стороны, и понимание причин успешности экспериментов в этот период не имеет значения. Но когда продукт становится устоявшимся, базовый функционал, бизнес-модель, позиционирование определены и экспериментов становится меньше, но последствия каждого из них масштабнее, здесь подход должен измениться.
6. Сложности с ценообразованием
Проблема. Как видно внизу на снимке, наши тарифы выстроены на основе четырех основных переменных: количества сайтов и страниц на сайте, количества ключевых слов и обратных ссылок.
Количество вариантов отдельных тарифов, которые можно сформировать на основе этих переменных, просто огромное. Один пользователь работает с сайтом на 200 тысяч страниц, другой со 100 сайтами по десять страниц, и между ними еще тысячи промежуточных вариантов. В этом случае калькулятор тарифов был бы идеальным решением для пользователей, но сложности его реализации были намного больше, чем ожидаемая выгода.
Решение. Первый прайсинг мы создали, полагаясь только на свои представления о том, какие лимиты в тарифах нужны пользователям.
И уже по ходу общения с пользователями, проведения опросов и экспериментов мы пришли к той версии страницы, которая есть сейчас.
В новом прайсинге мы расширили количество сайтов в каждом из тарифов и таким образом начали удовлетворять потребности еще одного дополнительного сегмента аудитории. Отдельные пользователи все еще обращаются к нам за уникальными тарифами, но уже значительно меньше.
7. Сложности с приемом платежей
Проблема. Первые продажи мы получили, используя «решение с коробки» – плагин, который позволяет принимать платежи через PayPal. Мы на этом сэкономили много ресурсов разработчиков, и в первый год такое решение работало хорошо. Но постепенно увеличивалось количество запросов на оплату банковской картой. Особенно много запросов было с России и Турции. Часть таких покупок мы оформляли руками, но это занимало много времени. Плюс, мы понимали, что много клиентов просто уходит, когда видят, что нет удобного способа оплаты.
Решение. Очевидно, что нужно было подключить оплату картами. Но вопрос был в том, какой сервис использовать, чтобы покрыть все необходимые нам страны и функции. Мы были настроены на подключение Stripe, но он только недавно открыл доступ для регистрации компаниям из Эстонии. Поэтому пока не было Stripe, мы подключили Paddle. Спустя время мы увидели, что хоть Paddle и не такой известный, но у него есть ценное преимущество – он включает как оплату картой, так и PayPal (Stripe включает только оплату картой). Для части наших пользователей все-таки важен PayPal из-за своей скорости и широких возможностей возврата средств в случае недобросовестного контрагента.
8. Сложности с поддержкой пользователей
Проблема. Первый год я поддерживал пользователей сам, так как обращений было немного. Я мог это делать параллельно с задачами по маркетингу и продукту. С ростом количества платных клиентов начало расти и количество обращений. Нужно было принимать решение: или снижать качество поддержки, или останавливать свою активность в роли маркетолога и полностью заниматься поддержкой, или нанимать менеджера по работе с клиентами.
Решение. Кажется очевидным, что в этом случае лучше нанять менеджера для работы с клиентами. Но для любого стартапа с ограниченным месячным бюджетом это не всегда верное решение. Да, функция поддержки пользователей – одна из ключевых и SaaS продукты не могут без нее существовать. Но на первых этапах базовые задачи поддержки можно реализовать с помощью детальных подсказок внутри сервиса, детальных видео и текстовых инструкций, форума или сообщества, где пользователи будут сами помогать друг другу. И тогда бюджет, выделенный на менеджера по работе с клиентами, можно потратить на привлечение новых пользователей. Мы наняли такого специалиста только тогда, когда стало очевидно, что без этой роли мы не сможем далее расти и увеличивать процент удержания клиентов.
Какие у нас сейчас задачи
У нас все еще низкий процент удержания клиентов. Мы сконцентрировались:
- На глубоком исследовании клиентов, которые с нами уже длительное время, чтобы выявить, в чем для них основная ценность продукта и что бы они хотели изменить в продукте.
- На донесении до новых клиентов тех самых ценных функций, за которые нас любят самые лояльные пользователи.
Всегда хочется универсализировать продукт как можно больше, чтобы захватить больше клиентов с разными потребностями. Но в этом случае есть большой риск, что вы проиграете узкоспециализированным продуктам, которые лучше закрывают каждую отдельную потребность.
Поэтому основное, чему я научился за это время, – это всегда создавать структуру продукта с заделом на то, что он будет частью большого продукта, но не спешить улучшать все подпродукты, а стать первым в одном инструменте, и только потом переходить к следующему.
Текст участвует в конкурсе «Историй успеха»
Читайте также: