Amazon’s Working Backwards 📱

Working Backwards – методика, разработанная и популяризированная Amazon, которая стала, в том числе, альтернативой классическому подходу с PRD.

💡Главная идея проста: разработка продукта начинается с написания пресс-релиза, как если бы продукт уже был запущен. Это помогает сразу сфокусироваться на ценности для клиента, а не на деталях реализации.

Плюсы подхода «разработки в обратную сторону»:
1. Фокус на клиенте. Ещё на старте вы описываете, какую задачу продукт решает и почему он лучше конкурентов.
2. Простота. Будущий образ результата описывается понятными и простыми для пользователя словами.
3. Правильные вопросы. Вместе с пресс-релизом вы готовите FAQ, заранее продумывая ключевые вопросы и ответы на них.
4. Комплексность. Вся важная информация собрана в явном виде в одной паре документов PR/FAQ.

В рамках подхода Working Backwards вы готовите два документа
– Пресс-релиз
– FAQ
Ниже подробнее разберём каждый

📰 Структура пресс-релиза

1️⃣ Название
Краткое и понятное целевой аудитории, чтобы сразу было ясно, о чём продукт.

2️⃣ Целевая аудитория
Кто будет использовать продукт и какие выгоды получит.
См. Метод Персон

3️⃣ Проблема
Какую реальную проблему продукт решает, какую потребность закрывает. Важно, чтобы эта проблема была изложена глазами клиента.

4️⃣ Решение
Как именно продукт решает указанную проблему?
Почему он делает это лучше конкурентов, например, быстрее, дешевле, проще?

5️⃣ Опыт использования
Как клиент сможет использовать продукт? Каким будет пользовательский опыт и какие эмоции и ощущения он будет вызывать?

6️⃣ Ценность
В чем заключается основная ценность продукта для клиента?
Почему этот продукт будет лучше конкурентов (прямых, косвенных и заменителей)?

7️⃣ С чего начать
Пошагово, что должен сделать клиент, чтобы получить продукт и решить свою задачу с помощью него

8️⃣ Цитата
От лица руководителя или разработчика, которая подчеркнёт значимость и уникальность продукта.
От лица потенциального пользователя, в которой он описывает впечатления от использования продукта с акцентом на преимущества.

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

Вы, как менеджер продукта, можете получить фидбек на свой продукт, описанный в таком формате, двумя способами:
– На встрече со стейкхолдерами (про это будет отдельный пост)
– Альтернативный подход: показать пресс-релиз потенциальным пользователям

📖 В отличие от пресс-релиза, FAQ имеет более свободную форму.

Главная цель FAQ – это собрать и проработать все важные вопросы, чтобы обсудить их с командой на следующих этапах создания продукта. Ограничений на количество вопросов и объём нет.

Выделяют два вида FAQ:

Публичный FAQ. Ориентирован на клиентов. Отвечает на вопросы, которые могут возникнуть у пользователей при знакомстве с продуктом. Используется как часть официальных материалов при релизе.

Внутренний FAQ. Создаётся для команды и стейкхолдеров. По сути, в нём собирается список вопросов, требующих проработки, например:
– разработчики используют его для оценки объёма работ;
– дизайнеры как отправную точку для wireframe и концептов;
– стейкхолдеры и спонсоры для оценки требуемых ресурсов.

В следующем посте разобрал, как Amazon перепридумали совещания и отказались от PowerPoint

Каждому, кто работает с продуктом, важно всегда быть в контексте рынка, а также уметь находить разные способы решения одних и тех же задач. Для этого нужно постоянно прокачивать свою насмотренность и учиться решать кейсы – чем больше задачек ты прорешал, тем меньше тебя можно «удивить» и застать врасплох. Что на собеседовании, что на работе.

Команда Карьерного Цеха собрала целую библиотеку с решениями продуктовых кейсов, а также с теорией для погружения в работу с продуктом.

Что внутри библиотеки:
🔘 Каталог видео с решением продуктовых задач от умных экспертов;
🔘 Только настоящие задачи и никаких абстрактных примеров;
🔘 Кейсы по разным стадиям продукта: от идеи до масштабирования
🔘 Прокачка насмотренности в любое время и в любом месте: можно смотреть видео вместо YouTube по вечерам или слушать вместо подкаста по дороге на работу.

Кому подойдет:
🔘 Продактам, которые хотят расширить свой арсенал подходов к решению задач;
🔘 Аналитикам, проджектам и другим специалистам, которые хотят в будущем стать продактами;
🔘 Всем, кто хочет расширить свой кругозор и грамотно прокачивать насмотренность.

Мне нравятся проекты Карьерного Цеха, я состою в их Клубе и с удовольствием провёл для участников митап о когнитивных ошибках в работе менеджера

Для библиотеки я записал свой кейс образовательной онлайн-платформы и подробно на нём разобрал универсальный CIRCLES Framework. Освоив этот фреймворк, вы сможете увереннее проходить отбор на позицию продакта.

Важно, что для подписчиков моего канала – доступ к библиотеке можно получить за 1₽ на первые 7 дней.
За это время вы сможете подробно ознакомиться с материалами и решить, хотите ли оформить подписку.

Далее подписка стоит 1 500₽ в месяц по промокоду OrdinaryPM, вместо обычных 2 000₽.

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

👀 Получить доступ на 7 дней за 1₽

Как в Amazon отказались от PowerPoint

В Amazon смогли воплотить мечту многих продактов – отказ от PowerPoint на встречах 🙃 Вместо бесконечных слайдов участники начинают с того, что молча читают заранее подготовленный документ Six Pager.

Как проходит «документоцентричное совещание»:
1. Подготовка. Документ рассылается участниках встречи заранее.
2. Тихое чтение ≈ 20-30 мин. За это время можно внимательно проанализировать 6 страниц, поэтому объём документа ограничен именно этим. Остаток встречи (30-40 мин) отдают обсуждению.
3. Обсуждение. Либо высказывается каждый, либо автор проходит по разделам и собирает обратную связь. Отдельно отмечу практику disagree & commit – можно не соглашаться с идеей, но поддержать её реализацию, если команда решила двигаться вперёд.
4. Фиксация итогов в документе, с общим доступом для всех участников.

Почему именно текст, а не слайды?
– Глубина. Слайды часто поверхностны, а текст подталкивает анализировать и вникать в суть.
– Логика. Письменная форма подталкивает к простым и понятным формулировкам и прозрачным причинно-следственным связям, подбору аргументов, подкрепляющих тезис.
– Single version of the Truth. Все получают одинаковый, полный документ, без когнитивных искажений за счёт оформления или питчинга.

Такой подход в Amazon ещё называют «замедление ради ускорения» 🐢🐆

Структура Six-Pager

Документ – это, прежде всего, связанная история. Конечно, в нём могут присутствовать списки с тезисами (tenets), но все они поясняются развернутыми предложениями. Иначе вместо рассказа мы получим PowerPoint, просто переупакованную в Word.

Документ может принимать разные формы, но предлагаю обратить внимание на эту структуру:

1️⃣ Введение (½ - 1 стр)
Простое объяснение про что Six Pager, причём даже для тех, кто не знаком с предметной областью.

2️⃣ Цели (½ стр)
Описывается, как будет выглядеть успех с точки зрения метрик: метрика сейчас → метрика в будущем → срок.
Важно: это отправная точка для всего документа. Если кто-то не согласен с этим утверждением, проще обсудить его напрямую, чем далее разбирать все аргументы, которые его поддерживают.

3️⃣ Принципы (½ стр)
Стратегические идеи, которые лежат в основе вышеизложенного решения.

4️⃣ Состояние бизнеса (1 стр)
Подробная и честная картина текущего положения дел, с точки зрения реализации стратегических целей.

5️⃣ Полученные знания (½-1 стр)
Описываем сложности и неудачи, с которыми сталкивались в прошлом и что хорошо сработало. Подкрепляем данными. Честно и откровенно.

6️⃣ Стратегические приоритеты (2-3 стр)
Это ключевая часть Six Pager, по сути это детальный план действий, как вы планируете достичь выше обозначенных целей. Важно, чтобы план действий и исходный тезис были связны.

7️⃣ Приложения
Таблицы, графики и всё то, что поддерживает выдвинутый вами тезис и аргументы в его поддержку

Six Pager – это не просто альтернатива слайдам, а инструмент, который меняет культуру обсуждения проектов и продуктов, провоцируя глубокое, осмысленное обсуждение ценой более тщательной проработки на старте

Что делает продакта настоящим лидером 🤔

В IT организационная структура устроена так, что у менеджера продукта нет прямых подчинённых: ни разработчики, ни аналитики, ни дизайнеры формально ему не подчиняются.

Но именно от менеджера продукта руководство ждёт реального влияния на бизнес-показатели через работу над продуктом. Возникает классическая ситуация – ответственность есть, ресурсов как бы нет.

На моей практике оптимальный подход здесь – это занять лидерскую позицию.

Лидерство в роли продакта

Хороший менеджер продукта не только отвечает за ценность продукта для пользователя, но и за то, чтобы команда понимала зачем она делает именно такой продукт. В этом ключе, продукт перестаёт быть просто набором фичей, но становится смыслом работы продуктовой команды.

Как это проявляется на практике:
1️⃣На старте проекта – сформулировать смысл и цель прежде всего для себя, а затем донести это до команды: вдохновить, объяснить, зачем мы идём в эту сторону (здесь нужны навыки и инструменты сторителлинга).
2️⃣В процессе работы – убирать барьеры, решать проблемы, слушать и поддерживать. Создавать процессы и среду, в которых команда может показывать максимум результата (здесь отлично работают модели Servant Leadership, Co-active Leadership Model, о них думаю написать отдельно).
3️⃣В кризисных или нестандартных ситуациях – лидер будет последним, кто отступит, лидер будет продолжать упорно искать способы решения. Самомотивация, устойчивость, выносливость в работе менеджера, может быть примером, который позволит команде не опускать руки.

Лидер ≠ должность
Лидер – это не роль в оргструктуре, а человек, которого команда готова слушать. Именно хороший менеджер делает из коллектива разработчиков, дизайнеров, аналитиков слаженную продуктовую команду.

Альтернатива?
Конечно, можно ограничиться операционным, менеджерским уровнем: просто описывать PRD и распределять задачи по спринтам, планировать и приоритизировать бэклог фичей. Команда при этом будет просто писать код и выкатывать его в прод.

Но в долгосрочной перспективе это почти всегда ведёт к стагнации:
1️⃣ падает мотивация, а сильные игроки уходят, потому что их драйвит не выполнение «плана по фичам»;
2️⃣ продукт превращается в набор фичей, а не в решение проблем пользователей;
3️⃣ динамичная конкурентная среда и новые технологии быстро «съедают» такой продукт, команда не способна преодолеть такие вызовы
4️⃣ результат – потеря конкурентоспособности продукта и низкая вовлечённость и мотивация команды

Такая отрицательно раскручивающаяся спираль «фабрики фичей».

Как вы могли уже заметить, один из ключевых компонентов лидерской позиции – это умение мотивировать и вдохновлять команду. В этой теме много нюансов и практических приёмов, о которых хорошо рассказала моя коллега в ❤️ – Женя Кадомец в своём канале Карьера, тренды и котики. Если вы хотите в этом по-настоящему разобраться читайте пост и подписывайтесь на канал Жени – у нее много полезного про то, как руководить командами, строить карьеру и не только – будет интересно 🙌

Какие практики ведения проектов выделяют хорошего менеджера? 📖

К своему стыду, я редко нахожу время на чтение книг, в т.ч. и на профессиональную литературу. Но книгу Егора Ганина «Как приготовить проект» я всё-таки прочитал. И вот почему.

Егор – известный эксперт в узких кругах российского IT. В Яндексе он отвечал за Почту, а в VK – за Облака. Мне было особенно интересно изучить его менеджерский опыт, ведь сам я в этой сфере уже более 13 лет.

Интересно, что книга совсем небольшая, но плотность информации в ней – высокая. Условно для себя я разделил её на две части:
– Роль менеджера в IT;
– Авторская методология ведения проектов.

В первой части книги Егор рассказывает, что отличает хорошего менеджера, от backlog holder и передатчика информации. Менеджмент – это не просто набор правил Kanban, Agile, Waterfall, а система принятия решений. Причём менеджер в этой системе должен накапливать знания и аккумулировать экспертизу, чтобы 2-5-10 проекты качественно отличались.

Как это реализовать на практике? Егор выделяет ключевые навыки, которые менеджеру важно развивать: умение вникать в задачи, планировать, организовывать процессы, грамотно информировать, работать с цифрами и контролировать результат.

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

1️⃣ Умение вникать. «Услышать и передать не тоже самое, что услышать вникнуть и передать».

В первом случае менеджер не создаёт никакой ценности: максимум он выполняет роль ретранслятора, а в худшем превращается в «сломанный телефон».

Во втором случае процесс принципиально меняется. Чтобы качественно поставить задачу, менеджеру важно самому разобраться в деталях: понять логику работы системы, этапность выполнения, т.е. продуктово проработать задачу и оформить её в понятную инструкцию. Именно так он приносит дополнительную ценность для команды.

2️⃣ Умение планировать. «Цель без плана – мечта. Постановка цели – это половина успеха». Если менеджер поставил и запланировал задачу, именно он отвечает за её выполнение. Важно, что чем дольше и дальше мы движемся по проекту, тем сложнее нам сохранять объективность из-за туннельного мышления и других спецэффектов мозга.

3️⃣ Умение организовывать. Обеспечивать прозрачность и предсказуемость процессов – это одна из главных задач, на решение которой нанимают менеджера. Не менее важна системность: день за днём, неделю за неделей повторять одни и те же действия, не теряя оптимизма. Настоящий менеджер остаётся последним, кто не отказывается от проекта, продолжая искать способы его реализации. Его сила в умении сохранять энергию, не поддаваться унынию и обеспечивать движение команды вперёд.

4️⃣ Умение контролировать. Осознанный менеджер отвечает за всё: за себя, за команду, за проект, сроки, встречи, обещания, запуски и сбои. При этом умение признать вину и ответственность за некачественный результат снижает шансы повторения ошибки и повышает стоимость менеджера на рынке труда. Хороший менеджер не ограничивается тем, чтобы просто констатировать срыв сроков. Он разбирается в причинах, выявляет узкие места и предлагает решения.

Контроль – это ещё и умение находиться в «суперпозиции»: одновременно быть внимательным к деталям и при этом видеть общую картину проекта. А проактивность и инициативность позволяют выявлять и устранять проблемы ещё до того, как их заметят остальные.

Вторая часть книги посвящена авторской методологии ведения проектов – выталкивающим таблицам. Спойлерить её не буду, скажу лишь, что методика стоит того, чтобы проинвестировать время в её изучение. Книга небольшая, вам хватить пары вечеров, чтобы разобраться в том, как по-настоящему эффективно делать проекты в IT.

Growth hacking без «взлома роста»: зачем командам такой подход? 🧐

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

Growth Hacking – один из таких примеров. В последнее время подмечаю ситуации, когда команды используют для «взлома роста», а как удобный фильтр для проверки гипотез, перед тем, как идти в полноценный проект.

Почему такой подход тоже имеет право на жизнь?

Во-первых, в таких компаниях редко когда основательно считают экономику проектов и в ситуации, когда проект не взлетает, с продакта требуют цифры (которых нет). В этом случае growth hacking помогает: быстрый тест идеи лучше, чем крупные инвестиции в проект, который может не взлететь.

Во-вторых, слабая культура аргументированного обсуждения инициатив и отказа от заведомо неудачных. Уверен, вам знакомы ситуации, когда от C-level прилетает «гениальная» идея, и команда обязана её реализовать. Вместо месяцев работы над полноценным проектом growth hacking позволяет быстро проверить основу идеи. Если на тестах метрики слабые – в проект больше не инвестируют.

Какие метрики важны при таком использовании growth hacking?

1️⃣ Стоимость теста. Если для проверки нужна разработка модуля, редизайн или целый спринт — значит, тест спланирован плохо. Упрощайте: почти всегда можно проверить быстрее и дешевле.

2️⃣ Скорость и количество. Один тест в месяц? Это не процесс, а карго-культ. Хороший бенчмарк, к которому нужно стремиться – около 15 тестов в месяц.

7 популярных креативных техник в продакт-менеджменте

А вот и обещанный обзор креативных техник, которые я применял в своей практике:

1️⃣ Double Diamond – методика, разработанная British Design Council в 2005 году и основанная на чередовании дивергентного и конвергентного мышления.
– На первом этапе мы исследуем и выявляем проблему (Discover → Define). Генерируем как можно больше идей без критики (designing the right thing).
– На втором этапе мы фокусируемся на создании и тестировании решений исходной проблемы (Develop → Deliver). Включаем аналитику и отбираем жизнеспособные идеи (designing things right).
Цель Double Diamond – структурировать креативный процесс и снизить риски при разработке продукта.

Существует и расширенная модель Triple Diamond, которая добавляет ещё один «бриллиант» с фокусом на масштабировании продукта.

2️⃣ ТРИЗ (Теория Решения Изобретательских Задач) – методика, разработанная советским инженером Генрихом Альтшуллером в 1940-1960-х годах. Основная идея ТРИЗ: каждая задача может сводиться к противоречию, которое можно решить, применяя проверенные принципы из анализа тысяч изобретений. Кратко ТРИЗ не описать, тянет на отдельный пост.

3️⃣ SCAMPER. Название – это акроним, в котором зашито 7 креативных приёмов: Substitute, Combine, Adapt, Modify, Put to Another Use, Eliminate, Reverse. Цель методики – помочь в генерации идей и систематизировать их.

4️⃣ CRAFT (Creative Algorithms, Frames & Tools) – методика, разработанная основателем студии IKRA Василием Лебедевым в 2010-х годах. В основе «фреймы» и поиск способов изменения взаимодействия. Например, есть проблема, что люди не хотят кликать по баннерам, это «фрейм», а что, если сделать баннер-лотерейный билет, кликнув по которому, можно выиграть приз? Как и ТРИЗ кратко описать будет сложно, тянет на отдельный пост.

5️⃣ Латеральное мышление – методика, разработанная Эдвардом де Боно в 1967 году, в основе которой лежит «боковой подход», цель которого увидеть проблему под новым углом. Наверняка вы слышали про «Шесть шляп мышления», есть ещё подход с провокацией (высказывание парадоксальной идеи), инверсией (меняем местами привычные вещи), аналогией (поиск параллелей в других сферах) и случайным символом (попытка связать случайное слово/образ и с задачей).

6️⃣ Theory of Constraints – методика, разработанная Элияху Голдраттом в 1980-х годах. Методика строится на системном подходе к решению проблем. Основная идея: выявить корневую проблему с помощью древовидной структуры, затем разработать прорывное решение, снова опираясь на эту модель. После этого решаются возникающие противоречия и конфликты, и формируется пошаговый план внедрения, направленный на максимальное улучшение системы. Если хотите разораться глубже, то прочитайте книги Голдратта «Цель» и «Цель 2.0».

7️⃣ Про классический брейншторм упоминать не буду, с ним большинство уже знакомо. А вот обратный брейншторм заслуживает вашего внимания:
– Первый этап: генерируем максимально глупые, нелепые или неподходящие идеи, которые усугубляют проблему, вместо того чтобы её решать.
– Второй этап: анализируем эти идеи и пытаемся превратить их в реальные, практичные решения исходной задачи. Этот приём помогает выйти за рамки привычного мышления и находить нестандартные подходы там, где классический брейншторм часто застревает.

Креативных техник довольно много. Вот несколько хороших подборок, где можно посмотреть и выбрать подходящие для себя:
– Design Kit от IDEO
– Подборка Project of How
– Hyper Island Toolbox
– Innowiz Online tools
– Vetas

По-настоящему сильные продукты: взгляд жюри Startech.Awards 💪

В этом году я попробовал себя в новой роли – участвовал в жюри Startech.Awards. Это как российский «Оскар» для стартапов.

За пару недель мне пришлось оценить более 50 стартапов (из 1680 заявок!) по таким критериям:
– Технологическая или инновационная составляющая
– Опыт работы на рынке / коммерческий трекшн
– Конкурентные преимущества
– Размер целевого рынка
– Укомплектованность и квалификация команды

💡 Интересный вывод: самым слабым местом большинства проектов было конкурентное преимущество. Давайте разберём, что это такое на примере методологии Гамильтона Хелмера.

Устойчивое конкурентное преимущество – это способность компании создавать ценность для клиентов и удерживать её дольше конкурентов благодаря защитным механизмам. Хелмер выделяет 7 сил:

1. Экономия масштаба – чем больше компания производит, тем дешевле обходится каждая единица.
2. Сетевые эффекты – ценность продукта растёт с ростом числа пользователей.
3. Контрпозиционирование – уникальное позиционирование продукта, которое конкуренты не могут скопировать без ущерба для себя.
4. Высокие затраты на переключение – клиентам неудобно или дорого менять продукт на другой.
5. Сила бренда – доверие к бренду, которое обеспечивает долгосрочное сотрудничество с клиентами.
6. Контроль уникальных ресурсов – патенты, технологии, команды экспертов.
7. Операционная эффективность и процессы – уникальные процессы или алгоритмы, которые сложно повторить.

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

Попробуйте взглянуть на свой продукт под этим углом: есть ли у него устойчивое конкурентное преимущество?
Ну а если хотите увидеть финал Startech.Awards, где поборются самые крутые стартапы с сильным конкурентным преимуществом, способные в будущем сделать disrupt рынка, приходите 19 сентября в ВЭБ Центр (Новинский бульвар, 31, Атриум).

Узнать подробности 🎫

Что такое дерево метрик? 🌳

Дерево метрик – это иерархичная визуализация как разные метрики в продукте влияют друг на друга: от верхнеуровневой к низкоуровневым.

Его ещё называют пирамидой метрик или иерархией метрик.

Главная ценность дерева в том, что из неструктурированного набора метрик, вам становятся видны рычаги влияния на верхнеуровневую метрику – North Star Metric.

North Star Metric (NSM) – главная метрика, измеряющая успешность продукта. NSM является производной от других метрик, которые отражают эффективность работы продукта в разных его частях. В контексте дерева метрик NSM его вершина. Цель продакта – работать над улучшением North Star Metric. Подробнее о NSM писал мой коллега Павел Беляев, тимлид дата-аналитиков в Яндекс eLama рекомендую не только почитать его пост, но подписаться на канал.

Дерево метрик помогает:

1. Фокусироваться на главном: выделить наиболее важные метрики, которые напрямую влияют на NSM. Благодаря этому команды могут направить усилия на наиболее значимые задачи и избегают распыления на второстепенные задачи.

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

Например, тимлид говорит: «Нужно заняться техдолгом». Продакт смотрит на дерево метрик и видит: 2% оплат не проходят из-за багов → если убрать техдолг в этой части, ошибок станет меньше → меньше ошибок = рост выручки выручки.

3. Улучшение качества принятия решений. Чёткая структура дерева метрик помогает принимать более обоснованные и эффективные решения. Команды сразу видят, какие метрики требуют внимания, и понимают, какие шаги нужно предпринять для их улучшения.

Например, вместо абстрактного «надо срочно добавить такую фичу», можно обосновать это через дерево метрик: эта фича улучшает Retention → растёт LTV → рост LTV мощный рычаг для роста Revenue, нашей NSM

4. Согласованность целей разных команд. Дерево метрик помогает выстроить единое понимание между командами: кто за что отвечает и как вклад каждой команды влияет на NSM. Это снижает риск конфликтов и дублирования работы. Кроме того, дерево служит опорой для управленческих решений, например, при распределении зон ответственности между командами

Продвинутый уровень использования Дерева метрик – в связке с OKR и с Unit-экономикой продукта.

Как построить дерево метрик?

1️⃣ Определите North Star Metric
В большинстве продуктов это выручка (Revenue) или прибыль (Profit).

2️⃣ Разложите NSM на метрики 1 уровня
Они должны быть конкретными и измеримыми. Не забываем про принцип MECE:
– метрики не должны пересекаться (Mutually Exclusive);
– но вместе должны полностью описывать влияние на верхнюю метрику (Collectively Exhaustive).

Например, выручка может раскладываться на количество клиентов и LTV (Lifetime Value)

3️⃣ Разложите метрики 1 уровня на метрики 2 уровня
Например, LTV можно разложить на:
– время жизни клиента (Lifetime)
– выручку от платящего пользователя (ARPU)
Количество клиентов – на количество новых и возвращающихся клиентов.

4️⃣ Повторяйте для метрик 2 уровня и ниже
Как понять сколько уровней дерева нужно?
На моей практике 4-5 уровней было достаточно. Главное идти до того уровня, где на отдельные метрики уже реально можно влиять через проведение тестов, экспериментов, изменения в продукте.

Есть и альтернативный способ построения дерева метрик: «снизу вверх», т.е. от базовых метрик к NSM. Но на моей практике он встречается реже.

5️⃣ Проанализируйте дерево
И найдите проседающие метрики, у которых сильное влияния на NSM

6️⃣ Сгенерируйте гипотезы
Определите, какие действия помогут подтянуть эти метрики и в итоге повлияют на NSM.

Ошибки при построении дерева метрик 🔴

В продолжение темы давайте разберём ошибки, с которыми я так или иначе сталкивался в своей практике:

1️⃣ Неправильный выбор метрик для оценки того, что на что влияет.
Как себя перепроверить: используйте фреймворки, например, AARRR или HEART, чтобы разложить продукт на составляющие и проверить логику.

2️⃣ Построение дерева в одиночку. Да, продакт хорошо разбирается в продукте, но реальность всегда сложнее, продукт не существует в вакууме.

Состав метрик и их влияние нужно обсуждать вместе с командой:
– договориться, какие метрики действительно важны;
– объяснить и согласовать подход к расчёту метрик и их влияния;
– сделать саму иерархию прозрачной.

Более того, когда дерево создаётся совместно, у коллег появляется чувство сопричастности и понимание того, как именно их работа влияет на общий результат. Это улучшает и коммуникацию, и согласованность действий.

3️⃣ Слишком большое дерево. Как писал выше, на моей практике 4-5 уровней было достаточно. Главное идти до того уровня, где на отдельные метрики уже реально можно влиять через проведение тестов, экспериментов, изменения в продукте.

4️⃣ Дерево метрик не обновляется. В IT всё очень динамично: измениться может что угодно — от стратегии компании до модели монетизации продукта или каналов привлечения пользователей. Конечно, такие изменения должны отражаться и в дереве метрик.

На этом у меня всё. Спасибо за внимание 🙌

Когнитивные искажения в IT и как их обходить 🧠

Многие уже знакомы с наиболее известными когнитивными искажениями – эвристикой доступности, эффектом якоря и предвзятостью подтверждения. Если же вы о них ещё не слышали, советую заглянуть в мой пост для канала Yandex for Products. Сегодня хочу продолжить разговор о когнитивных искажениях и поделиться пятью не менее важными, но куда реже обсуждаемыми искажениями, с которыми часто сталкиваются в IT.

Ошибка атрибуции 🏆
Мы склонны объяснять свои успехи личными достоинствами, а свои неудачи – внешними обстоятельствами. Для чужих успехов и неудач – всё наоборот.

Мой провал → помешали обстоятельства
Провал другого человека → свойства личности

Как проявляется в ИТ:

«Проект выстрелил, потому что я профи в этом», но «провал, потому что учения блокировали выкатку релиза на прод».
«Коллега завалил проект, потому что он не тянет проекты такой сложности», при этом игнорируется перегруз команды или неясные требования.

Как снизить влияние:
Техника 5 Why, чтобы сместить фокус свойств личности на факты и причинно-следственные связи.

Эффект Хиндсайта 🔮
Люди склонны воспринимать уже произошедшие события или подтверждённые факты как очевидные для них. Также этот эффект известен как знание задним числом.

Как проявляется в ИТ:

«Я же говорил, что эксперимент не взлетит», хотя изначально прогнозов не было или они были противоречивыми.

Эффект хиндсайта базируется на трёх опорах:
1⃣ Искажение памяти – мы вспоминаем свои прежние оценки и мнения как более близкие к реальному исходу, чем они были: «Я говорил, что это произойдёт»
2⃣ Иллюзия неизбежности – после факта цепочка причин выглядит единственно возможной, а альтернативы кажутся маловероятными или несущественными: «Это должно было случиться»
3⃣ Иллюзия предсказуемости случившегося – убеждение, что исход можно было увидеть заранее, будто признаки были очевидны: «Я знал, что это произойдёт».

Как снизить влияние:
1. Ведите журнал прогнозов: формулируйте гипотезы заранее с вероятностями и сроками, потом сверяйте точность. См. HADI-циклы
2. Признайте сильное влияние случайности и вероятности

Непринятие потерь 😨
Люди склонны придавать большую важность потенциальным потерям, чем эквивалентным приобретениям.

Как проявляется в ИТ:

«Не будем трогать монолит продукта – вдруг всё сломаем», хотя текущая скорость работы уже тормозит развитие.

Как снизить влияние:
1. Считайте Сost of Delay: что мы теряем, ничего не меняя?
2. Соотносите ожидаемую ценность (expected value) с тем, что вы можете потерять.

Искажение оптимизма 😎
Люди склонны недооценивать вероятность негативных исходов для себя и своей команды по сравнению с другими.

Как проявляется в ИТ:

«У нас стабильная платформа, инцидентов не будет», хотя алерты не покрывают продукт целиком.
«Мы точно успеем к концу квартала», при этом игнорируются зависимости от внешних команд.

Как снизить влияние:
1. Осознайте свою предвзятость через сверку и фиксацию расхождений между вашими планами и фактами.
2. Проводите Ретро в команде правильно: отмечайте, что помогало, усиливайте это; выявляйте, что мешало, и ищите решения.

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

Как проявляется в ИТ:

«Эта интеграция по API займёт неделю», а выходит на 3 недели из-за доступов, тестовых стендов, миграций.

Как снизить влияние:
1. Сверяйте свои прогнозы и факт, анализирутйе расхождения
2. Закладывайте буферы, а сверка прогноза и факта позволит вам понять насколько вы промахиваетесь
3. Продумывайте и оценивайте риски
4. Просите коллег почелленджить ваш план