Стейкхолдер-менеджмент: как быстрее и эффективнее принимать продуктовые решения на масштабе

Ксения Аполонская, Growth Product Manager, Miro Суперклассно видеть знакомые лица в офлайне, первая конфа за долгое время офлайн. Этот контент скорее для Middle PM, если здесь есть Senior, не уверена, что узнаете что-то новое. Моя тема — стейкхолдер менеджмент: как помогает грамотный он быстрее принимать продуктивные решения на масштабе. Я хочу поделиться подходом, который мы используем в Miro. Мы его немного изменили за последний год, потому что выросли очень сильно — мы выросли с 300 до 750 человек и с примерно 5 млн до 15 млн зарегистрированных пользователей. Поэтому по ходу прошлого года мы поняли, что пора операционализировать некоторые процессы, менять подходы. Сильно выросли ожидания от продактов компании, и, конечно же, выросло количество стейкхолдеров. Это наши продуктовые команды. По-моему, у нас чуть более 30 PM сейчас и джуниоров у нас нет, пока что мы набираем только ребят с опытом. Я работаю в команде Growth, большая команда. У нас есть core продукты, есть продукт growth. Фокус моей команды на экспериментах, мы занимаемся конверсией, экспеншеном, выручкой, также поддерживаем наш прайсинг и флоу покупки; делаем механики Value First, когда мы сначала даем ценность пользователям, а потом просим их купить продукт; и стратегия монетизации фичей. По этому списку понятно, что людей, которые хотят поучаствовать в решениях вокруг этих вещей, довольно много. И это так и есть. У меня достаточно много стейкхолдеров, поэтому я постараюсь поделиться максимально практическими советами, что помогает мне в работе. Почему эта тема важна? Во-первых, product launch зависит от грамотной коммуникации. Ни один продакт не хочет, чтобы его релиз сорвался из-за того, что в executive команде кто-то был не в курсе. Во-вторых, грамотная коммуникация позволяет расти профессионально. И если не делать коммуникацию грамотно, то можно в какой-то момент упереться в стеклянный потолок и как будто приостановить свой карьерный рост. А мы этого не хотим. Кого я называю стейкхолдерами? Конечно, это не только руководители, это инженерные лидеры, это продакты других стримов и команд, все, с кем у вас есть зависимости. И, если вкратце, это все те люди, с которыми вам нужно попасть, погрузиться в один контекст и с кем вам нужно договориться перед стартом. На этой картинке показано некое противостояние. У нас слева есть продукт, пользователь, бизнес-проблемы, delight, дизайн. А справа есть инжиниринг, который спрашивает, как мы с этим всем будем взлетать, есть legal, который говорит, что у нас есть новые регулировки, все это нужно поддерживать, чтобы это перформило, доски быстро грузились и так далее. Это мнимое противостояние очень ценное, потому что смысл привлечения людей из других функций в том, чтобы решение, к которому вы в итоге придете, было максимально качественным. Про этих людей можно думать как про RACI наоборот. Помните, RACI — responsible, accountable. Как будто перед кем я responsible, accountable, с кем мне нужно проконсультироваться, кого нужно проинформировать. Это репит, это фреймворк Bain, есть ссылка в презентации на статью, где можно почитать побольше, она примерно про то же самое. Есть люди, которые порекомендуют вам решения или курс действий, тех, кто должен их формально заапрувить и так далее. В середине D — decide. Скорее всего, это — вы, человек, который принимает решение. Как понять, есть ли у вас проблема со стейкхолдер-менеджментом? Есть пара сигналов. Если вы получаете сопротивление даже по каким-то маленьким решениям и шагам, это значит, что на шаг назад вы не выровняли контекст с людьми, с которыми вы работаете, и вам нужно вернуться на этот шаг и все ожидания и контекст проговорить еще раз. Если вам пишут и спрашивают апдейты, что происходит, какой статус — это тоже означает, что вы коммуницируете недостаточно, и, возможно, нужно поработать в эту сторону. И если стейкхолдеры в принципе не в курсе, чем занимается ваша команда, и какие у вас результаты, это тоже не есть хорошо для Senior Product Managers. Вообще умение грамотно транслировать, обеспечить прозрачность принятия решений на каждом шаге и получить правильные вводные на каждом шаге, когда вы придумываете решение — это отличает Junior от Senior PM. Представим, что мы начинаем большую инициативу, какой-то проект. Мы готовим новый функционал, фичу, может быть, даже запускаем новый проект. Посмотрим, как выглядит коммуникация на каждой стадии, и какие ожидания есть от продакт-менеджеров на каждой стадии. В начале большого проекта, особенно если вы новый человек или человек в быстрорастущей компании, может быть, ты даже не знаешь всех стейкхолдеров. Самая простая вводная — спросить своего менеджера, кто те пять человек, кого мне нужно обязательно включить, с кем мне нужно обязательно поговорить, прежде чем я выберу какое-то направление работы или определюсь с решением. Эти пять-десять человек потянут всех остальных, кого нужно. Основная потребность стейхолдеров заключается в том, чтобы их включили, их мнение выслушали. Никто из них на самом деле не хочет вместе с вами придумывать решение и не будет это делать. Если вы сталкиваетесь с тем, что кто-то из Head Product или Product лидов вас как-то блокирует, это значит, что вам нужно включить их в этот первый уровень обсуждения. Таким образом они как бы попадают в вашу команду, и вы как бы работаете вместе. Здесь очень классный формат — это рабочие группы, про которые сегодня уже сказали. Мы всегда их создаем для больших проектов. И есть суперпростой инструмент, который называется Google Docs — вы создаете документ, описываете там верхнеуровнево вашу инициативу, что вы планируете делать, какие шаги, какие milestones и отправляете его на имя тех людей, с которыми вам нужно попасть в один контекст. Дальше они оставляют комментарии, какие-то вопросы. И благодаря этим комментариям и вопросам вы уточните масштаб задачи, то есть у вас на радар попадет то, о чем до этого вы даже не подумали. Это — начало пути. Как мы работаем в Miro? У нас в Miro есть Product Reviews. Я думаю, что аналог есть в каждой продуктовой компании. Это встреча, на которую приходит от 30 до 70 человек. И мы недавно разделили Product Review на две фазы — фаза ноль и фаза один. Также, кажется, появилась фаза два, но мы до нее ни разу еще не доходили, в том смысле, что ни разу еще не проводили такую встречу. Фаза ноль вся полностью про проблемное поле. Мы говорим про то, какую проблему мы решаем, почему и почему сейчас. Фаза один — это решения. Когда уже решение готово, то продакт и дизайнер вместе показывают конкретный флоу, мокапы, проговаривают все риски и найденные зависимости, Go to market стратегию и все, что попадет и не попадет в скоуп этой задачи. Все это нужно для того, чтобы: a) задать правильные вопросы самому себе и ответить на них; б) ваши стейкхолдеры увидели ценность и затраты. То есть вы должны проговорить и первое, и второе — какова ценность того, что мы делаем, и сколько мы на это потратим ресурсов. Если вы впервые готовитесь к большой встрече и готовите PAD, Product Alignment Document — я думаю, в каждой компании есть какой-то аналог, мы называем это так — что нужно подготовить к этой встрече, и что нужно включить в этот документ? Самое главное — это собрать данные. Понятно, мы смотрим на цифры. Можно собрать цитаты пользователей, поговорить с пользователями, сделать некий опрос, посчитать opportunity size, посчитать support тикеты — все то, что погрузит всех в контекст максимально быстро. Что задача большая, ценная, есть спрос или проблемы у пользователей. Далее мы должны описать аудиторию — конкретно чью проблему мы решаем, какой use case. Как пример, как Facilitator Miro я хочу назначить человека, который будет на доске включать-выключать таймер, например. То есть — as a user I… Какая-то user story простая, которая даст вашим стейкхолдерам понять, для кого мы эту проблему решаем. С какой целью компании это связано? У всех есть разные подходы. У нас это OKR, где-то это KPI. Вообще это суперскилл, когда каждую свою инициативу можно привязать и провести прямую линию к стратегии компании, потому что это всех выравнивает. Простое русское слово alignment мы используем, все реально если понимают, какие OKR связаны с этой инициативой, становится проще. Как выглядит успех, и как мы поймем, что мы решили проблему? Здесь мы рисуем как бы светлое будущее, куда мы придем, решив эту проблему пользователя и бизнеса. Здесь нужно проговорить метрики — как мы это будем мерить — и потом, после того, как мы выпустим задачу, нам нужно еще будет посчитать, получилось у нас это сделать или нет. От продакта ожидается также — по крайней мере в Miro, я думаю, у вас тоже — посмотреть на рынок, как сейчас пользователи решают эти проблемы с другими продуктами, как это решено, в какие планы это включено, это платные фичи или бесплатные, какие бенчмарки. То есть нужно понимать примерно рыночный контекст. И далее — это я про фазу ноль рассказываю, про проблемное поле — какой подход вы предлагаете. Здесь можно разложить некую матрицу решений тоже верхнеуровнево. Есть вариант направления A, вариант направления B, за и против я вижу такие-то, основные риски я вижу такие-то. Это «эска», это «эмка», а это вообще XXL — нам туда не надо. Чтобы все это работало еще лучше и быстрее, необходимо работать над формированием доверия к себе. Безусловно, это более важно либо для новых людей, либо для тех, кто только что стал продакт-менеджером. Здорово, если на встрече всем понятно, что вы сделали ваш research, то есть вы не просто посмотрели на dashboard, вы реально погрузились в тему, вы поговорили с пользователями и провели, может быть, competitive analysis. Вам задают вопрос, а вы уже об этом подумали — это тоже успокаивает стейкхолдеров, это говорит им о том, что вы понимаете этот масштаб, это значит, что у вас есть некая карта, на которую вы ориентируетесь. Всех очень волнует, как вы принимаете решения, особенно вашего менеджера. Особенно это актуально для новых продактов. Подо что вы оптимизируете? Если вы решаете проблему пользователя, понятно, что все решения по этой инициативе должны быть про проблему пользователя — не выручку мы должны оптимизировать, а решили мы ее или нет. Когда все понимают, как вы принимаете решения, какой у вас принцип, из которого вы исходите, это тоже суперздорово работает на доверие к вам. И классный подход — вовлекать всех критически важных стейколдеров к разговору про выбранное направление работы до важных встреч. Есть всякие leadership вебинары для женщин, это американская серия вебинаров, и на них приглашаются женщины из самых известных компаний, которые достигли уже какого-то уровня в этой компании, это может быть Head of Product, VP Product. Они рассказывают про свой карьерный путь, и каждая из них упомянула, что перед каждой важной встречей она всегда говорит с ключевыми людьми заранее. Потому что иначе может быть неприятный сюрприз как у них, так и у вас, и никто этого не хочет. Поэтому на Product Review мы приходим уже с тем концептом, который уже выровнен с важными людьми в компании. И Капитан Очевидность. Последовательно доводить задачи до результата — тоже влияет на формирование доверия. Следующая фаза — это Delivery. Мы говорим здесь о самой важной фазе, когда формируется финальный вид функционала, который вы выпускаете, и на этой фазе принимается очень много решений. Поэтому здесь мы работаем с зависимостями, мы принимаем решения и проактивно коммуницируем. Стандартные здесь форматы коммуникации со стейкхолдерами — это апдейты и синки. Я не придумала слов лучше, но это звонки, встречи, которые будут с определенной частотой происходить и показывать прогресс. Например, сейчас я работаю над большой инициативой. У меня дважды в день есть синки с ключевой командой — это дизайнер и PMM — два раза в неделю с менеджером и раз в пару недель я разговариваю еще с продактами других команд, которые трогают те же самые компоненты, делают похожие эксперименты, выпускают тоже новые роли в продукте. Что такое зависимости? Это ограничения, которые вы не контролируете. Они могут быть технические, они могут быть Go to market — можем мы залаунчить или нет — легальные, и, конечно, другие команды. Не нужно ожидать, что другая команда возьмет и подвинет что-то в своем плане посреди квартала. Мы часто являемся той командой, к которой приходят и просят что-то подвинуть, и сейчас понятно уже всем, что это не очень возможно. У нас есть эти квартальные road map, мы работаем по OKR и поквартально планируем свои инициативы. Но нам очень помогают общие цели и OKR. Например, в прошлом году мы помогли запустить стартап-план, который не очень влияет на revenue, но при этом этот стартап-план был стратегически важен для компании. Мы потратили три недели на него, и всем было понятно, зачем мы это делаем. Поэтому если у вас в компании нет общего контекста про цели, какие-то условные OKR, вы можете быть тем человеком, который этот процесс наладит, потому что все зависимости разрешать намного проще, когда все понимают — да, это сейчас самое важное в компании. Принятие решений. Тут нужно принять основной факт — всегда какого-то согласия по решениям не случится. Это первое. И второе. Самое сложное решение — это когда ты выбираешь между двумя одинаково хорошими вариантами. Поэтому просто выбери какой-то один. Если один из вариантов очевидно хороший, а другой плохой, то тут думать нечего. Основная мысль про решения заключается в том, что если вы думаете над этой проблемой, то вы, скорее всего, готовы принять решение больше, чем вам кажется. Потому что никто не думал над ней больше вас, это ваш домен, это ваша экспертиза. Помним про время. Непринятие решения — это тоже решение. Если вы что-то не делаете сейчас, это означает, что оно не делается. Следующий пункт — рассматривайте только серьезные возражения. Представим, что идет какая-то встреча, и ваши коллеги начинают бурно обсуждать не основную какую-то проблему — как сделать секьюрным доступ к архивам пользователей — а какого цвета кнопка будет. Понятно, что всем интересно, всем хочется поучаствовать, это довольно просто — обсуждать цвет кнопки. Чтобы это все ускорить, можно поставить некий timebox — у нас есть только сегодня, и мы должны сегодня до конца встречи принять решение. Рассматривайте, адресуйте только серьезные возражения, не отвлекайтесь на все остальное. Конечно, это звучит очевидно, но мы видели случаи, когда в какой-то кроссфункциональной группе не все понимают, кто Decision Maker. И в итоге вы должны отвечать за это, вы должны всем сказать — это вы принимаете решение. Вы хотите, чтобы команда это сделала. Всем нужно знать, кто Decision Maker. Когда все случилось, когда мы всё выпустили, мы выпускаем праздничный пост в «Слэке» — ура, мы запустили новый таймер — про что это, кто это сделал, кому задавать вопросы. Опять же коммуникация на всю компанию, на всех стейкхолдеров. Пример такого апдейта может включать текущий статус, на проде или еще нет, какая команда ответственна, кто ответственный, что нужно знать. Мы очень любим делать Loom video. Loom video — это идеальная штука. Ты за две минуты голосом проговариваешь, что ты сделал, показываешь на доске, как это работает — всё. Все стейкхолдеры счастливы, им не нужно идти читать документацию, потому что не все это любят делать. Какие-то ссылки сюда включить — на PAD, на Go to market документы. Какие следующие шаги — например, сейчас у нас «бета», через месяц мы раскатываем на всех. Какие возможные проблемы — например, ожидаются ли проблемы с загрузкой досок, в случае Miro. Куда направлять вопросы и фидбэк, и вы можете попросить маркетинг-команду, или они сами это делают — подготавливают некий collateral, материалы, которые можно постить в соцсетках. То есть вы можете в такие апдейты включать эти ссылки и попросить вашу команду новостью поделиться там. После запуска коммуникация, конечно же, не заканчивается, и от продакт-менеджера ожидается, что она или он проанализирует, посчитает, достигли ли мы той цели, которую ставили, success метрики. Если мы говорим про какую-то фичу, то какой у нее adoption, и, естественно, предоставить обратную связь от пользователей. То есть просто даже цитаты. Мы, например, достаточно быстро видим отклик — что-то выпустили, и уже в LinkedIn идут какие-то треды. Мы можем сразу понять, это то, что пользователи хотели, насколько мы решили их проблему и так далее. Я работаю в команде Growth, поэтому мы проводим много экспериментов. Также результаты экспериментов у нас прозрачны для всех. Эксперименты не всегда удачные, как знают те, кто работают в Growth и проводят эксперименты. Поэтому здесь очень ценно, что нового мы узнали. Да, возможно, мы его не выпустили на всех, но что узнали нового, и как мы это применим дальше. Например, мы узнали про пользователя что-то новое — как мы это дальше будем использовать? У нас на прошлой неделе был онлайн-офсайд в Miro. Три дня весь Product Dep обсуждал состояние бизнеса, наши основные цели на следующий квартал, чего мы уже достигли. Один из моих коллег написал в «Зум» — мне так понравилось, что я заскриншотила — я бы хотел избавиться от слова «стейкхолдер» и называть всех партнерами. Помимо очевидных вещей, таких как объединять людей вокруг общей цели, таких как быть экспертом по управлению, которое ты решаешь, проактивно вовлекать, информировать своих стейкхолдеров есть еще и простой insight — просто относить к ним как к партнерам, потому что это более классно и инклюзивно.