Командная осознанность — что отличает лучшие продуктовые команды
По мнению главного продакт-менеджера из Atlassian с одиннадцатилетним опытом.
Оригинальный материал на Medium.
TL; TR:
- Командная осознанность (shared understanding) — главный навык отличной продуктовой команды. Это отличает просто хороших команд от отличных.
- Лучший продакт-менеджер — не тот, кто знает ответы на все вопросы. А тот, кто убедился, что его команда понимает, что нужно делать, для кого и почему.
- Личный опыт команды Ducalis.io по внедрению командной осознанности. Процесс долгий, сложный, но результаты отличные.
Как стать хорошим продакт-менеджером
Если погуглить и почитать Quora, находятся такие списки.
- С конкретными навыками: аналитика, UX/UI, клиентские интервью и исследование, умение делать A/B-тесты и так далее.
- С общими: иметь эмпатию, стратегическое видение, быть проактивным, адаптивным, искать непреднамеренные последствия.
Но все же набор конкретных навыков для изучения хороших продакт-менеджером понять несложно.
Два подхода к принятию решений про продукты
После сотни часов кастдев-интервью с продакт-менеджерами отчетливо видно два подхода:
- Супергерой — знающий все ответы и решающий все вопросы в команде.
- Фасилитатор — помогающий команде понять и принять решение.
Ловушка продуктового консультанта
Супергеройство вдохновляется образом Стива Джобса — быть единоличным гением, который видит будущее, его не интересует мнение сотрудников, он один знает, что нужно делать.
Супергеройство порождает ловушку: превращение в продуктового консультанта из менеджера продукта.
Продуктовый консультант — человек, знающий ответы на все мелкие вопросы про продукт.
Супергеройство в продакт-менеджменте до добра не доводит
Лично мне очень понравился опыт Шерифа Мансура, продакт-менеджера Atlassian с одиннадцатилетним опытом.
В начале своей карьеры Шериф полагал, что продакт-менеджер-супергерой знает ответы на все вопросы. Что в итоге породило проблему: Шерифу пришлось давать ответы на почти все вопросы касательно продукта, даже «поставьте кнопку тут», «сделайте ее синей», «запрос к API должен выполняться таким образом» и так далее. И в какой-то момент его команда завалила его этими вопросами, на которые он отвечал без остановки.
Во время очередного разговора с начальником Шериф начал рассказывать много нюансов, которые они хотят сделать с командой, какие и куда поставить кнопки, как он перегружен вопросами. Однако получил фидбек, что мало думает над глобальными стратегическими вещами и не работает над ними.
Проблема продуктового консультанта
- Количество вопросов к супергерою будет расти, а масштаб вопросов уменьшаться.
- Без вас вся работа встанет.
- Будет расти ненужная работа над ненужными фичами.
Все, что PM не успеет посмотреть или изучить, уйдет в работу и будет сделано не так, не для того и в не в том виде.
Для решения этих проблем на помощь берутся инструменты планирования Roadmap, составление Product Requirement Document, приоритизация Backlog.
Однако даже при наличии этих инструментов и условии, что команда все добросовестно читает, интерпретировать описанную задачу каждый будет по-своему.
Записать и прочитать все идеи, планы и видение по продукту совсем не значит осознать его.
Продакт-менеджмент — это командный спорт
В своем выступлении на конференции Mind The Product Шериф Мансур называет свое главное заблуждение: «продакт-менеджер должен принимать все решения».
Нужно двигаться в сторону системы командного принятия решений.
Задача продакт-менеджера — влиять на скорость принятия осознанных решений в команде (Velocity of Decision Making) через создание командной осознанности (Shared Understanding).
И это стало самым главным открытием карьеры Шерифа.
Три столпа командной осознанности
Команда должна осознавать:
- The Who. Для кого делается продукт? Кто именно ваши клиенты? Какие у них боли?
- The What. Что именно делается в вашем плане продукта?
- The Why. Почему именно так делается, а не иначе?
Один из признаков наличия командной осознанности — это оставить реализацию продуктового беклога без вашего внимания.
И команда будет делать нужные задачи для ваших клиентов, стратегии компании (акционеров), осознанно выбирая, что именно важно сделать и почему.
Ваши коллеги, дизайнеры, аналитики, разработчики смогут сами решить, без продакт-менеджера, все эти вопросы?
Признаки наличия командной осознанности
- Вы не залезали в ваш продуктовый беклог месяцами и у вас не возникает вопроса «зачем вы это сделали?»
- Ваша команда спорит с вашим предложением для продукта, утверждая, что это не соответствует целям компании.
- Ваша команда упоминает конкретные имена клиентов в обсуждении кейсов.
- При обсуждении планов команда упоминает фразы «это поможет нам повлиять на клиентскую метрику» вместо «мне надо закрыть пятый эпик, чтобы получить бонус».
- На командных демо ваши коллеги используют обороты «мы сделали X, потому что это решает клиентскую проблему Y» без ваших наводящих вопросов.
- Все идеи, которые записывают ваши коллеги в беклог, явно относятся к продуктовым планам компании.
Только вдумайтесь, вы как продакт-менеджер (оунер, CEO) готовы не влезать в планы команды? Не назначать каждому задачи?
Что делает отличный продакт-менеджер
Шериф выделяет три области работы продакт-менеджера.
- Управляет фазой исследования (Discovery Phase). Понять проблемы клиентов, их намерения. Сюда входят исследовательские интервью клиентов, опросы, быстрое прототипирование.
- Создание командной осознанности. Донести до команды кто (who), что (what) и почему (why). Скомпоновать его в удобный формат для быстрого осознания и применения для повседневной работы.
- Поиск проблем/зазоров в командной осознанности. Собрать с команды фидбек, что именно им непонятно и почему. И помочь это лучше осознать.
Собственный опыт создания командной осознанности
Вся история создания Ducalis.io — это попытка создать командную осознанность.
1. Делиться выводами после звонков с клиентами
Для звонков с клиентами используем методику книги “The Mom Test”. Стараемся не продавать, не делать демо, не рассказывать вообще про наше решение, а слушать клиента.
На звонке просить разрешение у клиента записать видео. После звонка делиться с командой короткими выводами со звонка и таймкодами из видео на самые показательные моменты, где клиент своими словами рассказывает про боль или проблему.
2. Цели продукта или компании выражены в критериях для оценки задач
Раньше у нас был документ с целями и планами компании. Но вспомнить ключевые метрики и цели из него без подсказки было сложно. После мы перевели их в критерии оценки для Ducalis.io.
Есть три набора критериев:
- Общие, которые должна понимать вся команда: активацию, ретеншен, скорость сервиса и помощь пользователям лучше понимать, взаимодействовать.
- Разработчики оценивают сложность разработки.
- Менеджеры оценивают потенциал продаж и массовость фичи.
3. Каждую неделю все в команде оценивают задачи
Задачи из нашего беклога нужно оценить по каждому из критериев. У менеджеров и разработчиков набор критериев немного разный. Делается это очень быстро, нужно быстро проставить субьективно баллы.
4. Каждый понедельник звонок по планам
У нас получается отсортированный по важности топ задач. Этот топ носит лишь рекомендательный характер. Команда сама добирает задачи и рассказывает на звонке, что именно и почему берет в работу.
5. Как именно мы понимаем, где у нас есть и нет командной осознанности
- Можно поставить прочерк в задаче, если не понимаешь, как именно оценить всю задачу или отдельный критерий. Это позволяет собрать честный фидбек от команды. И помочь автору задачи понять, что именно в ней непонятно.
- Через 30 дней после проставления оценок нужно оценить задачу снова. У нас регулярно появляется новый контекст проблем или задач от клиентов, поэтому «переоценка ценностей» — это обязательный ритуал проверки, всё ли в нашем беклоге актуально.
Всё вместе даёт картину Team Alignment, где мы наглядно видим, в чём именно у команды есть разногласия.
Результаты внедрения Shared Understanding в команде Ducalis.io
За несколько месяцев эта система начала давать результаты. Несколько отзывов от коллег:
Чаще всего всё хорошо с этим, хороший уровень: возросло понимание как менеджеров, так и разработчиков о продукте. Пытаются не только со своей стороны смотреть. Дискуссии стали аргументированнее.
Shared Understanding у нас, кажется, на высоком уровне.
Сейчас не хватает (не хватало) показателей, к которым движемся, что по итогу у нас клиентов должно стать Х, прибыли К и так далее.
Это поможет в том числе и в приоритетах — понятно, насколько та или иная задача поможет достичь нужного показателя. Поменялось после последнего обсуждения.
Вит, сейчас все же на тебе очень много завязано, ты мало делегируешь и передаёшь доверие по решению задач.
Как видите, сказать, что у нас всё отлично, — не можем. Но ситуация становится всё лучше и лучше с каждой неделей. Это отнимает немало сил, часто кажется «тут всё понятно, быстрее самому сделать, чем объяснять». Но это лишь откладывание на будущее проблемы, которая будет нарастать.
Попробуйте наш подход в Ducalis.io
Не забудьте завести себе аккаунт и пооценивать задачи. Всю эту методику наш продукт вам сам подскажет и направит.
Материалы из статьи
P.S. Синдром Стива Джобса — быть единоличным гением, который видит будущее, не интересуется мнением клиентов, сотрудников, один знает знает, что нужно делать. Но в то же время он говорил “Hire smart people and let them tell you what to do”.
Продакты Атлассиана — последние люди, кого нужно спрашивать: стоковая Джира в облаке и без плагинов ломается просто от апдейтов (и почти никогда не чинится обратно)
ну наконец-то начали обсирать Жиру! А то я уж думал, что так никто и не напишет.
То, что у них выручка больше ярда и это топовые тулы для разработки — это конечно же ни в счет.