Wrike: о стратегии, масштабировании продукта и нетипичном подходе к OKR

Продуктовая команда Wrike в рамках проекта Epic Talks от Epic Growth Conference рассказала, какой системы OKR придерживается компания, чтобы достигать высоких результатов, с какими трудностями сталкиваются при масштабировании продукта и как стратегически их решают.

В проекте приняли участие Алексей Коротич, VP of Product в Wrike, Антон Данилов, Lead Product Manager Enterprise, и Алексей Смирнов, Product Analytics Team Lead.

Алексей Коротич: Wrike — это облачный сервис для совместной работы и управления проектами, которым пользуются компании со всего мира, начиная от небольших команд из 5–20 человек и заканчивая такими крупными клиентами, как Airbnb, Western Union, Sony.

За последний год мы значительно выросли с точки зрения клиентской базы, и скорость прироста клиентов год от года только увеличивается. Также мы выпустили большое количество продуктовых релизов. Среди них — новая версия нашего флагманского продукта Wrike for Marketers.

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

Антон Данилов: Продуктовое enterprise-направление для нас нетипичное в том смысле, что мы в рамках него гораздо меньше, чем по другим направлениям, делаем какие-то продуктовые фичи или доработки. В enterprise мы занимаемся формированием платформы, на которой базируется всё то, что потом работает в продукте.

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

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

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

Как устроена продуктовая команда Wrike?

Алексей Коротич: Продуктовая команда Wrike состоит из более чем 40 человек, в ней можно выделить три функциональные роли: продуктовые менеджеры, продуктовые аналитики и UX-дизайнеры.

Среди них идёт деление по направлениям, фиче-командам, которые построены исходя из определённой бизнес-цели или сегмента пользователей, с которыми команда работает.

Одно из направлений — как раз enterprise-направление, которое работает с большими клиентами с большими командами. Например, в сore-направлении фокус на улучшение пользовательского опыта среднего пользователя Wrike.

Всего около 20 фиче-команд и направлений. И внутри каждого из них команда — это независимая самостоятельная единица, которая способна выстраивать продуктовые планы и реализовывать их в течение квартала и года, используя все имеющиеся ресурсы. Например, как конкретно это работает в enterprise, расскажет Антон.

Антон Данилов: Enterprise-направление предполагает совместную работу команды над стратегией. Мы продумываем, каким образом будем «атаковать» и выводить продукт на рынок, определяем его сильные и слабые стороны.

В каждом из векторов «атак» мы создаём сбалансированную дорожную карту, с помощью которой итеративно и стратегически достигаем поставленных целей.

Как устроен процесс работы с удалёнными командами?

Алексей Коротич: Продуктовая команда находится в основном в Санкт-Петербурге, и при этом мы работаем с огромным количеством таких функциональных команд, как продуктовый маркетинг, sales, customer success.

Команды, которые ближе к бизнесу, — sales, customer success — в основном находятся в наших международных офисах в Дублине, Сан-Хосе, Сан-Диего, Мельбурне, Токио. Мы как продуктовая команда взаимодействуем со всеми отделами на ежедневной основе.

Поделитесь опытом работы по системе OKR

Антон Данилов: Система OKR, по которой работаем мы, несколько отличается от классической. Мы считаем: если слепо следовать стандартной системе, можно попасть в ловушку. Формализм в постановке целей может привести к тому, что эти цели окажутся нерелевантными.

Мы же заранее продумываем, какие метрики должна выполнить конкретная продуктовая группа. Это помогает командам фокусироваться на наиболее важных (релевантных) целях. А главное, OKR всегда строится в виде полного дерева, где в основе стоят цели компании, заканчивается всё целями конкретного сотрудника.

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

Алексей Коротич: Если говорить про улучшение рабочего процесса, то мы выделяем наши ключевые результаты. Продактами Wrike они толкуются по-разному. Можно, например, в качестве ключевого результата поставить конкретный продуктовый релиз, а можно — бизнесовую метрику, и здесь нет правильного на 100% решения.

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

Используете продуктовый подход к самим себе?

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

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

Как настроены процессы в отделе аналитики?

Алексей Смирнов: Команда аналитиков децентрализована. Она включает три отдела: бизнес-аналитику, отдел продуктовой аналитики и data engineering.

В задачи бизнес-аналитиков входит работа для организации customer facing (sales, customer support, customer success). Мы очень быстро растём и сильно вкладываемся в маркетинг.

Тут возникает классическая проблема — ограниченное количество ресурсов, то есть менеджеров по продажам, для обработки воронки входящих лидов. Бизнес-аналитики помогают приоритизировать лиды, чтобы менеджер по продажам, придя с утра на работу, открыл свою CRM и увидел уже отсортированный по ценности для компании список лидов, которые нужно обработать в первую очередь.

Среди задач, которые выбраны на квартал и в которых участвуют продуктовые аналитики, есть стратегические, влияющие на бизнес. Ещё на этапе их приоритизации мы продумываем набор формальных KPI.

Благодаря этому мы быстро понимаем, что движемся именно к тому результату, ради которого выполняются эти задачи. Далее, когда определились с ориентирами, начинается девелопмент, где подключается операционная поддержка продуктовых аналитиков. Так решаются вопросы, которые касаются трекинга и анализа продуктовых инициатив.

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

Как принимаете решение на основе метрик?

Антон Данилов: Команды ведут еженедельный сompany wide — отчёт, где собираются истории со всего продукта и со всей компании. Есть продуктовые истории, есть аналитические, есть инженерные.

Если отдельно рассматривать команду аналитиков, то ребята пишут настоящие analytic stories, где дают анализ краткосрочных итогов, например, после выхода релиза. Смотрим именно на глубину поведения пользователя.

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

Аналитический отдел предложил провести анализ распределения по людям: сколько людей сужают роли, сколько расширяют, а сколько оставляют неизменными.

Оказалось, что 30% клиентов либо расширяли роли, либо сужали. Это подтолкнуло нас к мысли, что пора менять функцию управления ролями и дать возможность это делать самим пользователям.

И вот такие развёрнутые истории, где даётся качественный вывод из аналитической информации, — действительно очень крутой процесс.

Как повернуть команду в сторону цифр?

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

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

Какие продуктовые эксперименты проводите?

Алексей Смирнов: Эксперименты в нашей работе не так часты, один или два в месяц. Поясню, почему так мало экспериментов.

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

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

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

Пару лет назад наша команда аналитиков разработала механизм, который называется QFF (Quality Feedback Form). QFF помог наладить двустороннее взаимодействие с пользователями: когда человек совершает какое-либо действие внутри продукта, а позже мы задаём ему релевантные вопросы и получаем от него обратную связь.

Так есть понимание, насколько пользователь сейчас удовлетворён продуктом, как и в чём его можно улучшить, доработать.

Примеры удачных и неудачных экспериментов?

Антон Данилов: Когда мы ставим эксперименты, мы следуем двум направлениям.

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

Второе направление относится к категории экспериментов, объясняющих, каким образом необходимо что-то улучшить в продукте.

Здесь же про эксперименты, направленные на конверсию. И тут возникает проблема. Wrike — b2b-инструмент, и чтобы получить первые изменения в конверсии, должно пройти много времени.

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

Одна гипотеза помогла сделать очередной эксперимент частью нашего продукта — onboarding templates. Мы разработали несколько сценариев использования продукта. Это помогло пользователю наглядно увидеть, как разные инструменты продукта могут работать единым механизмом. Для этого проводилась целая серия A/B-тестов, и уже при первом эксперименте мы увидели значительный прирост конверсии.

Больше контента по продуктовому маркетингу — в Telegram-канале.

#продактменеджмент