У нас была команда из 10 человек на весь бренд. Например, развитием Selectel на тот момент занималось более 400 человек из разработки, продаж и маркетинга. Поэтому нам приходилось очень внимательно выбирать, какие фичи и улучшения стоит делать сейчас для роста продукта, а какие — откладывать на следующие итерации.
Кроме того, в индустрии облачного хостинга есть набор ожидаемых пользователями возможностей, без которых невозможно конкурировать. Зачем пользователю тратить своё время на переезд к другому хостингу, если у его текущего есть всё то же самое? Это ограничивало пространство для экспериментов: мы не могли бесконечно заниматься тестированием, потому что параллельно должны были расширять набор базовых услуг.
В отличие от B2B-ориентированных облачных продуктов, у нас не было отдела продаж. Поэтому продукт должен был «продавать» себя сам — через контрольную панель, цены, UX, продуктовые возможности и дружелюбную коммуникацию.
Ещё мы были ограничены в маркетинговых ресурсах, так как основной бюджет и лучший трафик доставался основному бренду Selectel. Поэтому мы сфокусировались на эффективности пользовательской воронки — работали в разы лучше нашего основного бренда и конкурентов.
Как можно быстрее расширить клиентскую базу и выйти на прибыль, чтобы получить инвестиции в развитие продукта и услуг и улучшение пользовательского опыта.
Самыми важными показателями для нас были:
За 8 месяцев беспрерывного discovery и delivery нам удалось почти в 2 раза улучшить 4 основные метрики. Удалось нам это практически случайно. Например, над некоторыми фичами мы работали от 3 до 6 месяцев, и они не дали ожидаемого роста. С другой стороны, парочку простых в разработке решений дали самые выдающиеся результаты.
Главный вывод для меня: не бояться экспериментов и быстрых решений. В процессе ты неизбежно будешь ошибаться, что-то не взлетит, но именно через такой опыт можно найти неочевидные точки роста, в которые изначально мы сами не верили. Главное — не переставать пробовать.
вырос показатель привлечения новых пользователей. В нашей терминологии это доля новых посетителей панели управления, которые регистрируются и проходят регистрацию до конца.
Желаемый результат был 10%
вырос показатель активации — то есть количество зарегистрированных пользователей, которые начинают пользоваться нашими услугами, включая бесплатные.
Желаемый результат был 90%
вырос показатель платной активации. Эта метрика показывает, сколько зарегистрированных пользователей пополняют баланс и становятся платящими клиентами.
Желаемый результат был 60%
Как дизайнер продукта, я считаю, что измерять влияние дизайна на бизнес критически важно — и для профессионального роста, и для развития продукта. На старте проекта я увлекался фреймворками Lean UX, Outcome-Driven UX Metrics и Growth-led UX. Полный вдохновения, я пришёл к менеджеру продукта и владельцу продукта обсудить наши цели и проблемы. Дальше я отправился думать, как дизайн может помочь команде и продукту достичь ожидаемых топ-менеджментом результатов.
Я собрал ключевые метрики, которые менеджеры использовали для отчётности перед «топами», и начал переводить их в UX-метрики. Для этого я использовал подход Джареда Спула — Outcome-Driven UX Metrics. Если коротко, этот фреймворк предлагает формулировать метрики не как сухие изменения в процентах, а как измеримый и амбициозный результат. То есть вместо таких:
Конверсия в регистрацию улучшена на 40%.
Хорошие метрики должны звучать так:
🎉 Мы отпразднуем, когда через год после запуска Vscale 10 000 пользователей смогут найти инфраструктурное решение для своего проекта.
Или
🎉 Мы отпразднуем, когда 60% зарегистрированных пользователей станут пополнять баланс и платить за наши сервисы в течение 30 дней после регистрации, а к этому результату мы придём в течение 6 месяцев после запуска.
После того как я согласовал метрики с менеджерами, я начал отслеживать их ежемесячно. Тут не обошлось без трудностей. У нас не было продвинутых систем аналитики вроде Amplitude, Google Analytics или PostHog. В моём распоряжении была только Яндекс.Метрика с двумя событиями на регистрацию и заказ серверов — они существовали сугубо для пользования маркетологами. Остальное приходилось вылавливать через вебвизор или напрямую из базы данных. Свободного времени разработчиков на внедрение событийной аналитики у нас не было.
В начале каждого месяца я собирал встречу с PO, PM, PMM, Customer Success Manager и вторым дизайнером в команде, чтобы обсудить результаты прошлого месяца. За полуторачасовую сессию мы разбирали, что помогло нам улучшить метрики в прошлом месяце. В том числе, где мы ошиблись или ничего не сделали, вследствие чего показатели ухудшились. К концу встречи пересобиралось планирование задач на следующий месяц или квартал, чтобы сфокусироваться на улучшении приоритетных метрик.
<aside> 💡
Полученный опыт
Цели и метрики могут меняться со временем. Я не рекомендую на старте перегружать себя и команду длинным списком UX-метрик. Например, в самом начале у нас было 17 метрик, а реально важных — 6 штук. Мы потратили много времени и энергии на измерение и обсуждение метрик, которые в итоге не повлияли на наполнение бэклога и релизы.
</aside>