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

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

TL; TR:

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

Как стать хорошим продакт менеджером?

Если погуглить и почитьа Quora, то находятся списки от очень конкретных навыков: аналитика, UX/UI, клиентские интервью и исследование, умение делать A/B тесты и т.д.

До слишком общих: эмпатия, стратегическое видение, проактивный, адаптивный, искать непреднамеренные последствия.

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

Два подхода к принятию решений по продукты

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

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

Ловушка продуктового консультанта

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

Супергеройство поражадет ловушку: превращение в продуктового консультанта из менеджера продукта.

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

Супергеройство в продакт-менеджменте до добра не доводит

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

Кадр из видео What is product management? — Agile Coach с официального канала Atlassian

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

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

Однако получил фидбек, что мало думает над глобальными стратегическими вещами и не работает над ними.

Проблема продуктового консультанта

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

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

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

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

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

Продакт менеджмент — это командный спорт

Из выступления про самые большие заблуждения в продакт-менеджменте за 11 лент в Atlassian

В своем выступлении на конференции Mind The Product Шериф Мансур называет своим заблуждением #1 — “Продакт менеджер должен принимать все решения”.

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

Задача продакт-менеджера—влиять на скорость принятия осознанных решений в команде (Velocity of Decision Making) через создание командной осознанности (Shared Understanding).

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

Три столпа командной осознанности

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

The Who — для кого делается продукт? Кто именно ваши клиенты? Какие у них боли?

The What — что именно делается? В вашем плане продукта?

The Why — почему именно так делается, а не иначе?

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

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

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

Признаки наличия командной осознанности:

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

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

Что делает отличный продакт-менеджер

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

1. Управляет фазой исследования (Discovery Phase). Понять проблемы клиентов, их намерения. Сюда входят исследовательские интервью клиентов, опросы, быстрое прототипирование.
2. Создание Командной Осознанности. Донести до команды Кто (Who), Что (What) и Почему (Why). Скомпоновать его в формат удобный для быстрого осознания и применения для повседневной работы.
3. Поиск проблем/зазоров в командной осознанности. Собрать с команды фидбек, что именно им не понятно и почему. И помочь это лучше осознать.

Пример результата опроса команды про понимание The Who, The What, The Why.

Собственный опыт создания командной осознанности

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

1. Делиться выводами после звонков с клиентами.

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

2. Цели продукта / компании выражены в критериях для оценки задач.

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

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

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

Набор критериев для оценки задач из беклога

3. Каждую неделю все в команде оценивают задачи.

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

Пример оценки задачи по критериям

4. Каждый понедельник звонок по планам

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

Топ оцененных задач, отсортированных по приоритету

5. Как именно мы понимаем, где у нас есть и нет командной осознанности

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

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

Результаты внедрения Shared Understanding в команде Ducalis.io

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

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

— “Shared Understanding у нас, кажется, на высоком уровне”.

— “Сейчас не хватает (не хватало) показателей, к которым движемся, что по итогу у нас клиентов должно стать Х, прибыли К и так далее. Это поможет в том числе и в приоритетах — понятно на сколько та или иная задача поможет достичь нужного показателя. Поменялось после последнего обсуждения”.

— “Вит, сейчас все же на тебе очень много завязано, ты мало делегируешь и передаешь доверие по решению задач“.

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

Попробуйте наш подход в Ducalis.io

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

Материалы из статьи:

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

P.S. про Синдром Стива Джобса — быть единоличным гением, который видит будущее, не интересуется мнением клиентов, сотрудников, один знает знает, что нужно делать. И тоже он говорил “Hire Smart People and Let Them Tell You What To Do”