Командная осознанность — что отличает лучшие продуктовые команды

По мнению главного продакт-менеджера из Atlassian с одиннадцатилетним опытом.

Оригинальный материал на Medium.

TL; TR:

• Командная осознанность (shared understanding) — главный навык отличной продуктовой команды. Это отличает просто хороших команд от отличных.
• Лучший продакт-менеджер — не тот, кто знает ответы на все вопросы. А тот, кто убедился, что его команда понимает, что нужно делать, для кого и почему.
• Личный опыт команды Ducalis.io по внедрению командной осознанности. Процесс долгий, сложный, но результаты отличные.

Если погуглить и почитать Quora, находятся такие списки.

• С конкретными навыками: аналитика, UX/UI, клиентские интервью и исследование, умение делать A/B-тесты и так далее.
• С общими: иметь эмпатию, стратегическое видение, быть проактивным, адаптивным, искать непреднамеренные последствия.

Но все же набор конкретных навыков для изучения хороших продакт-менеджером понять несложно.

После сотни часов кастдев-интервью с продакт-менеджерами отчетливо видно два подхода:

1. Супергерой — знающий все ответы и решающий все вопросы в команде.
2. Фасилитатор — помогающий команде понять и принять решение.
   

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

Продуктовый консультант — человек, знающий ответы на все мелкие вопросы про продукт.

Лично мне очень понравился опыт Шерифа Мансура, продакт-менеджера Atlassian с одиннадцатилетним опытом.

В начале своей карьеры Шериф полагал, что продакт-менеджер-супергерой знает ответы на все вопросы. Что в итоге породило проблему: Шерифу пришлось давать ответы на почти все вопросы касательно продукта, даже «поставьте кнопку тут», «сделайте ее синей», «запрос к API должен выполняться таким образом» и так далее. И в какой-то момент его команда завалила его этими вопросами, на которые он отвечал без остановки.

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

1. Количество вопросов к супергерою будет расти, а масштаб вопросов уменьшаться.
2. Без вас вся работа встанет.
3. Будет расти ненужная работа над ненужными фичами.

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

Для решения этих проблем на помощь берутся инструменты планирования Roadmap, составление Product Requirement Document, приоритизация Backlog.

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

Записать и прочитать все идеи, планы и видение по продукту совсем не значит осознать его.

В своем выступлении на конференции Mind The Product Шериф Мансур называет свое главное заблуждение: «продакт-менеджер должен принимать все решения».

Нужно двигаться в сторону системы командного принятия решений.

И это стало самым главным открытием карьеры Шерифа.

Команда должна осознавать:

• The Who. Для кого делается продукт? Кто именно ваши клиенты? Какие у них боли?
• The What. Что именно делается в вашем плане продукта?
  
• The Why. Почему именно так делается, а не иначе?
  

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

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

• Вы не залезали в ваш продуктовый беклог месяцами и у вас не возникает вопроса «зачем вы это сделали?»
• Ваша команда спорит с вашим предложением для продукта, утверждая, что это не соответствует целям компании.
• Ваша команда упоминает конкретные имена клиентов в обсуждении кейсов.
• При обсуждении планов команда упоминает фразы «это поможет нам повлиять на клиентскую метрику» вместо «мне надо закрыть пятый эпик, чтобы получить бонус».
• На командных демо ваши коллеги используют обороты «мы сделали X, потому что это решает клиентскую проблему Y» без ваших наводящих вопросов.
• Все идеи, которые записывают ваши коллеги в беклог, явно относятся к продуктовым планам компании.

Только вдумайтесь, вы как продакт-менеджер (оунер, CEO) готовы не влезать в планы команды? Не назначать каждому задачи?

Шериф выделяет три области работы продакт-менеджера.

• Управляет фазой исследования (Discovery Phase). Понять проблемы клиентов, их намерения. Сюда входят исследовательские интервью клиентов, опросы, быстрое прототипирование.
• Создание командной осознанности. Донести до команды кто (who), что (what) и почему (why). Скомпоновать его в удобный формат для быстрого осознания и применения для повседневной работы.
• Поиск проблем/зазоров в командной осознанности. Собрать с команды фидбек, что именно им непонятно и почему. И помочь это лучше осознать.

Вся история создания Ducalis.io — это попытка создать командную осознанность.

Для звонков с клиентами используем методику книги “The Mom Test”. Стараемся не продавать, не делать демо, не рассказывать вообще про наше решение, а слушать клиента.

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

Раньше у нас был документ с целями и планами компании. Но вспомнить ключевые метрики и цели из него без подсказки было сложно. После мы перевели их в критерии оценки для Ducalis.io.

Есть три набора критериев:

• Общие, которые должна понимать вся команда: активацию, ретеншен, скорость сервиса и помощь пользователям лучше понимать, взаимодействовать.
• Разработчики оценивают сложность разработки.
• Менеджеры оценивают потенциал продаж и массовость фичи.

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

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

• Можно поставить прочерк в задаче, если не понимаешь, как именно оценить всю задачу или отдельный критерий. Это позволяет собрать честный фидбек от команды. И помочь автору задачи понять, что именно в ней непонятно.
• Через 30 дней после проставления оценок нужно оценить задачу снова. У нас регулярно появляется новый контекст проблем или задач от клиентов, поэтому «переоценка ценностей» — это обязательный ритуал проверки, всё ли в нашем беклоге актуально.

Всё вместе даёт картину Team Alignment, где мы наглядно видим, в чём именно у команды есть разногласия.

За несколько месяцев эта система начала давать результаты. Несколько отзывов от коллег:

Как видите, сказать, что у нас всё отлично, — не можем. Но ситуация становится всё лучше и лучше с каждой неделей. Это отнимает немало сил, часто кажется «тут всё понятно, быстрее самому сделать, чем объяснять». Но это лишь откладывание на будущее проблемы, которая будет нарастать.

Не забудьте завести себе аккаунт и пооценивать задачи. Всю эту методику наш продукт вам сам подскажет и направит.

• Popular Misconceptions of the Product Craft by Sherif Mansour at Mind the Product Singapore.
• Product managers make all the decisions… right? от Sherif Mansour.
• What is product management? — Agile Coach.
• Как «Дукалис» помогает приоритизировать задачи в Jira.

P.S. Синдром Стива Джобса — быть единоличным гением, который видит будущее, не интересуется мнением клиентов, сотрудников, один знает знает, что нужно делать. Но в то же время он говорил “Hire smart people and let them tell you what to do”.

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