Я несчётное количество раз видел как какие-то числа и метрики кому-то презентуются, презентовал их сам и получал презентации. Поэтому немного научился видеть классические ошибки в том, как эти данные показывают.
Конечно мне далеко до умения людей, которые смотрят на большие таблички каждый день и которые финансово от этих табличек зависят. Я наблюдал несколько раз за тем, как такие люди с ними работают — у них буквально супер-способность увидеть паттерны и подозрительные места в мешанине чисел.
Мы обычно плохо видим паттерны в числах, если специально не тренировались для этого. Другое дело — лица. Их мы распознаем и отличаем автоматически и очень хорошо. Поэтому, кстати, есть подход, когда числовые данные превращают в лица для дальнейшей обработки (называется identicon или hash avatars, примеры, а ещё есть лица Чернова)
Но чем больше вы работаете с данными, тем лучше вы умеете видеть ситуацию за ними и ещё лучше можете оценивать достаточно ли предоставленных данных, не пытаются ли вас осознанно или неосознанно ввести в заблуждение. Числа всегда можно отобрать и показать так, чтобы оттенить желаемое мнение ("ложь, наглая ложь и статистика"). И я убеждён, что любой компетентный руководитель высокого звена умеет видеть такие манипуляции или недостаток размышлений при презентации данных (но не всегда скажет об этом).
Как же правильно презентовать данные? Хорошая новость в том, что есть набор простых правил и идей, которым можно достаточно механически следовать.
(продолжение)
Конечно мне далеко до умения людей, которые смотрят на большие таблички каждый день и которые финансово от этих табличек зависят. Я наблюдал несколько раз за тем, как такие люди с ними работают — у них буквально супер-способность увидеть паттерны и подозрительные места в мешанине чисел.
Мы обычно плохо видим паттерны в числах, если специально не тренировались для этого. Другое дело — лица. Их мы распознаем и отличаем автоматически и очень хорошо. Поэтому, кстати, есть подход, когда числовые данные превращают в лица для дальнейшей обработки (называется identicon или hash avatars, примеры, а ещё есть лица Чернова)
Но чем больше вы работаете с данными, тем лучше вы умеете видеть ситуацию за ними и ещё лучше можете оценивать достаточно ли предоставленных данных, не пытаются ли вас осознанно или неосознанно ввести в заблуждение. Числа всегда можно отобрать и показать так, чтобы оттенить желаемое мнение ("ложь, наглая ложь и статистика"). И я убеждён, что любой компетентный руководитель высокого звена умеет видеть такие манипуляции или недостаток размышлений при презентации данных (но не всегда скажет об этом).
Как же правильно презентовать данные? Хорошая новость в том, что есть набор простых правил и идей, которым можно достаточно механически следовать.
(продолжение)
(начало)
Две главные идеи:
1. Когда хороший руководитель смотрит на число, то он/она всегда задаёт вопрос:
— Всё хорошо? Должны ли мы продолжать делать то, что мы делаем и побольше? — Всё плохо? Должны ли мы как-то изменить наш курс?
2. Факт или число сами по себе не значат ничего. А иногда могут даже повредить: они создают фальшивое ощущение понимания ситуации.
Поэтому нельзя просто показывать число или факт. Надо всегда объяснять значение и инсайт, который стоит за ним. Добавлять дополнительные числа и факты, которые поддерживают этот инсайт.
Шесть базовых приёмов для этого.
I. Никогда не иметь только абсолютные значение или только проценты. В большинстве случаев вам надо показать и то и то.
Использование только чего-то одного это классический приём для "массажа данных", поэтому всегда вызывает повышенный интерес ("тут пытаются закопать тело"). Особенно если это проценты от процентов ("рейт уменьшения нашего процента оттока уменьшился на 10%").
Примеры:
а) Презентовано: использование фичи выросло на 30%. Ура!
Реальность: 100 пользователей из 10,000 использовало фичу, а стало 130.
б) Презентовано: спустя полгода 800 платных пользователей использует эту штуку. Ура!
Реальность: штука доступна 150,000 платным пользователям, её использует 0.5%.
II. Всегда сравнивать с целым или с большой картиной.
Плохо: наш объём оплат через СБП превысил 100млн.₽.
Хорошо: наш объём оплат через A СБП превысил 100млн.₽, это 10% от всех оплат.
III. Cравнивать с историчными данными.
Плохо: наш объём оплат через СБП превысил 100млн.₽.
Хорошо: наш объём оплат через A СБП превысил 100млн.₽, в прошлом месяце было 70млн. — рост на 43%.
IV. Сравнивать с похожими элементами.
Плохо: наш объём оплат через СБП превысил 100млн.₽.
Хорошо: наш объём оплат через A СБП превысил 100млн.₽, а вот оплаты через карточки — 150млн.₽ Оба метода примерно одинаково популярны.
V. Сравнивать с целью.
Плохо: наш объём оплат через СБП превысил 100млн.₽.
Хорошо: наш объём оплат через A СБП превысил 100млн.₽. Это 125% от нашей цели на год в 80млн.
VI. Когда и как считались данные.
Это опциональная, но полезная привычка. Рядом с расчитанными данными полезно указать когда они были расчитаны и как, указать ссылку на отчёты, репорты откуда они были взяты.
Cоединять разные факты, разрезать текущие числа.
Самая сложная и неконкретная штука из всех, так как к ней нет готовой инструкции. Поэтому без номера.
Если посмотреть на все связанные числа и факты целиком, даже слабосвязанные, то это может привести к неожиданным инсайтам.
Если нарезать текущие данные по разным признакам (по времени, по стране, по браузеру и т.д. и т.п.), то это тоже может привести к неожиданным инсайтам.
Это, разумеется, не полный список. У вас, в вашей специфике и индустрии будут свои особенности. Но посыл и цель показа данных, главный вопрос — вряд ли будет другим:
— Всё хорошо или нет? Должны ли мы продолжать делать то, что мы делаем или надо что-то поменять?
Две главные идеи:
1. Когда хороший руководитель смотрит на число, то он/она всегда задаёт вопрос:
— Всё хорошо? Должны ли мы продолжать делать то, что мы делаем и побольше? — Всё плохо? Должны ли мы как-то изменить наш курс?
2. Факт или число сами по себе не значат ничего. А иногда могут даже повредить: они создают фальшивое ощущение понимания ситуации.
Поэтому нельзя просто показывать число или факт. Надо всегда объяснять значение и инсайт, который стоит за ним. Добавлять дополнительные числа и факты, которые поддерживают этот инсайт.
Шесть базовых приёмов для этого.
I. Никогда не иметь только абсолютные значение или только проценты. В большинстве случаев вам надо показать и то и то.
Использование только чего-то одного это классический приём для "массажа данных", поэтому всегда вызывает повышенный интерес ("тут пытаются закопать тело"). Особенно если это проценты от процентов ("рейт уменьшения нашего процента оттока уменьшился на 10%").
Примеры:
а) Презентовано: использование фичи выросло на 30%. Ура!
Реальность: 100 пользователей из 10,000 использовало фичу, а стало 130.
б) Презентовано: спустя полгода 800 платных пользователей использует эту штуку. Ура!
Реальность: штука доступна 150,000 платным пользователям, её использует 0.5%.
II. Всегда сравнивать с целым или с большой картиной.
Плохо: наш объём оплат через СБП превысил 100млн.₽.
Хорошо: наш объём оплат через A СБП превысил 100млн.₽, это 10% от всех оплат.
III. Cравнивать с историчными данными.
Плохо: наш объём оплат через СБП превысил 100млн.₽.
Хорошо: наш объём оплат через A СБП превысил 100млн.₽, в прошлом месяце было 70млн. — рост на 43%.
IV. Сравнивать с похожими элементами.
Плохо: наш объём оплат через СБП превысил 100млн.₽.
Хорошо: наш объём оплат через A СБП превысил 100млн.₽, а вот оплаты через карточки — 150млн.₽ Оба метода примерно одинаково популярны.
V. Сравнивать с целью.
Плохо: наш объём оплат через СБП превысил 100млн.₽.
Хорошо: наш объём оплат через A СБП превысил 100млн.₽. Это 125% от нашей цели на год в 80млн.
VI. Когда и как считались данные.
Это опциональная, но полезная привычка. Рядом с расчитанными данными полезно указать когда они были расчитаны и как, указать ссылку на отчёты, репорты откуда они были взяты.
Cоединять разные факты, разрезать текущие числа.
Самая сложная и неконкретная штука из всех, так как к ней нет готовой инструкции. Поэтому без номера.
Если посмотреть на все связанные числа и факты целиком, даже слабосвязанные, то это может привести к неожиданным инсайтам.
Если нарезать текущие данные по разным признакам (по времени, по стране, по браузеру и т.д. и т.п.), то это тоже может привести к неожиданным инсайтам.
Это, разумеется, не полный список. У вас, в вашей специфике и индустрии будут свои особенности. Но посыл и цель показа данных, главный вопрос — вряд ли будет другим:
— Всё хорошо или нет? Должны ли мы продолжать делать то, что мы делаем или надо что-то поменять?
Существует такое убеждение, что чем выше мы на лестнице развития, тем больше у нас развита осознанность. Умение отследить каждое свое действие, мысль. Интроспекция своих процессов, саморефлексия. Осознанность подаётся как Святой Грааль, который каждый уважающий себя человек должен искать.
И это полезный инструмент в большинстве случаев. Но как всегда бывает есть нюанс, который прекрасно описывается цитатой математика и философа Alfred North Whitehead:
> It is a profoundly erroneous truism, repeated by all copybooks and by eminent people when they are making speeches, that we should cultivate the habit of thinking of what we are doing. The precise opposite is the case. Civilization advances by extending the number of important operations which we can perform without thinking about them.
Уайтхед утверждает, что развитие цивилизации зависит от уровня абстракций, которыми цивилизация оперирует. Чем глубже абстракции, чем больше сложных систем, которыми мы можем оперировать как единым целым — тем большего может эта цивилизация достичь.
Пример этого мы видим, например, в развитии компьютеров и интернета. Мы открываем пост в Телеграме и не задумываемся, какая пирамида систем уходит вниз, чтобы это произошло — вплоть до уровня, где электрические сигналы туда-сюда бегают.
Конечно в этом есть и минусы. Системы-абстракции используются как есть, поэтому они неоптимальны и нет мотивации что-то кардинально в них улучшать. Изначальные неоптимальности и привычки остаются с нами на долгое время — "так сложилось".
Советы компаниям/стартапам тоже говорят о том, что вот надо "переосмыслить всё", "думать от основ (first principles)" и т.д. И это безусловно верно. Но мало кто говорит о том, какие вещи должны не быть переосмыслены, должны быть взяты как есть: будь это процессы, подходы к управлению или инженерные вещи. Не тратить время на обдумывание действий в одних областях, чтобы его было больше в других.
Поэтому полезно не только переосмысливать и пересобирать вещи, но и решать какие вещи мы переосмысливаем и отслеживаем сильно реже — будь это наши привычки, дефолты, паттерны, подходы, процессы и прочее. Вещи, которые делаются без размышлений, сложные системы, которыми мы оперируем как отдельным простым предметом.
И это полезный инструмент в большинстве случаев. Но как всегда бывает есть нюанс, который прекрасно описывается цитатой математика и философа Alfred North Whitehead:
> It is a profoundly erroneous truism, repeated by all copybooks and by eminent people when they are making speeches, that we should cultivate the habit of thinking of what we are doing. The precise opposite is the case. Civilization advances by extending the number of important operations which we can perform without thinking about them.
Уайтхед утверждает, что развитие цивилизации зависит от уровня абстракций, которыми цивилизация оперирует. Чем глубже абстракции, чем больше сложных систем, которыми мы можем оперировать как единым целым — тем большего может эта цивилизация достичь.
Пример этого мы видим, например, в развитии компьютеров и интернета. Мы открываем пост в Телеграме и не задумываемся, какая пирамида систем уходит вниз, чтобы это произошло — вплоть до уровня, где электрические сигналы туда-сюда бегают.
Конечно в этом есть и минусы. Системы-абстракции используются как есть, поэтому они неоптимальны и нет мотивации что-то кардинально в них улучшать. Изначальные неоптимальности и привычки остаются с нами на долгое время — "так сложилось".
Советы компаниям/стартапам тоже говорят о том, что вот надо "переосмыслить всё", "думать от основ (first principles)" и т.д. И это безусловно верно. Но мало кто говорит о том, какие вещи должны не быть переосмыслены, должны быть взяты как есть: будь это процессы, подходы к управлению или инженерные вещи. Не тратить время на обдумывание действий в одних областях, чтобы его было больше в других.
Поэтому полезно не только переосмысливать и пересобирать вещи, но и решать какие вещи мы переосмысливаем и отслеживаем сильно реже — будь это наши привычки, дефолты, паттерны, подходы, процессы и прочее. Вещи, которые делаются без размышлений, сложные системы, которыми мы оперируем как отдельным простым предметом.
Один из важных артефактов наших продуктовых процессов — check-in meetings или "контрольная встреча".
Давайте поговорим про неё поподробнее, а я покажу как это у нас выглядит.
I. Предпосылки
Если ваша продуктовая команда стала больше пары-тройки человек, то у вас появляются две цели, которые противоречат друг другу.
— С одной стороны, вы хотите бóльшей автономности ваших команд. Чтобы решения принимались сами, а у вас была возможность расширять количество команд.
— С другой стороны, вы хотите, чтобы решения были правильные. То есть совпадали с целями продукта. Чтобы была синхронизация, а не разброд. Чтобы о проблемах вы узнали как можно раньше и ничего не тормозило.
Первая задача требует от вас вовлекаться в ежедневные дела команды меньше. Вторая задача требует вовлекаться больше.
Перекос в ту или иную сторону несёт свои специфичные проблемы. Вы или ограничиваете маштабирование команд, замыкая решения на себя — то есть общая скорость ограничена вашей скоростью и *ёмкостью*, что может работать, но до определенного предела.
Или же у вас теряется управление — все идут в разные стороны, нет фокуса, а о проблемах вы узнаете слишком поздно (когда они уже случились, а не когда появились первые симптомы).
Ситуация становится ещё сложнее, когда в нашей картине мира появляются интересанты из руководителей и других частей компании. Им хочется знать, что происходит в продуктовой команде: а что мы выпустили, а почему, а какой роадмап, а на год, а вот мы выпустили — а какой импакт и так далее и так далее. Этот интерес понятен и справедлив — результаты их работы зависит от продукта, они хотят знать и влиять на продуктовые планы. Но без управления и направления этих запросов — продакт-менеджеры могут быть погребены под этой "бесполезной работой" — готовить слайды, таблички, упаковывать и переупаковывать мысли и идеи снова и снова для сторонних читателей.
Рано или поздно каждая компания вырастает и принимает решение это как-то улучшить. Но решения могут быть разными.
Давайте поговорим про неё поподробнее, а я покажу как это у нас выглядит.
I. Предпосылки
Если ваша продуктовая команда стала больше пары-тройки человек, то у вас появляются две цели, которые противоречат друг другу.
— С одной стороны, вы хотите бóльшей автономности ваших команд. Чтобы решения принимались сами, а у вас была возможность расширять количество команд.
— С другой стороны, вы хотите, чтобы решения были правильные. То есть совпадали с целями продукта. Чтобы была синхронизация, а не разброд. Чтобы о проблемах вы узнали как можно раньше и ничего не тормозило.
Первая задача требует от вас вовлекаться в ежедневные дела команды меньше. Вторая задача требует вовлекаться больше.
Перекос в ту или иную сторону несёт свои специфичные проблемы. Вы или ограничиваете маштабирование команд, замыкая решения на себя — то есть общая скорость ограничена вашей скоростью и *ёмкостью*, что может работать, но до определенного предела.
Или же у вас теряется управление — все идут в разные стороны, нет фокуса, а о проблемах вы узнаете слишком поздно (когда они уже случились, а не когда появились первые симптомы).
Ситуация становится ещё сложнее, когда в нашей картине мира появляются интересанты из руководителей и других частей компании. Им хочется знать, что происходит в продуктовой команде: а что мы выпустили, а почему, а какой роадмап, а на год, а вот мы выпустили — а какой импакт и так далее и так далее. Этот интерес понятен и справедлив — результаты их работы зависит от продукта, они хотят знать и влиять на продуктовые планы. Но без управления и направления этих запросов — продакт-менеджеры могут быть погребены под этой "бесполезной работой" — готовить слайды, таблички, упаковывать и переупаковывать мысли и идеи снова и снова для сторонних читателей.
Рано или поздно каждая компания вырастает и принимает решение это как-то улучшить. Но решения могут быть разными.
II. Решение и его фундаментальные принципы
Решение, на мой взгляд, тут такое: вовлекаться сильно и глубоко, но не часто. В процессе вовлечения генерировать артефакты с информацией, которые имеют высокий уровень переиспользования. А для этого используется check-in встреча и check-in слайды.
Проблема любого процесса, что он имеет свойство занимать весь доступный ему объем (как газ). Добавить процесс или дополнительную работу — просто. Ценность процесса заметна, а недостатки — нет. И в большинстве компаний есть социальные табу на обсуждения нужности новых процессов (особенно если их вносит менеджер) — это не одобряется. В результате процессы и "дополнительная обслуживающая работа" плодятся и занимают всё свободное время.
Одно из решений это подход "хочешь добавить процесс/встречу — убери процесс/встречу". Другой — перед описанием процесса, явно сформулировать его цели и основополагающие принципы (что мы хотим, что мы не хотим).
Что мы хотим:
— Мы хотим убрать необходимость частого вовлечения в жизнь команды и дать ей бóльшую автономность. При этом мы 1) хотим понимать "здоровье" команды(все хорошо? мы на пути к достижению целей или нет?), 2) хотим знать о проблемах и помехах как можно раньше 3) хотим принимать важные решения быстро, чтобы разблокировать команду, если она заблокирована 4) и хотим иметь общий контекст и понимание целей("общие модели мира") — как в компании так и в команде, чтобы команда и компания могла принимать правильные решения сами.
— Мы хотим спрашивать продакт-менеджера и команду о вещах и данных, которые они и так должны знать. И мы хотим, чтобы продакт-менеджер регулярно про эти вещи думал, а на эти метрики смотрел. Мы верим, что это вещи и метрики повышают качество решений команды.
— Мы хотим, чтобы сбор нужных данных, метрик и новостей должно быть легким для продакт-менеджера и команды. Если это пока не легко — должна быть возможность сделать это сильно легче. Процесс должен побуждать сделать этот сбор лёгким.
— Мы хотим, чтобы итогом процесса был артефакт о продуктовых делах команды с очень высоким уровнем переиспользования для всех: от маркетинга и отдела продаж — до менеджмента и PR. Создаем один раз → используем много где. И мы хотим, чтобы этот артефакт был понятен сам по себе, без дополнительных объяснений.
Что мы не хотим:
— Не хотим спрашивать про одни и те же вещи дважды (например в разных форматах и дизайне).
— Не хотим спрашивать вещи в неожиданное время и непредсказуемо. Продакт-менеджер и команда всегда знают, когда от них ожидают новой порции информации и готовятся заранее.
— Не хотим спрашивать новости и данные, которые нам не нужны и которые не будет использовать для принятия решения или проверки "здоровья" команды. Не спрашиваем вещи "на всякий случай, вдруг в будущем будут нужны". Не спрашиваем вещи и данные, цель которых просто продемонстрировать, что команда/продакт-менеджер их имеют.
— Не хотим, чтобы продакт-менеджер думал о дизайне слайдов и о том, как оформить свои мысли.
— Не хотим, чтобы встречи превращались в чтение слайдов, которые и так все могут прочитать. Это очень скучно.
Решение, на мой взгляд, тут такое: вовлекаться сильно и глубоко, но не часто. В процессе вовлечения генерировать артефакты с информацией, которые имеют высокий уровень переиспользования. А для этого используется 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 минут. Достаточно неформальный — два костюма из 5 (👔👔⬜️⬜️⬜️). Читать слайды запрещено. Слайды быстро "прокликиваются". Если у кого-то есть комментарий или вопрос — тогда останавливаемся и обсуждаем.
Процесс основан на двух элементах: сheck-in встреча и check-in документ.
→ Темплейт check-in документа (реальный темплейт из которого я убрал специфичные для нас вещи)
— В конце каждого месяца есть назначенная check-in встреча (звонок) у каждой команды.
— К концу каждого месяца продакт-менеджер c командой работает над обновлением своего документа. Каждый раз это один и тот же документ (его ссылка не меняется, это даёт всем предсказуемость — "обновления всегда тут"). Обновление этого документа происходит в конце месяца, но перед тем как происходят разные другие встречи и события, которые требуют апдейтов. Это даёт возможность подготовить информацию один раз и переиспользовать много.
— Продакт-менеджер дублирует слайды прошлого месяца. Старые уносит в конец документа и скрывает. Новые — обновляет. Так как это обновление существующих слайдов — это делать всегда проще и быстрее, чем создавать что-то с нуля.
— Дизайн документа менять нельзя, только контент (ну и размер текста в некоторый редких исключений). Это упрощает его создание, переиспользование и чтение (когда вам надо посмотреть 20 таких документов).
— Готовый документ посылается участникам встречи и опционально всей продуктовой команде (рекомендуемый вариант) за день-два до самого звонка. У всех есть время его внимательно почитать и задать вопросы в комментариях. Мы ожидаем, что большинство вопросов и обсуждений будут в комментариях до звонка.
— На звонок приглашены все важные интересанты. Например это могут быть продакт-лид, инженерный лид и дизайн-лид команды и руководитель продукта. Опционально члены команды. В зависимости от команды и направления могут быть ещё кто-то. Но к добавлению новых людей к звонку надо подходить осторожно, чтобы сохранить атмосферу в которой всё ещё комфортно говорить о проблемах, недостатках и некомфортных вещах. Также именно поэтому не рекомендуется записывать звонок.
— Звонок занимает 30 минут. Достаточно неформальный — два костюма из 5 (👔👔⬜️⬜️⬜️). Читать слайды запрещено. Слайды быстро "прокликиваются". Если у кого-то есть комментарий или вопрос — тогда останавливаемся и обсуждаем.
IV. Описание темплейта документа
Давайте посмотрим на каждый слайд шаблона и его цель повнимательнее. (слайды на английском)
— Обложка
Имя сквода, дата обновления и по возможности — имена или фотографии команды. Кто сделал те штуки, про которые мы рассказываем дальше.
— Миссия, виденье и стратегия
Здесь у нас краткое в пару предложений описание цели существования команды. Ссылки на документ с виденьем, стратегием и дэшбордом с основными метриками.
— Метрики команды, месячные и квартальные
Самые главные метрики команды. Как правило именно по ним поставлены цели. Команда показывает значение метрики за прошлые периоды, за текущий, динамику изменения, цель на год и каков наш прогноз по достижению цели. В комментариях добавляется информация о дате получении метрик, ссылки на репорты откуда их взяли и любая дополнительная информация. Важно не только показать метрики, но и написать как и когда их собрали — это избавляет от множества проблем.
— Дополнительные метрики команды (опционально)
Любые дополнительные метрики, которыми команда хочет поделиться или похвалиться.
— Что мы выпустили, планы и над чем работаем прямо сейчас.
Список задач, проектов и фокусов, которыми занимается команда. Это не обязательно прям "фича", это именно фокус. Каждая задача ссылается на What/Why/Outcome документ с дополнительными деталями.
Проекты помечены особым образом. У них есть статус оценка риска: ✅ – запущено, ❌ – решили не делать, 🟢 – всё по плану, 🟡 – есть риски, 🔴 – очень серьезные риски, скорее всего не сделаем вовремя. Также примерный прогноз выпуска с точностью до месяца. Самые важные вещи отмечены жирным — важное, это когда вот именно штуку мы хотим сделать точно. И мы готовы жертвовать другими проектами ради этого, если нужно будет выбирать.
Если проект мы не успели сделать в квартале — он переходит на следующий (если мы все же хотим его сделать). В этом случае он должен быть явно помечен ("перенесли с квартала X").
Задачи и фокусы на следующие кварталы должны восприниматься как предварительный план, а не жёсткое обещание.
— Детали о самом важном изменении (опционально)
Если у команды есть самое важный ключевый проект (как правило они могут занимать больше одного квартала), то тут про него можно рассказать отдельно: как дела, как прогресс, что идёт хорошо, а что не очень.
— Что мы сделали и выпустили
Список вещей, которые команда выпустила или сделана за месяц. Описание в несколько предложений (суть и ценность) и ссылка на What/Why/Outcome документ. У нас принято писать только про вещи, которые стали доступны хоть каким-то живым пользователям (не обязательно всем).
— Дополнительная информация о выпущенных штуках (опционально)
Любая информация о выпущенных штуках, на усмотрение команды: видео с демонстрацией, дополнительные скриншоты, первые результаты и так далее.
— Баги/качество/SLA
Данные и метрики, которые описывают качество продукта. Например SLA, решённые и найденные баги и так далее. Эта штука должна балансировать фокус на "выпущенных штуках" и понуждать думать о качестве. Конкретные вещи специфичны для каждого продукта и компании, поэтому дать готовую структуру тут нельзя.
— Новые штуки в планах (опционально)
Если в планах появились новые вещи — показываем их тут со ссылкой на их What/Why/Outcome описание.
Давайте посмотрим на каждый слайд шаблона и его цель повнимательнее. (слайды на английском)
— Обложка
Имя сквода, дата обновления и по возможности — имена или фотографии команды. Кто сделал те штуки, про которые мы рассказываем дальше.
— Миссия, виденье и стратегия
Здесь у нас краткое в пару предложений описание цели существования команды. Ссылки на документ с виденьем, стратегием и дэшбордом с основными метриками.
— Метрики команды, месячные и квартальные
Самые главные метрики команды. Как правило именно по ним поставлены цели. Команда показывает значение метрики за прошлые периоды, за текущий, динамику изменения, цель на год и каков наш прогноз по достижению цели. В комментариях добавляется информация о дате получении метрик, ссылки на репорты откуда их взяли и любая дополнительная информация. Важно не только показать метрики, но и написать как и когда их собрали — это избавляет от множества проблем.
— Дополнительные метрики команды (опционально)
Любые дополнительные метрики, которыми команда хочет поделиться или похвалиться.
— Что мы выпустили, планы и над чем работаем прямо сейчас.
Список задач, проектов и фокусов, которыми занимается команда. Это не обязательно прям "фича", это именно фокус. Каждая задача ссылается на What/Why/Outcome документ с дополнительными деталями.
Проекты помечены особым образом. У них есть статус оценка риска: ✅ – запущено, ❌ – решили не делать, 🟢 – всё по плану, 🟡 – есть риски, 🔴 – очень серьезные риски, скорее всего не сделаем вовремя. Также примерный прогноз выпуска с точностью до месяца. Самые важные вещи отмечены жирным — важное, это когда вот именно штуку мы хотим сделать точно. И мы готовы жертвовать другими проектами ради этого, если нужно будет выбирать.
Если проект мы не успели сделать в квартале — он переходит на следующий (если мы все же хотим его сделать). В этом случае он должен быть явно помечен ("перенесли с квартала X").
Задачи и фокусы на следующие кварталы должны восприниматься как предварительный план, а не жёсткое обещание.
— Детали о самом важном изменении (опционально)
Если у команды есть самое важный ключевый проект (как правило они могут занимать больше одного квартала), то тут про него можно рассказать отдельно: как дела, как прогресс, что идёт хорошо, а что не очень.
— Что мы сделали и выпустили
Список вещей, которые команда выпустила или сделана за месяц. Описание в несколько предложений (суть и ценность) и ссылка на What/Why/Outcome документ. У нас принято писать только про вещи, которые стали доступны хоть каким-то живым пользователям (не обязательно всем).
— Дополнительная информация о выпущенных штуках (опционально)
Любая информация о выпущенных штуках, на усмотрение команды: видео с демонстрацией, дополнительные скриншоты, первые результаты и так далее.
— Баги/качество/SLA
Данные и метрики, которые описывают качество продукта. Например SLA, решённые и найденные баги и так далее. Эта штука должна балансировать фокус на "выпущенных штуках" и понуждать думать о качестве. Конкретные вещи специфичны для каждого продукта и компании, поэтому дать готовую структуру тут нельзя.
— Новые штуки в планах (опционально)
Если в планах появились новые вещи — показываем их тут со ссылкой на их What/Why/Outcome описание.
— Проблемы и риски (опционально)
Какие проблемы и риски у нас есть. Если на предыдущих слайдах у нас были проекты в статусе "серьезные риски" — их надо упомянуть тут.
— Решения, которые нужно сделать (опционально)
Какие решения требуют вовлечения или одобрения от стейкхолдеров? Про какие решения всем нужно знать? Какие решения не получается принять и с ними нужна помощь?
— Открытый микрофон (опционально)
Любая информация, которой команда хочет поделиться, но она не подошла на предыдущие слайды.
— Нужные действия (опционально)
В процессе дискуссии появляются задачи ко всем участникам встречи — что-то надо сделать, что-то поправить, на что-то посмотреть повнимательнее. Действия добавляются в процессе звонка или сразу после на этот слайд. В конце встречи команда ревьювает старые действия (сделано/нет/что осталось) и новые.
— Архив
Слайды предыдущих месяцев добавляются сюда.
Какие проблемы и риски у нас есть. Если на предыдущих слайдах у нас были проекты в статусе "серьезные риски" — их надо упомянуть тут.
— Решения, которые нужно сделать (опционально)
Какие решения требуют вовлечения или одобрения от стейкхолдеров? Про какие решения всем нужно знать? Какие решения не получается принять и с ними нужна помощь?
— Открытый микрофон (опционально)
Любая информация, которой команда хочет поделиться, но она не подошла на предыдущие слайды.
— Нужные действия (опционально)
В процессе дискуссии появляются задачи ко всем участникам встречи — что-то надо сделать, что-то поправить, на что-то посмотреть повнимательнее. Действия добавляются в процессе звонка или сразу после на этот слайд. В конце встречи команда ревьювает старые действия (сделано/нет/что осталось) и новые.
— Архив
Слайды предыдущих месяцев добавляются сюда.
V. Дополнение
Мы стараемся проводить такие встречи в конце месяца, но до всех остальных ежемесячных и ежеквартальных встреч с другими отделами, c другими менеджментами т.д. То есть перед ними уже есть все данные и апдейты — это сильно упрощает жизнь.
Каждые три месяца "контрольную встречу" рекомендуется делать "большой контрольной встречей" и больше фокусироваться на результатах квартала и целях на следующий. А каждые двенадцать месяцев — "гранд контрольная встреча".
Переиспользование данных и апдейтов это ключевая мысль этого процесса. Поэтому я ещё раз отдельно подчеркну, что следует следить за тем, чтобы использовался всегда один и тот же темплейт без изменений. Темплейт можно и нужно улучшать — но сразу для всех. Это позволяет не только легче обновлять его каждый месяц, но и весьма просто собирать результаты каждого сквода в обобщающий документ "результаты продукта за месяц".
В идеале одинаковые темплейты должны использоваться везде и данные с апдейтами легко текут снизу вверх. Ведь гораздо проще (буквально скопировать и вставить)собрать апдейты с команд, отобрать самое важное и в том же самом темплейте показать дальше.
Мы стараемся проводить такие встречи в конце месяца, но до всех остальных ежемесячных и ежеквартальных встреч с другими отделами, c другими менеджментами т.д. То есть перед ними уже есть все данные и апдейты — это сильно упрощает жизнь.
Каждые три месяца "контрольную встречу" рекомендуется делать "большой контрольной встречей" и больше фокусироваться на результатах квартала и целях на следующий. А каждые двенадцать месяцев — "гранд контрольная встреча".
Переиспользование данных и апдейтов это ключевая мысль этого процесса. Поэтому я ещё раз отдельно подчеркну, что следует следить за тем, чтобы использовался всегда один и тот же темплейт без изменений. Темплейт можно и нужно улучшать — но сразу для всех. Это позволяет не только легче обновлять его каждый месяц, но и весьма просто собирать результаты каждого сквода в обобщающий документ "результаты продукта за месяц".
В идеале одинаковые темплейты должны использоваться везде и данные с апдейтами легко текут снизу вверх. Ведь гораздо проще (буквально скопировать и вставить)собрать апдейты с команд, отобрать самое важное и в том же самом темплейте показать дальше.
VI. Заключение
Компаниям разных размеров и разного уровня взросления нужны разные подходны к информированию о своих новостях и контроле своих команд. "Уровень развития" тут не в смысле "хуже или лучше", а в смысле — "размер" процесса должен соответствовать размеру компании и команды.
И вот как только внутри компании возникают команды, возникает и необходимость рассказывать "а как у команд дела и здоровье". А как только у компании возникают внешние обязательства (будь это инвесторы или совет директоров) — возникает необходимость рассказывать "а как у нас дела и здоровье".
Без пригляда это может превратиться в отдельную штуку, которую надо делать, но в которой никто не видит большой пользы. "Раз в квартал мы всё бросаем и делаем слайды для совета директоров". Да, в этом тоже есть своя польза, но это отдельная задача про которую вспоминают, когда "уже пора". В итоге все отвлекаются, возникают проблемы вида "ой, а тут мы не знаем как подсчитать" или там "почему-то метрика показывает совсем другое" и т.д.
Гораздно более лучшим подходом является комбинированный "снизу вверх" и "сверху вниз" подход. Когда с одной стороны информация, которую показывают "наверх" (будь это комитет менеджеров, совет директоров или кто-угодно ещё) повторяет информацию, которую собирают ежемесячно (или даже еженедельно) продакт-менеджеры. Но и информация и данные, которые собирают продакт-менеджеры, основаны на том, что желают видеть "наверху".
Контрольные "check-in" встречи и слайды это подход к реализации именно этого принципа. Думаю, c небольшими изменениями его можно использовать не только продакт-менеджерами, а и с почти любым направлением.
Компаниям разных размеров и разного уровня взросления нужны разные подходны к информированию о своих новостях и контроле своих команд. "Уровень развития" тут не в смысле "хуже или лучше", а в смысле — "размер" процесса должен соответствовать размеру компании и команды.
И вот как только внутри компании возникают команды, возникает и необходимость рассказывать "а как у команд дела и здоровье". А как только у компании возникают внешние обязательства (будь это инвесторы или совет директоров) — возникает необходимость рассказывать "а как у нас дела и здоровье".
Без пригляда это может превратиться в отдельную штуку, которую надо делать, но в которой никто не видит большой пользы. "Раз в квартал мы всё бросаем и делаем слайды для совета директоров". Да, в этом тоже есть своя польза, но это отдельная задача про которую вспоминают, когда "уже пора". В итоге все отвлекаются, возникают проблемы вида "ой, а тут мы не знаем как подсчитать" или там "почему-то метрика показывает совсем другое" и т.д.
Гораздно более лучшим подходом является комбинированный "снизу вверх" и "сверху вниз" подход. Когда с одной стороны информация, которую показывают "наверх" (будь это комитет менеджеров, совет директоров или кто-угодно ещё) повторяет информацию, которую собирают ежемесячно (или даже еженедельно) продакт-менеджеры. Но и информация и данные, которые собирают продакт-менеджеры, основаны на том, что желают видеть "наверху".
Контрольные "check-in" встречи и слайды это подход к реализации именно этого принципа. Думаю, c небольшими изменениями его можно использовать не только продакт-менеджерами, а и с почти любым направлением.
Я уже делился описаниями части наших продуктовых процессов: еженедельное письмо, продуктовый питч, документы What/Why/Outcome, контрольные встречи.
Сегодня поделюсь последней частью, про которую хочу пока рассказать. Про то, как это это всё работает вместе и почему оно работает именно так.
☞ Продуктовые встречи и процессы в Ecwid (2024)
Сегодня поделюсь последней частью, про которую хочу пока рассказать. Про то, как это это всё работает вместе и почему оно работает именно так.
☞ Продуктовые встречи и процессы в Ecwid (2024)
В работе над одним проектом мне потребовалось кратко сформулировать идею «а что же такое онбоардинг и как его надо делать». Ниже — мои мысли на эту тему (на июнь 2024).
☞ Размышления про онбоардинг
☞ Размышления про онбоардинг
Существует такое важное понятие как «агентность». Его можно описать как способность человека действовать как самостоятельный агент, а точнее способность:
— Иметь свои собственные цели и знать про них
— Действовать так, чтобы этих целей достигать
Если упрощать ещё, то это умение «хотеть» и «брать». Без этой способности наш ум становится машиной, работающей вхолостую.
И этому можно научится. Причем достаточно механически — следуй определенному алгоритму и гарантированно ваша агентность станет выше. Вот один из таких алгоритмов, которой помогает увеличить агентность при решении проблем.
# У вас есть проблема. Вы её сейчас решаете?
1. Нет, не решаю проблему.Вопрос: вы в «режиме жертвы»?
1.1 Да, в режиме жертвы(проблему не решаю): ответьте на следующие вопросы.
— А что если это всё же возможно?
— Какое самое глупое, простое действие вы можете совершить, чтобы хотя бы чуть-чуть продвинуться в решении?
1.2 Нет, не в режиме жертвы (проблему не решаю): ответьте на следующие вопросы.
— (настоящее) Что вы делаете прямо сейчас для решения?
— (цель) Как в деталях выглядит мир после того, как у вас всё получится? Как выглядит успех и решение проблемы? Что на самом деле вы хотите сделать? Через год, что бы вы хотели отметить с друзьями?
— (почему) Почему вы хотите решить эту проблему?
— (проблема) Что является текущим препятствием? Опишите проблему в деталях? Что заставляет или может заставить вас прокрастинировать при её решении?
— (решения) Какие идеи потенциально могут сработать?
— (план) Если мы возьмем самую лучшую, простую или наиболее понравившуюся идею — какой у вас план?
— (следующий шаг) Каков ваш немедленный и ближайший следующий шаг?
— (помощь) Кто или что может вам помочь с проблемой и штуками, где мы слабы?
— (окружение) Как вы можете настроить свое социальное окружение, чтобы: 1) поддерживать свою мотивацию, и 2) избегать разочарований и отвлечений?
2. Да, решаю сейчас проблему. Ответьте на следующие вопросы.
— Как в деталях выглядит мир после того, как у вас всё получится?
— Какова связь между тем, что вы делаете сейчас, вашим планом и целью?
— Иметь свои собственные цели и знать про них
— Действовать так, чтобы этих целей достигать
Если упрощать ещё, то это умение «хотеть» и «брать». Без этой способности наш ум становится машиной, работающей вхолостую.
И этому можно научится. Причем достаточно механически — следуй определенному алгоритму и гарантированно ваша агентность станет выше. Вот один из таких алгоритмов, которой помогает увеличить агентность при решении проблем.
# У вас есть проблема. Вы её сейчас решаете?
1. Нет, не решаю проблему.Вопрос: вы в «режиме жертвы»?
1.1 Да, в режиме жертвы(проблему не решаю): ответьте на следующие вопросы.
— А что если это всё же возможно?
— Какое самое глупое, простое действие вы можете совершить, чтобы хотя бы чуть-чуть продвинуться в решении?
1.2 Нет, не в режиме жертвы (проблему не решаю): ответьте на следующие вопросы.
— (настоящее) Что вы делаете прямо сейчас для решения?
— (цель) Как в деталях выглядит мир после того, как у вас всё получится? Как выглядит успех и решение проблемы? Что на самом деле вы хотите сделать? Через год, что бы вы хотели отметить с друзьями?
— (почему) Почему вы хотите решить эту проблему?
— (проблема) Что является текущим препятствием? Опишите проблему в деталях? Что заставляет или может заставить вас прокрастинировать при её решении?
— (решения) Какие идеи потенциально могут сработать?
— (план) Если мы возьмем самую лучшую, простую или наиболее понравившуюся идею — какой у вас план?
— (следующий шаг) Каков ваш немедленный и ближайший следующий шаг?
— (помощь) Кто или что может вам помочь с проблемой и штуками, где мы слабы?
— (окружение) Как вы можете настроить свое социальное окружение, чтобы: 1) поддерживать свою мотивацию, и 2) избегать разочарований и отвлечений?
2. Да, решаю сейчас проблему. Ответьте на следующие вопросы.
— Как в деталях выглядит мир после того, как у вас всё получится?
— Какова связь между тем, что вы делаете сейчас, вашим планом и целью?
Я уже писал, что рано или поздно при обдумывании "работ" в JTBD все приходят к мысли, что людям-то нужна одна штука: чувствовать счастья больше и чаще, а боли ощущать как можно меньше и реже. Ради этого придумывают разные штуки, строят сложные абстрактные конструкции.
Как водится — если мысль правильная, то кто-то её уже высказывал. В нашем случае Эпикур — основатель эпикурейства. Заметный древнегреческий философ, который оставил нам слово и термин, но убеждения которого нынче не так известны массово (не так как поп-стоицизм)
Вкратце Эпикур и его последователи утверждали следующее:
— Цель жизни — наслаждение. Наслаждение это хорошо и благо, а боль — зло. Поэтому надо стремиться к наслаждению и избегать боли. В этом заключается причина и цель всех человеческих поступков.
— Удовольствия бывают активные (от действия) и статические (от текущего состояния). Радость "делать" и радость "пребывать", как например "удовольствие от еды" и "удовольствие от отсутствия голода". Не быть голодным это не просто отсутствие страданий. Не быть голодным — это наслаждение. Отстутствие страданий само по себе наслаждение.
— Активное наслаждение количественно (больше делаем — больше удовольствие). А статичное как правило конечно. Его нельзя наполнить больше определенного.
— Есть четыре вида наслаждений: а) активные телесные (например от еды) б) статичные телесные (например от отсутствия чувства голода) в) активные душевные (беседа с друзьями) г) Статичные душевные (от отсуствия беспокойства от чего-либо). Все наслаждения хороши, но по мнению Эпикура последнее (отсутствие беспокойства, тревог, страха) — самое важное. Это "атараксия" и к ней стоит стремится.
— Душевные страдания чаще могут быть сильнее телесных. Люди часто страдают от тревожных мыслей о предстоящих возможных страданий, чем от страданий как таковых. И тревожные мысли более продолжительные, чем само реальное страдание о котором тревожатся. И наоборот — душевные удовольствия могут перевесить физические страдания.
— Человек взвешивает различные страдания и наслаждения. И выбирает тот путь, который в итоге перевесит в "общей сумме". Порой мы воздерживаемся от удовольствий здесь и сейчас — если они могут дать бóльшее удовольствие в будущем или же позволят избежать больших страданий. Или согласны на страдание здесь или сейчас из-за этого же.
Эти выкладки кажутся интуитивно верными. В нейронауках вам тоже сразу расскажут про бесконечный танец возбуждения и торможения нейронов(происходит и то и то одновременно, сильно упрощая — побеждает сумма общего импульса), который в итоге определяет наши решения.
Какие из этой штуки следуют мысли.
Как водится — если мысль правильная, то кто-то её уже высказывал. В нашем случае Эпикур — основатель эпикурейства. Заметный древнегреческий философ, который оставил нам слово и термин, но убеждения которого нынче не так известны массово (не так как поп-стоицизм)
Вкратце Эпикур и его последователи утверждали следующее:
— Цель жизни — наслаждение. Наслаждение это хорошо и благо, а боль — зло. Поэтому надо стремиться к наслаждению и избегать боли. В этом заключается причина и цель всех человеческих поступков.
— Удовольствия бывают активные (от действия) и статические (от текущего состояния). Радость "делать" и радость "пребывать", как например "удовольствие от еды" и "удовольствие от отсутствия голода". Не быть голодным это не просто отсутствие страданий. Не быть голодным — это наслаждение. Отстутствие страданий само по себе наслаждение.
— Активное наслаждение количественно (больше делаем — больше удовольствие). А статичное как правило конечно. Его нельзя наполнить больше определенного.
— Есть четыре вида наслаждений: а) активные телесные (например от еды) б) статичные телесные (например от отсутствия чувства голода) в) активные душевные (беседа с друзьями) г) Статичные душевные (от отсуствия беспокойства от чего-либо). Все наслаждения хороши, но по мнению Эпикура последнее (отсутствие беспокойства, тревог, страха) — самое важное. Это "атараксия" и к ней стоит стремится.
— Душевные страдания чаще могут быть сильнее телесных. Люди часто страдают от тревожных мыслей о предстоящих возможных страданий, чем от страданий как таковых. И тревожные мысли более продолжительные, чем само реальное страдание о котором тревожатся. И наоборот — душевные удовольствия могут перевесить физические страдания.
— Человек взвешивает различные страдания и наслаждения. И выбирает тот путь, который в итоге перевесит в "общей сумме". Порой мы воздерживаемся от удовольствий здесь и сейчас — если они могут дать бóльшее удовольствие в будущем или же позволят избежать больших страданий. Или согласны на страдание здесь или сейчас из-за этого же.
Эти выкладки кажутся интуитивно верными. В нейронауках вам тоже сразу расскажут про бесконечный танец возбуждения и торможения нейронов(происходит и то и то одновременно, сильно упрощая — побеждает сумма общего импульса), который в итоге определяет наши решения.
Какие из этой штуки следуют мысли.
1) Подход с разными видами наслаждения и страданий c некоторыми условностями можно применять как ещё один фреймворк приоритизации, рассказа о ценности продукта, сравнения продуктов.
Главная условность в том, что считать "телесным" или "душевным" удовольствием / страданием при работе с "эфемерными" продуктами. "Телесное" как "происходящее в моменте и более заземлённое" в противовес "душевному как более абстрактному"? Слишком натянуто, поэтому сложно использовать.
В отличие от разделения на "активные" и "статичные" удовольствия. Эта штука уже гораздо интереснее, так как рассматривает общее удовольствие от продукта или процесса как комбинацию двух частей: удовольствие от получения чего-то хорошего и удовольствие от избегания чего-то нехорошего.
Более того, переключение на новый продукт тоже связано с сопряженным новым наслаждением и новым страданием ("надо учиться новому — сложно"). В итоге у нас есть общий импульс от наслаждения/страдания от использования текущего продукта + потенциальное(обещанное) наслаждение/страдание от переключения на новый продукт. Если общий импульс достаточно большой — человек переключается.
2) Другая мысль связана с нашим избеганием страдания как широкого явления. Мы не любим страдать и выберем короткий путь, уговор себя и т.д. лишь бы потенциального страдания избежать.
Я пришёл к мысли, что качественный рост связан с умением управлять этим избеганием. Или другими простыми словами — ищи боль, не избегай её, оставайся с болью, боль как цель. Sequere dolorem (любая банальная мысль, выраженная латинским, сразу звучит мудрее).
Боль как нежелание делать сложное, как постоянные неудачные попытки, как балансировка на грани "да ну его". Это и "разобраться до конца в сложной проблеме, когда хочется выбрать простой путь и закрыть глаза на детали", но и "почитать на ночь дочери книгу, когда хочется посмотреть сериал".
Вспоминая свой прошлый опыт, я вижу, что самые значительные профессиональные трансформации произошли, когда мне было очень некомфортно. Когда хотелось бросить, но не бросил.
Очень небольшое число болей и страданий — правильная цель. Мы можем терпеть боль ради привычки или боязни изменений, которые обещают нам (скорее всего ложно) еще большую боль. Терпеть камешек в ботинке стоит только если это такой кинки-способ проверить свою силу воли. Выбор "какую боль терпеть" очень важный.
Нужная боль — меняет нас и ведёт к выбранной цели. Должны соблюдаться оба правила — и наблюдаемые изменения (если изменений нет — зачем это всё?) и изменения в нужную сторону (если вас бить кнутом, то вы сможете быстро научится отбивать чечётку — но стоит ли это того?). Но если выбор сделан, то эту боль можно научится ценить и радоваться ей — ведь она обещает будущие наслаждения от лучшей версии себя.
Главная условность в том, что считать "телесным" или "душевным" удовольствием / страданием при работе с "эфемерными" продуктами. "Телесное" как "происходящее в моменте и более заземлённое" в противовес "душевному как более абстрактному"? Слишком натянуто, поэтому сложно использовать.
В отличие от разделения на "активные" и "статичные" удовольствия. Эта штука уже гораздо интереснее, так как рассматривает общее удовольствие от продукта или процесса как комбинацию двух частей: удовольствие от получения чего-то хорошего и удовольствие от избегания чего-то нехорошего.
Более того, переключение на новый продукт тоже связано с сопряженным новым наслаждением и новым страданием ("надо учиться новому — сложно"). В итоге у нас есть общий импульс от наслаждения/страдания от использования текущего продукта + потенциальное(обещанное) наслаждение/страдание от переключения на новый продукт. Если общий импульс достаточно большой — человек переключается.
2) Другая мысль связана с нашим избеганием страдания как широкого явления. Мы не любим страдать и выберем короткий путь, уговор себя и т.д. лишь бы потенциального страдания избежать.
Я пришёл к мысли, что качественный рост связан с умением управлять этим избеганием. Или другими простыми словами — ищи боль, не избегай её, оставайся с болью, боль как цель. Sequere dolorem (любая банальная мысль, выраженная латинским, сразу звучит мудрее).
Боль как нежелание делать сложное, как постоянные неудачные попытки, как балансировка на грани "да ну его". Это и "разобраться до конца в сложной проблеме, когда хочется выбрать простой путь и закрыть глаза на детали", но и "почитать на ночь дочери книгу, когда хочется посмотреть сериал".
Вспоминая свой прошлый опыт, я вижу, что самые значительные профессиональные трансформации произошли, когда мне было очень некомфортно. Когда хотелось бросить, но не бросил.
Очень небольшое число болей и страданий — правильная цель. Мы можем терпеть боль ради привычки или боязни изменений, которые обещают нам (скорее всего ложно) еще большую боль. Терпеть камешек в ботинке стоит только если это такой кинки-способ проверить свою силу воли. Выбор "какую боль терпеть" очень важный.
Нужная боль — меняет нас и ведёт к выбранной цели. Должны соблюдаться оба правила — и наблюдаемые изменения (если изменений нет — зачем это всё?) и изменения в нужную сторону (если вас бить кнутом, то вы сможете быстро научится отбивать чечётку — но стоит ли это того?). Но если выбор сделан, то эту боль можно научится ценить и радоваться ей — ведь она обещает будущие наслаждения от лучшей версии себя.
Хороший продакт-менеджер должен уметь принимать решения и действовать в условиях нехватки информации. А прекрасный продакт-менеджер должен ещё обладать определенным двоемыслием — умением одновременно держать в голове две противоречащие друг другу идеи. Продакт-менеджер должен одновременно и любить свой продукт и считать его замечательным, но одновременно считать его плохим и недостойным мира.
Про это хорошо сказал Честертон в «Ортодоксии»:
> Но для веры и мятежа нужно не вяло принимать мир — «на худой конец сойдет», а ненавидеть всем сердцем и всем сердцем любить. Нам не нужно, чтобы радость и гнев смешивались в унылом довольстве, — мы хотим яростной радости и яростного гнева. Мир должен быть для нас замком людоеда, который мы обязаны взять, и собственным коттеджем, куда мы можем вернуться под вечер.
> Без сомнения, обычный человек способен примириться с миром, но этого мало. Способен ли он ненавидеть мир так сильно, чтобы его изменить, и любить так сильно, чтобы счесть достойным перемены? Способен ли узнать, как здесь плохо, и не впасть в отчаяние? Способен ли он, словом, быть не только оптимистом и не только пессимистом, но одержимым оптимистом и одержимым пессимистом? Я утверждаю, что разумный оптимист тут провалится, неразумный — восторжествует.
Если к продукту нет ни любви ни ненависти, то возникает безразличие. Безразличие к настоящему, безразличие к возможному будущему успеху или неуспеху. Продакт-менеджер по прежнему может делать правильные вещи "на навыке", но так можно сделать только что-то среднее и обычное. Чтобы сделать скачок от "ок" к "круто" — продукт надо любить.
От любви он идёт дальше, копает глубже, вкладывает себя. Соглашается испытывать боль. Забота и вера в продукт — питательная среда для роста чего-то великого.
Но если у продакт-менеджера есть только любовь, то этого недостаточно. Если цветок перелить водой — он погибнет точно также, как и от недолива. Нужно уметь чётко видеть недостатки продукта и ненавидеть их всей душой. Хотеть устранить. Ведь именно безусловная слепая любовь приводит к отторжению любого негативного мнения и фидбэка. К закукливанию и медленному замерзанию в пузыре воображаемого тепла.
Эта ненависть к текущему положению дел — движущая сила, горящий огонь внутри, который заставляет не почивать на лавра и принять status quo, а неутомимо стремится к чему-то лучшему.
Но если у продакт-менеджера есть только эта ненависть, но нет любви — это приводит к опусканию рук. Циничному "тут так все плохо, что ничего не исправить — так стоит ли стараться?"
Только комбинация двух штук приводит к нужному результату. Повторяя и перефразируя Честертона: "надо ненавидеть продукт так сильно, чтобы его изменить, и любить так сильно, чтобы счесть достойным перемены".
Про это хорошо сказал Честертон в «Ортодоксии»:
> Но для веры и мятежа нужно не вяло принимать мир — «на худой конец сойдет», а ненавидеть всем сердцем и всем сердцем любить. Нам не нужно, чтобы радость и гнев смешивались в унылом довольстве, — мы хотим яростной радости и яростного гнева. Мир должен быть для нас замком людоеда, который мы обязаны взять, и собственным коттеджем, куда мы можем вернуться под вечер.
> Без сомнения, обычный человек способен примириться с миром, но этого мало. Способен ли он ненавидеть мир так сильно, чтобы его изменить, и любить так сильно, чтобы счесть достойным перемены? Способен ли узнать, как здесь плохо, и не впасть в отчаяние? Способен ли он, словом, быть не только оптимистом и не только пессимистом, но одержимым оптимистом и одержимым пессимистом? Я утверждаю, что разумный оптимист тут провалится, неразумный — восторжествует.
Если к продукту нет ни любви ни ненависти, то возникает безразличие. Безразличие к настоящему, безразличие к возможному будущему успеху или неуспеху. Продакт-менеджер по прежнему может делать правильные вещи "на навыке", но так можно сделать только что-то среднее и обычное. Чтобы сделать скачок от "ок" к "круто" — продукт надо любить.
От любви он идёт дальше, копает глубже, вкладывает себя. Соглашается испытывать боль. Забота и вера в продукт — питательная среда для роста чего-то великого.
Но если у продакт-менеджера есть только любовь, то этого недостаточно. Если цветок перелить водой — он погибнет точно также, как и от недолива. Нужно уметь чётко видеть недостатки продукта и ненавидеть их всей душой. Хотеть устранить. Ведь именно безусловная слепая любовь приводит к отторжению любого негативного мнения и фидбэка. К закукливанию и медленному замерзанию в пузыре воображаемого тепла.
Эта ненависть к текущему положению дел — движущая сила, горящий огонь внутри, который заставляет не почивать на лавра и принять status quo, а неутомимо стремится к чему-то лучшему.
Но если у продакт-менеджера есть только эта ненависть, но нет любви — это приводит к опусканию рук. Циничному "тут так все плохо, что ничего не исправить — так стоит ли стараться?"
Только комбинация двух штук приводит к нужному результату. Повторяя и перефразируя Честертона: "надо ненавидеть продукт так сильно, чтобы его изменить, и любить так сильно, чтобы счесть достойным перемены".
Мне задали вопрос:
> Какие есть секреты по постепенному развороту большой организации от денежных метрик (условного GMV) к продуктовым? Какие трюки хорошо сработали в твоем опыте? Если вообще была такая проблема в эквиде
В ответе есть две части: про метрики и про разворот большой компании.
1) Метрики это проекция реального мира на числа. Они дают управляемость и позволяют работать с этой моделью мира. Но как и любая модель — не описывают мир во всех его деталях, могут ошибаться.
Как и у гипотез — ошибки модели сводятся к двум общим типам:
— Ложноотрицательные: в реальном мире что-то произошло, но метрики этого не показали.
— Ложноположительные: метрики что-то показали и объяснили, мы пришли к какому-то заключению, но в реальном мире этого нет или же причина изменений метрик — другая.
Правильная модель стремится к минимизации этих ошибок. Чтобы метрика была достаточно чувствительна, чтобы реагировать на наши действия (и желательно только на них, исключая внешние воздействия), но при этом модель была достаточно точна, чтобы мы по ней могли делать достоверные заключения о реальном мире и законах его изменения. Последний момент важен — необходимо не только описать мир, но и понимать причинность событий, возможность предсказывать реакцию на наши действия с бóльшей точностью.
Поэтому разделение метрик на "денежные" и "продуктовые" — непродуктивно. Вам вот надо идти от "денежных" к "продуктовым". В это же время похожая компания думает о важности перехода от "продуктовых" метрик к "денежным", ближе к бизнесу и клиентам. (а потом мы все слушаем доклады на конференциях об этих замечательных трансформациях)
Вместо этого нужно обсуждать — какие метрики должны быть, чтобы минимизировать ошибки двух типов при движении к нужной нам цели. Чтобы метрики были достаточно чувствительны, чтобы реагировать именно на наши действия ("горячо/холодно") и в то же время их изменения описывали мир, а вы могли лучше понять по ним реальный мир и его движущие силы.
2) Я не эксперт по развороту больших компаний, но мнение и опыт взаимодействия с ними имею. Главная мысль такая — поймите настоящие цели и приоритеты большой компании и её ключевых людей. Адаптируйте ваше предлагаемое изменение, чтобы оно помогало эти настоящие цели достичь. Или более простыми словами — плывите по главному сильному течению, а не против.
Проблема тут в том, что настоящие цели и декларируемые цели могут(и будут) отличаться. На словах одно, но на деле важным считается другое. И главный секрет в том, чтобы понять, что же на самом деле компании нужно (а она себе в этом явно может и не признаваться) и делать вещи, которые этому помогают.
Да, можно (и иногда нужно) идти против течения. Это требует умения и накопленной репутации. Но если у вас уже есть и умение и репутация — мой совет для ваc прозвучит как что-то очень базовое(и наивное) и точно не нужен.
> Какие есть секреты по постепенному развороту большой организации от денежных метрик (условного GMV) к продуктовым? Какие трюки хорошо сработали в твоем опыте? Если вообще была такая проблема в эквиде
В ответе есть две части: про метрики и про разворот большой компании.
1) Метрики это проекция реального мира на числа. Они дают управляемость и позволяют работать с этой моделью мира. Но как и любая модель — не описывают мир во всех его деталях, могут ошибаться.
Как и у гипотез — ошибки модели сводятся к двум общим типам:
— Ложноотрицательные: в реальном мире что-то произошло, но метрики этого не показали.
— Ложноположительные: метрики что-то показали и объяснили, мы пришли к какому-то заключению, но в реальном мире этого нет или же причина изменений метрик — другая.
Правильная модель стремится к минимизации этих ошибок. Чтобы метрика была достаточно чувствительна, чтобы реагировать на наши действия (и желательно только на них, исключая внешние воздействия), но при этом модель была достаточно точна, чтобы мы по ней могли делать достоверные заключения о реальном мире и законах его изменения. Последний момент важен — необходимо не только описать мир, но и понимать причинность событий, возможность предсказывать реакцию на наши действия с бóльшей точностью.
Поэтому разделение метрик на "денежные" и "продуктовые" — непродуктивно. Вам вот надо идти от "денежных" к "продуктовым". В это же время похожая компания думает о важности перехода от "продуктовых" метрик к "денежным", ближе к бизнесу и клиентам. (а потом мы все слушаем доклады на конференциях об этих замечательных трансформациях)
Вместо этого нужно обсуждать — какие метрики должны быть, чтобы минимизировать ошибки двух типов при движении к нужной нам цели. Чтобы метрики были достаточно чувствительны, чтобы реагировать именно на наши действия ("горячо/холодно") и в то же время их изменения описывали мир, а вы могли лучше понять по ним реальный мир и его движущие силы.
2) Я не эксперт по развороту больших компаний, но мнение и опыт взаимодействия с ними имею. Главная мысль такая — поймите настоящие цели и приоритеты большой компании и её ключевых людей. Адаптируйте ваше предлагаемое изменение, чтобы оно помогало эти настоящие цели достичь. Или более простыми словами — плывите по главному сильному течению, а не против.
Проблема тут в том, что настоящие цели и декларируемые цели могут(и будут) отличаться. На словах одно, но на деле важным считается другое. И главный секрет в том, чтобы понять, что же на самом деле компании нужно (а она себе в этом явно может и не признаваться) и делать вещи, которые этому помогают.
Да, можно (и иногда нужно) идти против течения. Это требует умения и накопленной репутации. Но если у вас уже есть и умение и репутация — мой совет для ваc прозвучит как что-то очень базовое(и наивное) и точно не нужен.
У меня есть очиститель/увлажнитель воздуха, которым можно управлять с телефона. В отличие от товаров, где удаленный доступ добавляют по причине "а прикольно!" (зачем чайнику wi-fi?) — это полезно. Можно например, не вставая с постели, включить тихий режим сна. Другая удобная штука — пуш-нотификации о том, что пора долить воды.
И вот приходит мне пуш-нотификация об этом. Я сразу иду и вытаскиваю из очистителя бак, чтобы туда налить воды. Сразу же мне прилетает другое уведомление — "я разобран и не готов к использованию".
Это хороший пример того, как делаются штуки, которые не учитывают контекст ситуации. Сообщение о проблеме "разобранный прибор" — полезное. Сообщение о проблеме разобранного прибора сразу после того как мне настоятельно предложили его разобрать — не имеет смысла.
Пользователь не взаимодействует с продуктом только в конкретном моменте. Он далает это в контексте (предыдущие действия, будущие действия, цели, состояния, эмоции, etc). Не учитывя эти вещи, делая шутки механически "для конкретного момента в вакууме", будет получаться посредственный неудобный продукт.
Как например сайт авиакомпании, которая требует для логина верификации через СМС и постоянно разлогинивает, не давая сохранить в оффлайн данные о своих рейсах. И когда у тебя возникает форс-мажор в другой стране с международным роумингом и ужасным аэропортным вайваем — ты вспоминаешь тех продакт-менеджеров добрыми словами.
Как например приложение Visa Airport Companion, которое для регистрации требует пройти десяток шагов с валидацией почты, телефона, карты и предоставлением кучи данных о себе. Подавляющее число пользователей этого приложения скачивают его и проходят регистрацию на очереди в лаунж аэропорта, в чужой стране, возможно сильно уставшие. А чтобы попасть в лаунж по их банковской карте — надо пройти квест с регистрацией на 15 минут (и да, если переключится из приложения куда-то еще, то оно может выгрузится и весь прогресс регистрации будет потерян).
Это реклама и сторисы на весь экран, когда ты открываешь приложение, чтобы вызвать такси прямо сейчас(зато какой рост метрик!). "Имя им — легион."
Пользователь всегда существует в контексте. И поведение отличного продукта обязано этот контекст учитывать.
И вот приходит мне пуш-нотификация об этом. Я сразу иду и вытаскиваю из очистителя бак, чтобы туда налить воды. Сразу же мне прилетает другое уведомление — "я разобран и не готов к использованию".
Это хороший пример того, как делаются штуки, которые не учитывают контекст ситуации. Сообщение о проблеме "разобранный прибор" — полезное. Сообщение о проблеме разобранного прибора сразу после того как мне настоятельно предложили его разобрать — не имеет смысла.
Пользователь не взаимодействует с продуктом только в конкретном моменте. Он далает это в контексте (предыдущие действия, будущие действия, цели, состояния, эмоции, etc). Не учитывя эти вещи, делая шутки механически "для конкретного момента в вакууме", будет получаться посредственный неудобный продукт.
Как например сайт авиакомпании, которая требует для логина верификации через СМС и постоянно разлогинивает, не давая сохранить в оффлайн данные о своих рейсах. И когда у тебя возникает форс-мажор в другой стране с международным роумингом и ужасным аэропортным вайваем — ты вспоминаешь тех продакт-менеджеров добрыми словами.
Как например приложение Visa Airport Companion, которое для регистрации требует пройти десяток шагов с валидацией почты, телефона, карты и предоставлением кучи данных о себе. Подавляющее число пользователей этого приложения скачивают его и проходят регистрацию на очереди в лаунж аэропорта, в чужой стране, возможно сильно уставшие. А чтобы попасть в лаунж по их банковской карте — надо пройти квест с регистрацией на 15 минут (и да, если переключится из приложения куда-то еще, то оно может выгрузится и весь прогресс регистрации будет потерян).
Это реклама и сторисы на весь экран, когда ты открываешь приложение, чтобы вызвать такси прямо сейчас(зато какой рост метрик!). "Имя им — легион."
Пользователь всегда существует в контексте. И поведение отличного продукта обязано этот контекст учитывать.
Люди недооценивают насколько неудобства мира вокруг вызваны действиями очень небольшого количества злонамеренных людей.
Заборчики, замки, проверки, вахтёры, капчи и рейт-лимиты — всё это результат действий конкретных людей, которые пытались обойти правила.
В любой системе существуют "щели" и лазейки в правилах и условностях. Если человек принимает решение эти лазейки эксплуатировать, то он может нанести ассиметрично большой урон системе. Она просто не готова к этому.
Буквально один человек, который решил точечно слать спам через ваш сервис, приводёт к тому, что у всех обычных пользователей сервиса появятся скрытые ограничения. С которыми люди, которые просто делают что-то необычное, будут сталкиваться (и страдать).
Сфокусированность злодеев на обход защит("спор меча и щита") такая, что надо или "закручивать гайки" очень сильно или же иметь отдельную выделенную команду на противодействие этому.
Так или иначе у нас возникает сильная ассиметрия — небольшое количество нарушителей, приводит к большому кумулятивному ущербу. Система с высоким уровнем внутреннего доверия переходит к низкому, что ударяет по её эффективности.
Например в исследовании "The sociobiology of sociopathy: An integrated evolutionary model" говорится:
> Sociopaths, who comprise only 3-4% of the male population and less than 1% of the female population...are thought to account for over 50% of all crimes in the U.S.
Чтобы это обойти система должна иметь процесс и привычки систематического "наказывания" нарушителей(включая исходный недопуск их в систему). Включая "наказывание" тех, кто видит нарушение, но не "наказывает" нарушителей сам. Если этого нет — то кажется, что со временем всегда будет деградация до системы с низким уровнем доверия и большим количеством запретов и (само)ограничений.
Заборчики, замки, проверки, вахтёры, капчи и рейт-лимиты — всё это результат действий конкретных людей, которые пытались обойти правила.
В любой системе существуют "щели" и лазейки в правилах и условностях. Если человек принимает решение эти лазейки эксплуатировать, то он может нанести ассиметрично большой урон системе. Она просто не готова к этому.
Буквально один человек, который решил точечно слать спам через ваш сервис, приводёт к тому, что у всех обычных пользователей сервиса появятся скрытые ограничения. С которыми люди, которые просто делают что-то необычное, будут сталкиваться (и страдать).
Сфокусированность злодеев на обход защит("спор меча и щита") такая, что надо или "закручивать гайки" очень сильно или же иметь отдельную выделенную команду на противодействие этому.
Так или иначе у нас возникает сильная ассиметрия — небольшое количество нарушителей, приводит к большому кумулятивному ущербу. Система с высоким уровнем внутреннего доверия переходит к низкому, что ударяет по её эффективности.
Например в исследовании "The sociobiology of sociopathy: An integrated evolutionary model" говорится:
> Sociopaths, who comprise only 3-4% of the male population and less than 1% of the female population...are thought to account for over 50% of all crimes in the U.S.
Чтобы это обойти система должна иметь процесс и привычки систематического "наказывания" нарушителей(включая исходный недопуск их в систему). Включая "наказывание" тех, кто видит нарушение, но не "наказывает" нарушителей сам. Если этого нет — то кажется, что со временем всегда будет деградация до системы с низким уровнем доверия и большим количеством запретов и (само)ограничений.