Как сформировать видение продукта и согласовать его со стейкхолдерами?

Что мы видим, когда работаем с командами?

У нас большой опыт работы с командами. Везде мы видим один и тот же паттерн:

1) Продактам сверху всегда спускаются задачи

2) Продакты не понимают почему спускается то, что спускается, продуктовый подход превращается в проектный

3) Выгорание команды и негатив от менеджмента

4) Команде навязываются продуктовые метрики

5) Инвестиции защищаются далеко не с первого раза

6) Продакт долго растет до CPO, так как делает задачи сверху

7) Низкий возврат инвестиций, так как команды продолжают фичирить во все стороны

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

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

Год назад мы рассказывали о том, как это можно починить путем выстраивания Discovery у себя в корпорации. Вкратце: есть 4 основные цикла, которые внедряются в процесс производства. Неважно, используете вы Agile, Waterfall, Канбан или что-то еще.

(откройте картинку в новой вкладке для просмотра схемы в увеличении)

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

Что такое пререквизит?

Как он появился? Изначально мы пытались все то, что вы видите на схеме выше, внедрить в компании. Но, как это часто бывает, все пошло не по плану. Все потому что у нас не было информации о том, куда и что именно мы внедряем. Затем мы нашли для себя 3 простые вещи, на которые нам стоит смотреть:

1) Ключевые метрики в работе команды на данный момент

2) Текущая воронка и почему она именно такая

3) Какие ресурсы сейчас есть у команд и компании в целом

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

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

Почему это не работало?

Мы стали искать узкое место — причину, по которой нововведения не работали. Вот что выявили:

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

С целью решения проблемы мы пошли в Интернет и сходили к нашим коллегам. Обнаружили интересную концепцию от Романа Пинчера — Product Vision Board. Эта концепция логично все собирала в одно место, этим можно было бы пользоваться, но в наших реалиях это, увы, не работало. Мы решили пересобрать концепцию так, как ее видим мы в реальности — в МТС и других командах.

Какие задачи мы решали?

1) Собирать всю необходимую информацию всего за 1 неделю и сразу начинать работу.

2) Актуализировать состояние продукта и команды силами самой команды и менеджмента, чтобы все могли честно посмотреть на текущие результаты, получить инсайты и т. д.

3) Дать возможность команде посмотреть на продукт сверху, чего всегда не хватает, пока команда вечно куда-то бежит и вообще находится в коконе своего продукта. При этом менеджменту нужно дать возможность посмотреть на продукт изнутри.

4) Выстроить результативную коммуникацию между командой и менеджментом. Именно из проблем в коммуникации вырастают все те проблемы, о которых мы говорили выше.

Что у нас получилось?

Мы создали инструмент, который действительно у нас работает. Ключевые действия:

1) Оставили только то, что нужно и реально используется. Первые вариации Vision Board были довольно большими, но в процессе работы с командой мы их сократили.

2) Смогли найти ценность для команды и менеджмента в одном документе. Как мы это поняли? Команда и менеджмент ссылаются на инструмент, просят выстраивать коммуникацию вместе с ним.

3) Сделали инструмент, на основе которого команда и менеджмент актуализируют, анализируют и принимают решения.

4) Повысили качество работы, коммуникации и достижения целей.

Результаты команд / CPO / VP

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

Кроме того, бэклог очищается от всего, что нерелевантно для достижения миссии продукта. Наконец, всем становится четко понятен фокус работы на ближайший месяц / квартал. То есть, вижн борд помогает вам качественнее спланировать ближайший период работы.

Актуальные вопросы о Product Vision Board

Вопрос: Есть наблюдение, что инструмент Пинчера может хорошо работать на относительно локальных продуктах. Но во время применения его на большом сервисе либо Core продукте эффективность снижается. Сталкивались ли вы с чем-то подобным?

Ответ: Не заметили, хотя проверили инструмент на большом кол-ве продуктов. У большого продукта может, разве что, появится вопрос емкости формулировок. Больше всего информации появляется на этапе заполнения блока 4 (описание конкретных сегментов). Чем больше сегментов, тем сложнее в них разобраться. Здесь вопрос в том, на что делается акцент в рамках ближайшего месяца/квартала. Ведь мы редко работаем над 5-10-20 сегментами одновременно. Кроме того, у вас 1, 2 и 3 блок борда могут быть статичными, а большие блоки 4 и 5 могут меняться под конкретные функции.

Вопрос: Применим ли артефакт для компаний любого масштаба или есть ограничения?

Ответ: Можно применить его для всей компании, и, если она большая, то и документ будет большим. Либо применить для конкретного продукта или направления внутри компании. Артефакт применим и для стартапов на уровне идеи, которые ставят цель привлечения инвестиций. Потому что часто инвесторам не очень понятна задумка, а стартапер не может ее объяснить.

Вопрос: А если у стейкхоллдера нет видения продукта / компании / стратегии развития? И он предлагает определить видение продакту / команде самостоятельно.

Ответ: Это история про взятие ответственности на себя. Тогда продакт приходит к стейкхолдеру и утверждает вижн без корректировок, но со стейкхолдером также надо согласовать, что любые правки и «хотелки» должны калиброваться с согласованным виженом. Продакт берет на себя ответственность, что очень круто для развития в продукте. Можно сказать, что вы сами начинаете управлять стейкхолдером. Кроме того, если стейкхолдер не имеет своего видения, то вижн борд в таком случае — документ коммита для обеих сторон. Стейкхолдер увидел борд и согласился с тем, что в нем написано.

Вопрос: С какими самыми частыми ошибками сталкиваются команды при заполнении такого борда?

Ответ: Когда пишут сегмент, к которому не привязана проблематика, не учтен контекст. Или когда приписывает одному сегменту проблематику совершенно другого сегмента. Иногда получается рассинхрон. Вот почему не стоит замыкаться в своем коконе — важно «калибровать» вижн с кем-то, кто имеет насмотренность и кто видит эти ошибки.

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