Как продолжать растить зрелый продукт, когда точечные оптимизации не помогают? Большие инициативы с большими рисками (Дмитрий Орлов)

Дмитрий Орлов, Lead Product Manager, Head of Product Growth, Wrike

Привет! Меня зовут Дима, я работаю в компании Wrike последние пять лет в роли Head of Product Growth. Wrike — это система управления проектами и коллаборацией. Она достаточно сложная, гибкая. Это больше платформа, чем решение. Больше 20 000 организаций из 140 стран сейчас работают в Wrike. Среди них Google, Airbnb, Ogilvy и многие другие крутые чуваки, которых я не могу назвать.

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

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

Более того, приходят новые дерзкие конкуренты, начинают отъедать твой рынок, и это тоже создает отдельный челлендж для роста.

Рост обычно связывают с какими-то оптимизациями. Например, у нас есть фичи, в которых заключена ценность для пользователей. У нас есть бизнес-модель. Теперь, чтобы расти, нам надо увеличивать активацию, улучшать retention, монетизацию, и так далее.

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

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

Или, например, как у нас было в прошлом году — глобальный редизайн, который решает сразу множество проблем, но при этом противоречит привычкам текущих пользователей. Поэтому это сложный, большой проект. Обычно эти проекты связаны с большим количеством рисков, но при этом reward сильно больше, чем от локальных оптимизаций.

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

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

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

С ростом организации чтобы постоянно релизить такие большие проекты, нужно настраивать специфические процессы. И вначале, когда вы еще небольшие, и когда вы можете между собой договориться, сделать какое-то большое изменение, это все намного проще. А когда у вас уже больше 1 000 человек в команде, и каждый говорит на своем языке, и не только в том смысле, что native speakers говорят на разных языках, но и в том, что везде используются свои термины, свои культурные принципы, появляется куча проблем. Из-за них релиз больших проектов тормозится.

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

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

Вторая проблема: решения каких-то trade-off, которые постоянно появляются в рамках работы над таким проектом, затягиваются, потому что это требует долгих нездоровых дебатов на уровне разных специалистов.

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

Четвертая проблема: откаты или какие-то изменения на поздних стадиях проекта. Давайте рассмотрим каждый из этих четырех проблем детально.

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

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

Что делать, чтобы этого не происходило? Нужно иметь рутину, которая связывает проекты со стратегией компании. Я потом подробно расскажу, как это происходит у нас в Wrike.

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

Вторая проблема — это нездоровые дебаты о trade-off. Это приводит к тому, что проекты тормозятся, потому что затягиваются решения между стейкхолдерами. Происходит это обычно, потому что есть конфликт цели и интересов на уровне межфункциональных команд, например, маркетинга и продукта. У них разные цели, разные скоупы, разные свои локальные метрики. Но при этом, чтобы двинуть какой-то большой проект, нужно участие и тех, и других. Но он может быть так спроектирован, что он приносит ценность именно на уровне целей продуктовой организации, но почему-то вредит маркетинговой организации. Тогда происходит нездоровый trade-off, и тут надо принять решение.

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

Во-первых, хорошо, когда есть четкие принципы для принятия решения о trade-off. Они обычно следуют из понимания целей того или иного большого проекта, а цели обычно связаны с какими-то конкретными метриками. Поэтому мы опять возвращаемся к рутине, когда есть четкое планирование, на уровне стратегии мы хотим достичь определенных показателей для бизнеса. И успех определенного большого проекта оценивается именно в рамках достижения результата по этим показателям. Это помогает принять сложное решение на уровне trade-off, потому что понятно, какой главный приоритет для этого проекта.

Вторая история: должно быть пространство для принятия такого рода решений. В нашей практике в Wrike есть так называемые Tiger teams. Это команды межфункциональных специалистов, там может быть и продукт, и маркетинг, sales, и так далее. Они следят за определенным большим проектом, и у них есть достаточно контекста, чтобы помочь принять в рамках этой группы решение о trade-off. И они встречаются регулярно — каждую неделю или каждые две недели. То есть всегда есть площадка для того, чтобы, если какое-то количество таких решений накопилось, их можно было принять.

Я знаю, что в других организациях есть еще другие, специфические процессы для этого. Например, где-то пишут специальный документ. Если есть какое-то сложное trade-off-решение, которое требует нескольких стейкхолдеров, то пишется специальный документ с опциями, и там просят прокомментировать или одобрить всех, кого это решение касается. До тех пор, пока такой документ не будет написан, не будет принято решение. Но такие документы быстро пишутся, и все готовы на них быстро реагировать.

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

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

Следующая проблема — это непонимание стейкхолдерами деталей проекта. Это приводит к тому, что координация действий других департаментов затягивается, из-за этого проекты затягиваются.

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

Я покажу примеры, как это организовано в Wrike, вернусь к этому чуть позже.

Второй инструмент — это синхронный механизм коммуникации планов вовне продуктовой организации. У нас такой есть, он называется релиз-календарь.

И третья история: нужно иметь площадку для обсуждения межфункциональных вопросов с командами. Я уже говорил про Tiger teams в нашем случае. Кроме того, что эта площадка используется для решения вопросов, она также используется и для коммуникаций последнего статуса и принятых решений по проекту для этих специалистов, и они уже могут распространять дальше по департаментам, которым это важно.

У нас есть две ключевых структуры планирования целей и создания прозрачности. У нас есть продуктовые OKRs разного уровня. Каждый окиар с каким-то стратегическим треком. Каждый objective определенного уровня включает в себя какое-то количество OKRs и релизов.

Релизы — это конкретные инкременты, которые мы хотим сделать в рамках квартала, и у них может быть какой-то тип релиза, так как мы используем так называемый gate-stage approach. В зависимости от сложности и от рисков, связанных с релизом, у нас могут быть разные этапы. То есть мы можем сначала делать релиз на ограниченную аудиторию в виде какого-то регионального теста, и так далее, и только в конце он будет публичным. Все это открыто на уровне организации, всегда видно, какая команда над чем работает, и как это связано с overall стратегией, почему определенные релизы важны, и как они помогут определенным стратегии и метрикам.

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

Есть история про откаты и серьезные изменения на поздних стадиях. Это топ, потому что это потеря очень дорогого времени работы над большим проектом, а также демотивация команды. Происходит это зачастую по двум причинам: либо потому что у топ-менеджмента не было достаточно visibility и buy-in в определенные большие проекты. И под конец для них это раскрывается, и они не верят в результат. Либо потому что всплывает какая-то важная межфункциональная зависимость, которая не была учтена заранее, и которую надо решить, откатившись на более ранние этапы проекта.

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

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

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

Я хочу еще немного рассказать о том, как мы работаем в Wrike. У нас есть куча особенностей, которые делают эту работу достаточно сложной. У нас много людей — более 1 000 человек. У нас межкультурная команда, несколько офисов по всему миру. Работаем со специалистами из разных часовых поясов, которые говорят на разных языках. И зачастую мы, находясь в России, должны часто синхронизироваться со специалистами из Штатов. И у нас очень много customer facing-специалистов — наверное, половина организации — которым нужно знать про все изменения в продукте заранее, чтобы уметь с ними работать с клиентами.

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

Тут у меня есть схема, где я рассказываю о разных инструментах, которые мы используем: артефакты, ивенты в продуктовой организации и ивенты на уровне кросс-функциональных команд.

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

На уровне продуктовых команд и на уровне квартала у нас происходит планирование OKRs, и релизов, которые называют gate-stage релизами. Они могут быть разными в зависимости от этапа проекта. Окиар-планирование у нас происходит в таком OKR-дереве. На самом деле у нас несколько уровней objectives. И каждый objective обязательно связан со специфическим треком, который определен на предыдущем уровне.

Это все открыто для всей организации, кто угодно может посмотреть OKRs всей компании, это все делается в Wrike. И в рамках каких-то ивентов, связанных с этим, у нас есть ревью OKRs, когда команды рассказывают об успехе достижения определенных OKRs друг другу раз в квартал. И у нас есть еще множество явных синхронизаций с командами разработки. У нас есть продуктовый апсайд, где мы обсуждаем, как определенные OKRs в рамках квартала связаны со стратегией, почему и что мы будем конкретно делать. И потом мы это рассказываем на all-hands командам разработки.

В рамках работы с кросс-функциональными командами в этот момент начинается так называемое go-to-market планирование. На уровне квартала выделяются самые важные ключевые инициативы и под них собираются команды кросс-функциональных специалистов, которые будут еженедельно или каждые две недели следить за этим проектом и помогать ему. По сути, выделяются ресурсы маркетинговой и sales-организации на поддержку каких-то больших важных релизов.

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

У нас есть специальные ивенты в рамках продуктовой команды.

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

Также у нас есть ивенты, которые называются solution reviews. Под них у нас в календаре есть специальные слоты. На них люди, ответственные за определенный релиз в зависимости от этапа релиза, могут рассказать какой-то концепт с целью собрать обратную связь и рассказать другим командам, которые могут быть в это вовлечены, детали планируемого релиза. На этих solution reviews зовутся люди, которых выбирает сам owner, исходя из того, кого нужно вовлекать под этот кросс-функциональный релиз.

Также у нас есть ивент для основной организации, которая называется Product roadmap update. Он происходит раз в месяц, и на нем все лиды продукта рассказывают, что изменилось за последний месяц, и что планирует меняться в следующем месяце для всей организации, чтобы они могли задать вопросы. Это обязательная рутина, чтобы они знали, что меняется, чтобы у них была привычка возвращаться к этому.

И на самом низком уровне у нас происходит Agile работа в командах, и там мы оперируем спринт-бэклогом, целью спринта. В рамках двухнедельного спринта всегда есть какая-то локальная цель, то есть мы хотим добиться какой-то ценности, но это всегда какая-то маленькая составляющая у большого кросс-функционального проекта, над которым мы можем работать от одного до нескольких кварталов. И в рамках этого спринта у нас всегда есть спринт-ревью. Также раз в месяц у нас есть multi demo — это расширенное спринт-ревью, на которое приходит больше людей. Просто раз в месяц ходить на него легче, и там мы рассказываем о результатах месяца.

И в рамках работы с кросс-функциональными специалистами у нас есть Tiger teams-встреча, где для самых крупных и важных релизов разруливаются какие-то межфункциональные вопросы, или обсуждается статус этой инициативы.

И это все называется agile at scale — это большая классная история, как это все может работать в больших организациях.