Один из важных артефактов наших продуктовых процессов — check-in meetings или “контрольная встреча”.

Давайте поговорим про неё поподробнее, а я покажу как это у нас выглядит.

I. Предпосылки
Если ваша продуктовая команда стала больше пары-тройки человек, то у вас появляются две цели, которые противоречат друг другу.

• С одной стороны, вы хотите бóльшей автономности ваших команд. Чтобы решения принимались сами, а у вас была возможность расширять количество команд.
• С другой стороны, вы хотите, чтобы решения были правильные. То есть совпадали с целями продукта. Чтобы была синхронизация, а не разброд. Чтобы о проблемах вы узнали как можно раньше и ничего не тормозило.

Первая задача требует от вас вовлекаться в ежедневные дела команды меньше. Вторая задача требует вовлекаться больше.

Перекос в ту или иную сторону несёт свои специфичные проблемы. Вы или ограничиваете маштабирование команд, замыкая решения на себя — то есть общая скорость ограничена вашей скоростью и ёмкостью, что может работать, но до определенного предела. Или же у вас теряется управление — все идут в разные стороны, нет фокуса, а о проблемах вы узнаете слишком поздно (когда они уже случились, а не когда появились первые симптомы).

Ситуация становится ещё сложнее, когда в нашей картине мира появляются интересанты из руководителей и других частей компании. Им хочется знать, что происходит в продуктовой команде: а что мы выпустили, а почему, а какой роадмап, а на год, а вот мы выпустили — а какой импакт и так далее и так далее. Этот интерес понятен и справедлив — результаты их работы зависит от продукта, они хотят знать и влиять на продуктовые планы. Но без управления и направления этих запросов — продакт-менеджеры могут быть погребены под этой “бесполезной работой” — готовить слайды, таблички, упаковывать и переупаковывать мысли и идеи снова и снова для сторонних читателей.

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

II. Решение и его фундаментальные принципы
Решение, на мой взгляд, тут такое: вовлекаться сильно и глубоко, но не часто. В процессе вовлечения генерировать артефакты с информацией, которые имеют высокий уровень переиспользования. А для этого используется check-in встреча и check-in слайды.

Проблема любого процесса, что он имеет свойство занимать весь доступный ему объем (как газ). Добавить процесс или дополнительную работу — просто. Ценность процесса заметна, а недостатки — нет. И в большинстве компаний есть социальные табу на обсуждения нужности новых процессов (особенно если их вносит менеджер) — это не одобряется. В результате процессы и “дополнительная обслуживающая работа” плодятся и занимают всё свободное время.

Одно из решений это подход “хочешь добавить процесс/встречу — убери процесс/встречу”. Другой — перед описанием процесса, явно сформулировать его цели и основополагающие принципы (что мы хотим, что мы не хотим).

Что мы хотим:

• Мы хотим убрать необходимость частого вовлечения в жизнь команды и дать ей бóльшую автономность. При этом мы 1) хотим понимать “здоровье” команды(все хорошо? мы на пути к достижению целей или нет?), 2) хотим знать о проблемах и помехах как можно раньше 3) хотим принимать важные решения быстро, чтобы разблокировать команду, если она заблокирована 4) и хотим иметь общий контекст и понимание целей(“общие модели мира”) — как в компании так и в команде, чтобы команда и компания могла принимать правильные решения сами.
• Мы хотим спрашивать продакт-менеджера и команду о вещах и данных, которые они и так должны знать. И мы хотим, чтобы продакт-менеджер регулярно про эти вещи думал, а на эти метрики смотрел. Мы верим, что это вещи и метрики повышают качество решений команды.
• Мы хотим, чтобы сбор нужных данных, метрик и новостей должно быть легким для продакт-менеджера и команды. Если это пока не легко — должна быть возможность сделать это сильно легче. Процесс должен побуждать сделать этот сбор лёгким.
• Мы хотим, чтобы итогом процесса был артефакт о продуктовых делах команды с очень высоким уровнем переиспользования для всех: от маркетинга и отдела продаж — до менеджмента и PR. Создаем один раз → используем много где. И мы хотим, чтобы этот артефакт был понятен сам по себе, без дополнительных объяснений.

Что мы не хотим:

• Не хотим спрашивать про одни и те же вещи дважды (например в разных форматах и дизайне).
• Не хотим спрашивать вещи в неожиданное время и непредсказуемо. Продакт-менеджер и команда всегда знают, когда от них ожидают новой порции информации и готовятся заранее.
• Не хотим спрашивать новости и данные, которые нам не нужны и которые не будет использовать для принятия решения или проверки “здоровья” команды. Не спрашиваем вещи “на всякий случай, вдруг в будущем будут нужны”. Не спрашиваем вещи и данные, цель которых просто продемонстрировать, что команда/продакт-менеджер их имеют.
• Не хотим, чтобы продакт-менеджер думал о дизайне слайдов и о том, как оформить свои мысли.
• Не хотим, чтобы встречи превращались в чтение слайдов, которые и так все могут прочитать. Это очень скучно.

III. Check-in встреча и check-in документ
Процесс основан на двух элементах: сheck-in встреча и check-in документ.

→ Темплейт check-in документа (реальный темплейт из которого я убрал специфичные для нас вещи)

• В конце каждого месяца есть назначенная check-in встреча (звонок) у каждой команды.
• К концу каждого месяца продакт-менеджер c командой работает над обновлением своего документа. Каждый раз это один и тот же документ (его ссылка не меняется, это даёт всем предсказуемость — “обновления всегда тут”). Обновление этого документа происходит в конце месяца, но перед тем как происходят разные другие встречи и события, которые требуют апдейтов. Это даёт возможность подготовить информацию один раз и переиспользовать много.
• Продакт-менеджер дублирует слайды прошлого месяца. Старые уносит в конец документа и скрывает. Новые — обновляет. Так как это обновление существующих слайдов — это делать всегда проще и быстрее, чем создавать что-то с нуля.
• Дизайн документа менять нельзя, только контент (ну и размер текста в некоторый редких исключений). Это упрощает его создание, переиспользование и чтение (когда вам надо посмотреть 20 таких документов).
• Готовый документ посылается участникам встречи и опционально всей продуктовой команде (рекомендуемый вариант) за день-два до самого звонка. У всех есть время его внимательно почитать и задать вопросы в комментариях. Мы ожидаем, что большинство вопросов и обсуждений будут в комментариях до звонка.
• На звонок приглашены все важные интересанты. Например это могут быть продакт-лид, инженерный лид и дизайн-лид команды и руководитель продукта. Опционально члены команды. В зависимости от команды и направления могут быть ещё кто-то. Но к добавлению новых людей к звонку надо подходить осторожно, чтобы сохранить атмосферу в которой всё ещё комфортно говорить о проблемах, недостатках и некомфортных вещах. Также именно поэтому не рекомендуется записывать звонок.
• Звонок занимает 30 минут. Достаточно неформальный — 2 костюма из 5 (👔👔⬜️⬜️⬜️). Читать слайды запрещено. Слайды быстро “прокликиваются”. Если у кого-то есть комментарий или вопрос — тогда останавливаемся и обсуждаем.

IV. Описание темплейта документа
Давайте посмотрим на каждый слайд шаблона и его цель повнимательнее. (слайды на английском)

• Обложка. Имя сквода, дата обновления и по возможности — имена или фотографии команды. Кто сделал те штуки, про которые мы рассказываем дальше.
• Миссия, виденье и стратегия. Здесь у нас краткое в пару предложений описание цели существования команды. Ссылки на документ с виденьем, стратегием и дэшбордом с основными метриками.
• Метрики команды, месячные и квартальные. Самые главные метрики команды. Как правило именно по ним поставлены цели. Команда показывает значение метрики за прошлые периоды, за текущий, динамику изменения, цель на год и каков наш прогноз по достижению цели. В комментариях добавляется информация о дате получении метрик, ссылки на репорты откуда их взяли и любая дополнительная информация. Важно не только показать метрики, но и написать как и когда их собрали — это избавляет от множества проблем.
• Дополнительные метрики команды (опционально). Любые дополнительные метрики, которыми команда хочет поделиться или похвалиться.
• Что мы выпустили, планы и над чем работаем прямо сейчас. Список задач, проектов и фокусов, которыми занимается команда. Это не обязательно прям “фича”, это именно фокус. Каждая задача ссылается на What/Why/Outcome документ (https://t.me/qetzal_1up/1123) с дополнительными деталями.

Проекты помечены особым образом. У них есть статус оценка риска: ✅ – запущено, ❌ – решили не делать, 🟢 – всё по плану, 🟡 – есть риски, 🔴 – очень серьезные риски, скорее всего не сделаем вовремя. Также примерный прогноз выпуска с точностью до месяца. Самые важные вещи отмечены жирным — важное, это когда вот именно штуку мы хотим сделать точно. И мы готовы жертвовать другими проектами ради этого, если нужно будет выбирать.

Если проект мы не успели сделать в квартале — он переходит на следующий (если мы все же хотим его сделать). В этом случае он должен быть явно помечен (“перенесли с квартала X”).

Задачи и фокусы на следующие кварталы должны восприниматься как предварительный план, а не жёсткое обещание.

• Детали о самом важном изменении (опционально). Если у команды есть самое важный ключевый проект (как правило они могут занимать больше одного квартала), то тут про него можно рассказать отдельно: как дела, как прогресс, что идёт хорошо, а что не очень.

• Что мы сделали и выпустили. Список вещей, которые команда выпустила или сделана за месяц. Описание в несколько предложений (суть и ценность) и ссылка на What/Why/Outcome документ. У нас принято писать только про вещи, которые стали доступны хоть каким-то живым пользователям (не обязательно всем).

• Дополнительная информация о выпущенных штуках (опционально). Любая информация о выпущенных штуках, на усмотрение команды: видео с демонстрацией, дополнительные скриншоты, первые результаты и так далее.

• Баги/качество/SLA. Данные и метрики, которые описывают качество продукта. Например SLA, решённые и найденные баги и так далее. Эта штука должна балансировать фокус на “выпущенных штуках” и понуждать думать о качестве. Конкретные вещи специфичны для каждого продукта и компании, поэтому дать готовую структуру тут нельзя.

• Новые штуки в планах (опционально). Если в планах появились новые вещи — показываем их тут со ссылкой на их What/Why/Outcome описание.

• Проблемы и риски (опционально). Какие проблемы и риски у нас есть. Если на предыдущих слайдах у нас были проекты в статусе “серьезные риски” — их надо упомянуть тут.

• Решения, которые нужно сделать (опционально). Какие решения требуют вовлечения или одобрения от стейкхолдеров? Про какие решения всем нужно знать? Какие решения не получается принять и с ними нужна помощь?

• Открытый микрофон (опционально). Любая информация, которой команда хочет поделиться, но она не подошла на предыдущие слайды.

• Нужные действия (опционально). В процессе дискуссии появляются задачи ко всем участникам встречи — что-то надо сделать, что-то поправить, на что-то посмотреть повнимательнее. Действия добавляются в процессе звонка или сразу после на этот слайд. В конце встречи команда ревьювает старые действия (сделано/нет/что осталось) и новые.

• Архив. Слайды предыдущих месяцев добавляются сюда.

V. Дополнение
Мы стараемся проводить такие встречи в конце месяца, но до всех остальных ежемесячных и ежеквартальных встреч с другими отделами, c другими менеджментами т.д. То есть перед ними уже есть все данные и апдейты — это сильно упрощает жизнь.

Каждые три месяца “контрольную встречу” рекомендуется делать “большой контрольной встречей” и больше фокусироваться на результатах квартала и целях на следующий. А каждые двенадцать месяцев — “гранд контрольная встреча”.

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

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

VI. Заключение
Компаниям разных размеров и разного уровня взросления нужны разные подходны к информированию о своих новостях и контроле своих команд. “Уровень развития” тут не в смысле “хуже или лучше”, а в смысле — “размер” процесса должен соответствовать размеру компании и команды.

И вот как только внутри компании возникают команды, возникает и необходимость рассказывать “а как у команд дела и здоровье”. А как только у компании возникают внешние обязательства (будь это инвесторы или совет директоров) — возникает необходимость рассказывать “а как у нас дела и здоровье”.

Без пригляда это может превратиться в отдельную штуку, которую надо делать, но в которой никто не видит большой пользы. “Раз в квартал мы всё бросаем и делаем слайды для совета директоров”. Да, в этом тоже есть своя польза, но это отдельная задача про которую вспоминают, когда “уже пора”. В итоге все отвлекаются, возникают проблемы вида “ой, а тут мы не знаем как подсчитать” или там “почему-то метрика показывает совсем другое” и т.д.

Гораздно более лучшим подходом является комбинированный “снизу вверх” и “сверху вниз” подход. Когда с одной стороны информация, которую показывают “наверх” (будь это комитет менеджеров, совет директоров или кто-угодно ещё) повторяет информацию, которую собирают ежемесячно (или даже еженедельно) продакт-менеджеры. Но и информация и данные, которые собирают продакт-менеджеры, основаны на том, что желают видеть “наверху”.

Контрольные “check-in” встречи и слайды это подход к реализации именно этого принципа. Думаю, c небольшими изменениями его можно использовать не только продакт-менеджерами, а и с почти любым направлением.