rutb

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

В моём случае получилась вполне настоящая self-hosted доска для ретроспектив без обязательной регистрации, с голосованием, группировкой карточек, экспортом и прочими штуками, которые мне нужны

Но ценность здесь вообще не в том, что миру теперь доступна ещё одна ретро-доска. Ценность в том, что после такого опыта отношение к нейросетям становится гораздо приземлённее. И слышать в очередной раз «я это сделал всего за пару часов без напряга, записывайтесь ко мне на курс» становится еще смешнее обычного

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

Ну и новый опыт — это в любом случае прекрасно!

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

@pm_faq

Поэтому менеджеру недостаточно просто поставить задачу — нужно передать контекст и убедиться, что у всех одинаковое понимание результата. Для продуктовой работы это вообще один из ключевых навыков: команда должна понимать не только что мы делаем, но и зачем.
Полезной мне показалась и мысль о пользователях. Батырев говорит о клиентах, но в продуктовой разработке это легко переводится как «пользователь — наше всё». В конечном счёте именно пользователь определяет, имеет ли продукт какую-либо ценность, а не основатель, руководитель или продакт со своим прекрасным видением.

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

Интересно, что некоторые идеи книги хорошо переносятся вообще за пределы менеджмента. Например, принцип «люди будут делать, когда сделать легче, чем не сделать» практически напрямую описывает хороший UX. Хочешь увеличить вероятность действия — сокращай количество препятствий. Хочешь действие остановить — увеличивай их.
На этом хорошее заканчивается.

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

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

Отсюда появляются принципы вроде «не вступайте в переговоры с террористами», «сильные уважают только силу», «не обсуждайте принятые решения с подчинёнными» и моё любимое «учить — лечить — мочить».

Мне такой взгляд на управление не близок.

Особенно спорно выглядит утверждение, что решения руководителя не нужно обсуждать с исполнителями. Команда очень часто обладает контекстом, которого нет у менеджера.
Можно принять откровенно плохое решение, а потом героически заставлять людей его реализовывать только потому, что «решения не обсуждаются». Сам Батырев позже признаёт, что любая идея руководителя может быть подвергнута сомнению, что только подчёркивает внутреннюю противоречивость книги.

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

Отдельно раздражает подача некоторых вполне очевидных вещей как сакрального знания менеджера.

• Читайте книги.

• Хвалите людей.

• Развивайтесь.

• Говорите понятно.

• Соблюдайте собственные правила.

• Если стратегия не работает — поменяйте её.

• Хороших сотрудников развивайте, с плохими расставайтесь.

Сами по себе советы нормальные. Но для человека с хотя бы небольшим опытом управления или продуктовой работы большая их часть вряд ли станет открытием.

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

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

Пожалуй, ради этой мысли читать все 45 татуировок было необязательно.

Для менеджеров продукта: https://t.me/pm_faq

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

Но всё это преамбула. Куда всё катится то на мой взгляд? К альтернативе. Да-да, ждём когда на рынке появится тот, кто скажет: вот вам конструктор для создания своего маркеплейса; вот вам услуги хранения и доставки, если нужны. Но все риски на вас. И такие решения уже есть. Конечно, же, первым в дело вступил Яндекс со своим Яндекс Kit. Они увидели возможность и активно тестируют лёгкий переворот рынок где-то с прошлого года

Переворот пока набок и без снятия штанов. Но, зная этих ребят, всё там будет. Они своё не упустят

В общем, будем посмотреть. Было бы интересно поглядеть как Озон, всего пару раз вышедший в плюс за всю историю, начнёт загибаться, так как через 30 лет вдруг оказалось, что бизнес идея хуйня. А вы думали почему ВБ скупает аэропорты, строит отели и тестирует формат такси в Беларуси? Про банк вообще молчу

• с другой логикой;

• с другой политикой;

• с другим отношением к пользователю;

• и местами вообще с другой продуктовой ставкой

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

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

А это уже опаснее, чем просто неловкая формулировка. Потому что в какой-то момент ты перестаёшь отвечать на вопрос: «что мы строим и для кого?» и начинаешь отвечать на другой: «на что мы похожи?». Фокус сильно смешается на копирование и подражание, а нужно решать проблемы своих пользователей и отталкиваться от их интересов

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

Если коротко: сказать «мы как Яндекс Что-то» удобно, но почти всегда это ленивое объяснение. И чем раньше команда научится описывать свой продукт своими словами, тем лучше она понимает, что именно делает

https://t.me/pm_faq

• Нанимай/продвигай руководителей по признакам зрелости: ответственность, дисциплина, системное мышление, способность «резать» лишнее;

• В публичной коммуникации — «мы», в разборе провалов — «я»;

• В KPI руководителей добавь метрики преемственности: рост сильной второй линии, автономность команд.

2️⃣ «Сначала кто, потом что» (First Who, Then What)

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

Снижает стоимость ошибок стратегии и ускоряет адаптацию.

Принципы:

• «Компетентен, но токсичен/пассивен» — это минус для компании;

• Подбирай команду под задачу: «кто на этом месте даст x2?»;

• Ставь людей на роли по их сильным сторонам, а не чтобы заткнуть дырку. Используй талант и заряд людей для роста, а не для оптимизаций.

3️⃣ Парадокс Стокдейла

Нужно одновременно: (а) смотреть в лицо суровой реальности без самообмана и (б) сохранять непоколебимую веру, что ты победишь в долгосрок. Не «всё будет хорошо», а «сейчас плохо X, и мы всё равно вытащим, потому что Y». Это дисциплина мышления.

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

Принципы:

• Введи регулярные «brutal facts» сессии: что не работает, что мы игнорируем, какие риски заметаем;

• Разделяй «факты» и «предположения», фиксируй решения письменно;

• Коммуникация сверх-вниз: говори честно про проблемы, составляй понятный план действий. Коммуникация в формате «проблема — решение».

4️⃣ Концепция Ежа (Hedgehog Concept)

Стратегия достижения выдающегося успеха путем фокусировки на одном главном, простом и понятном деле, которое находится на пересечении трех кругов:

1. в чём ты можешь быть лучшим в мире (не «хорошим», а номер 1);

2. что позволит заработать (ключевой драйвер прибыли/денег);

3. что тебя по-настоящему вдохновляет (страсть/смыслы).

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

Принципы:

• Определи 1–2 «ключевых метрики», завязанных на деньги (например: прибыль на пользователя, маржа на транзакцию, LTV/CAC, выручка на сотрудника);

• Проведи аудит: где у вас есть шанс стать №1 в своей узкой категории/нише/канале продвижения;

• Режь проекты, которые не попадают в пересечение (даже если они «интересные»). Никакого распыления без явного успеха по ключевой инициативе.

5️⃣ Культура дисциплины

Великие компании не полагаются на героизм и контроль, они создают систему, где дисциплина встроена: люди сами делают правильно. Это сочетание дисциплинированных людей, дисциплинированного мышления и дисциплинированных действий. Бюрократия — костыль, дисциплина — операционная мышца, которую важно качать.

Даёт предсказуемость, скорость и качество без микроменеджмента.

Принципы:

• Прозрачные ожидания и правила игры: что «норма», что «запрещено», кто принимает решения, как решать конфликты. Прозрачность системы ключ к дисциплине;

• Регулярные ритуалы управления: еженедельный отчет для команд об успехах и неудачах, квартальные планирования, разборы неудачных кейсов без поиска виноватых;

• Убирай «лишние согласования», но отдавай ответственность за результат. Дисциплина без ответственности не строится.

6️⃣ Маховик (Flywheel) вместо «революций»

Величие строится через накопление маленьких последовательных побед, которые усиливают друг друга. Снаружи это может выглядеть как «внезапный успех», но внутри — годы толкания маховика в одном направлении. Смены приоритетов, реорганизации и «чудо-стратегии» часто сбивают темп.

Помогает не срываться в хаотичные повороты и держать курс, пока система набирает инерцию.

Принципы:

• Нарисуй свой маховик: 5–7 шагов причинно-следственной цепочки «делаем X → улучшается Y → растёт Z → можем делать ещё больше X»;

• Замеряй ключевые метрики на каждом шаге, а не только финальную выручку. Деньги это важно, но это не самое важное;

• Сократи количество «больших инициатив» и увеличь качество исполнения. Делай не «много», а «достаточно», не «быстро», а «качественно».

7️⃣ Технологии как ускоритель, а не причина

Технологии сами по себе не делают компанию великой. Великие используют технологии выборочно — как усилитель выбранной стратегии, а не как замену стратегии. «Давайте внедрим X» без ясной логики и цели — просто шум.

Защищает от дорогих игрушек, которые не дают результата.

Принципы:

• Каждая технология должна отвечать: «какой шаг маховика ускоряет и какую метрику двигает». Технологии просто инструмент;

• Запускай пилоты перед масштабированием — короткие, с критериями успеха определенными заранее;

• Если технология не усиливает фокус — откладываем, даже если пропустим волну хайпа.

Подписывайтесь на телеграм-канал о профессии Product Manager — https://t.me/pm_faq

От базовых вещей до более сложных продуктовых тем. Без учебников, мотивационных лозунгов и «единственно верных» подходов — только то, что реально помогает думать и работать

Думай наборами: лучше провести A/B/C-тест, а не оказаться в ситуации «делать/не делать». Это снижает риск влюбиться в единственную идею. К полезным источникам вариантов относятся Opportunity Solution Tree (карта возможностей и решений) и обратная декомпозиция воронки (где «застревают» пользователи?). Под воронкой понимается основной сценарий продукта, над которым ты работаешь.

3) Оцени потенциал, уверенность и усилия

Быстрый фильтр до детальной оценки:

• Потенциал влияния на целевую метрику.

• Уверенность (доказательства: данные, эксперименты, экспертиза).

• Усилия (время / команда / зависимости / риск).

Задача с высоким потенциалом и уверенностью и умеренными усилиями почти всегда является кандидатом в «первую очередь».

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

4) Проверь последовательность и зависимости

Если фича Б «разблокирует» три другие инициативы — возможно, именно она первая, даже если её собственное влияние среднее. Планируй так, чтобы минимизировать критический путь.

5) Сократи неопределённость

Если уверенность низкая — поставь на первое место исследование или эксперимент, который за 1–2 недели даст решающее знание («убедимся, что гипотеза живая»). Это может сэкономить месяцы разработки.

Что делать первым: Первая задача — та, что с наилучшим ожидаемым вкладом в ключевую метрику с учётом зависимостей и стоимости задержки, и которую ты можешь начать прямо сейчас.

Почему нельзя делать всё?

Смена контекста. Переключение между контекстами убивает скорость и качество. Размазанная по задачам команда = слабый результат везде. Старайся не терять фокус и заниматься чем-то одним.

Стоимость задержки (Cost of Delay). Всё важное не сделаешь одновременно. То, что начнёшь позже, принесёт ценность позже — а иногда и вовсе потеряет смысл. Нужно стараться сокращать Time to Market (время от начала работ до доступности пользователям) для каждой отдельной задачи.

Поздняя обратная связь. Размытый фокус = слабая обратная связь. Когда задачи растянуты, цикл «идея → результат → выводы» удлиняется. В результате можно не сделать правильных выводов и упустить важное.

Технический и организационный долг. «Параллельный прогресс» без приоритетов умножает долги и зависимые блокировки. В процессе работы какие-то части продукта успевают устареть или измениться, что усложняет дальнейшую работу над задачей. Особенно если это что-то большое.

Вывод: делать всё — значит ничего не доводить до бизнес-эффекта. Твоя сила — в сфокусированном потоке ценности для пользователя. Старайся максимально быстро доставлять ценность и фокусироваться на задачах с максимальной ценностью.

Как приоритизировать направления?

Речь о «а куда вообще идти» — конверсия в платежи или удержание, B2B-интеграции или техническая оптимизация и т.д. Важным кажется всё, а сделать за раз можем только что-то одно. Как быть?

1) Привяжи направления к стратегии

У бизнеса есть какие-то ожидания на квартал или год. И так как задача менеджера продукта, фактически, заключается в обслуживании интересов бизнеса, релизы и развитие продукта нужно строить, исходя из бизнес-стратегии.

• Верхний уровень: доля рынка, LTV, маржинальность, позиционирование. Что из этого важнее в рамках стратегии? Вот самым важным и нужно заниматься;

• Ключевая метрика: какие входные метрики помогают нарастить ключевую метрику сейчас (активация, частота, разнообразие использования, UGC, supply/demand-баланс и т. п.).

2) Оцени потенциальный эффект

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

3) Распредели нагрузку (capacity allocation)

Заранее договорись о «рамках бэклога»: например, 70/20/10.

• 70% — работа над ключевым сценарием / воронкой (рост, удержание, монетизация);

• 20% — рост вширь (новые сегменты / каналы);

• 10% — пробуем новое (эксперименты и исследования).

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

4) Определи конкретные цели и «критические вопросы» по каждому направлению

Не «улучшить удержание», а «+3 п. п. D30 ретеншена в сегменте новых пользователей в Q4; ключевой вопрос — где основной отток: onboarding или 1-й ключевой сценарий?».

Будь конкретен и обозначай сроки — план работ сам начнёт вырисовываться. Дедлайн — самый работающий фреймворк для приоритизации задач.

5) Пересматривай планы и стратегию

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

Раз в квартал пересматривай стратегию и планы; раз в 2–4 недели пересматривай инициативы в рамках направлений по актуальным данным. Иногда самое мудрое решение — бросить начатое на середине, чем пытаться довести до конца.

Периоды для пересмотра могут быть любыми. Главное, чтобы стратегия отражала реальную ситуацию на рынке и в команде.

Какие фреймворки помогают приоритизировать задачи?

MoSCoW

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

Состоит из:

• Must have. Критические требования, без которых нельзя обойтись;

• Should have. Важные задачи следующей очереди. Без них больно, но можно прожить;

• Could have. Можно сделать, если останется время или ресурсы. Вещи, без которых можно обойтись, но прикольно сделать;

• Won’t have. Задачи, которые пока не планируется делать. Могут быть потенциально полезны, но на текущем этапе продукта не нужны.

Плюсы: помогает быстро создать общие ожидания.

Риски: слишком много задач в «Must have», отсутствие количественной ценности, и легко превращается в спор мнений.

Совет: перед разметкой зафиксируй жёсткие ограничения (дедлайн, ожидаемый результат) и метрики успеха; «Must have» — это задачи, которые реально критичны для достижения цели/срока. Подробнее.

ICE

Используется для быстрого отсева гипотез.

Формула:

ICE = Impact × Confidence × Effort

Где:

• Impact — ожидаемый эффект на ключевую метрику (оценка от 1 до 10);

• Confidence — уверенность в Impact (данные / тесты / экспертиза; оценка от 0,1 до 1, где 1 — это 100% уверенность);

• Effort — человеко-недели / сложность (чем меньше, тем выше ICE-score).

Риски: не учитывает охват аудитории (Reach), Impact «на глаз», оценки актуальны только в момент их проставления.

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

RICE

Чаще всего используется при формировании дорожных карт, квартальных планов и для сравнения фич разного масштаба.

Формула:

RICE = (Reach × Impact × Confidence) / Effort

Где:

• Reach — скольких пользователей коснётся за период (шт. / % / сессии);

• Impact — влияние на поведение / метрики (0,25 / 0,5 / 1 / 2 / 3, где 3 — это коэффициент максимального влияния);

• Confidence — уверенность 0–100% (или 0,1–1);

• Effort — человеко-недели / месяцы.

Риски: двойной учёт (Impact и Reach об одном и том же), оценки необъективны.

Совет: привяжи охват (Reach) к надёжному источнику, конкретно опиши, какая оценка Impact чему соответствует, с примерами.

Модель Kano

Что: классификация атрибутов ценности: Обязательные (Must-be), Ожидаемые (Performance), Восхищающие (Delighters), Нейтральные (Indifferent) и Негативные (Reverse).

Используется при упаковке ценности для пользователя. Например: на этапе проектирования MVP, на этапе определения стратегии маркетинга или при редизайне продукта.

Фреймворк помогает понять, почему «вау-фичи» не заменяют «базовую гигиену».

Риски: требуются корректные опросы и интервью; категории смещаются со временем (Delighter → Must), долго и дорого.

Совет: пересматривай классификацию раз в 6–12 мес., соотноси с метриками успеха. Подробнее о модели Kano.

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

Оценка возможностей (Opportunity Scoring)

Фреймворк помогает найти точки роста на основе обратной связи от пользователей продукта. Пользователи оценивают важность и удовлетворённость по сценариям / JTBD. Возможности рождаются там, где высокая важность и низкая удовлетворённость. Эти сценарии нужно оптимизировать в первую очередь, так как они дадут максимальный эффект.

Когда: выбор направлений улучшений в существующем продукте.

Плюсы: явно показывает «дыры» в опыте.

Риски: неверная выборка, неподходящие формулировки вопросов, отрыв от метрик дохода.

Совет: связывай «дыры» с поведенческими данными (аналитика / воронки), валидируй сегментами. Подробнее.

Принятие решений

Как принимать решения, когда есть несколько сильных альтернатив?

Шаг 0.  Обратимость решения и возможные риски

Прежде чем принимать решение о том, какой путь выбрать, нужно определить, какой вариант можно будет безболезненно «откатить». Тут всё просто. Если что-то можно попробовать без последствий и потом вернуть всё как было, то нужно это пробовать.

Дальше нужно оценить «радиус поражения» в случае ошибки. Чем больше риски и последствия, тем тщательнее нужно расписать план релиза и возврата.

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

Шаг 1. Чёткая формулировка задачи

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

Шаг 2. Критерии для сравнения

Сравни решения между собой, чтобы точнее определить лучший вариант. Например:

1. Ожидаемое влияние на ключевую метрику или цель квартала;

2. Скорость получения результата (за сколько недель получим надёжный сигнал об успехе или неудаче);

3. Стоимость / усилия (как финансовые, так и человеческие ресурсы);

4. Возможные риски разного рода;

5. Соответствие долгосрочной стратегии.

Эти критерии помогут детальнее понять сильные и слабые стороны каждой гипотезы.

Шаг 3. Скоринг

Используй фреймворки для приоритизации. Например, RICE. Или, используя список критериев выше, оцени каждую гипотезу по пунктам, например по пятибалльной шкале. Сложи получившиеся баллы и приоритизируй гипотезы по получившимся очкам.

Шаг 4. Когда всё еще ничья

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

• Какая альтернатива создаёт больше будущих опций / знаний? Какое решение более масштабируемое?

• Если через год окажется, что мы ошиблись — о каком невыбранном варианте ты пожалеешь сильнее?

• Представь, что решение провалилось. Почему? Что бы ты изменил сейчас?

Когда применять AARRR-анализ?

Pirate Metrics, или AARRR (Acquisition — привлечение → Activation — активация → Retention — удержание → Revenue — выручка → Referral — рекомендация), — стандартная воронка, подходящая под большинство продуктов. Позволяет определить зоны роста.

Иногда букв «A» бывает три. Это Awareness (осведомлённость) — самый верх воронки. Говорит о знании бренда/продукта. Пользователи знают, что вы, как решение, существуете.

Применяй AARRR, когда:

• Диагностируешь стагнацию/просадку: где именно «падает» рост — в привлечении, активации или удержании? Разбивай продукт на стримы (они же направления) и смотри, в каком самые большие потери. Обычно принято начинать с верха воронки;

• Выстраиваешь метрики на стадии поиска Product-Market Fit (PMF, соответствие рынку): надо просто и одинаково назвать этапы и посчитать базовые конверсии, чтобы определить, насколько продукт интересен пользователям. Если отваливаются на самом верху воронки, то либо интерес крайне низкий, либо что-то сломалось на лендинге (и так бывает);

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

• Распределяешь зоны ответственности: маркетинг, продукт, аналитика, поддержка чётко должны понимать, на какую часть воронки они влияют.

Как считать, чтобы не обмануться:

• Разбивай пользователей на когорты, а не бери средние значения;

• Определи ключевые действия и, соответственно, метрики для каждого шага воронки: что такое Activation (первый «value moment», осознание ценности), что считаем Retention (D1/D7/WAU-retention);

• Привяжись к деньгам: Retention без Revenue часто даёт ложный оптимизм. Задача бизнеса — максимизировать прибыль. Если Retention растёт, а денег нет, то толку от высокого удержания никакого;

• Определи «красные линии» или «сторожевые» метрики: процент отказов, время ответа, скорость загрузки, количество жалоб и т. д. — чтобы не выжигать продукт. Зарабатывать — это хорошо, но совсем выдаивать продукт недальновидно.

Альтернатива:

Пиратская воронка линейна, что не всегда даёт правильное представление о пользовательском пути. Для некоторых сфер лучше оперировать не воронками, а циклами (социальные сети, UGC-площадки, маркетплейсы). Причём не одним циклом, а сразу несколькими. В качестве альтернативы AARRR можно попробовать Growth Loops. Или вообще комбинировать оба подхода. AARRR покажет «где течёт», циклы — «как/почему растёт».

Прозрачность решений

Как документировать и объяснять свои решения команде и стейкхолдерам?

1. Начинай с контекста

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

Пример: «Мы выбрали запуск фичи A, потому что она решает ключевую боль сегмента X. Мы сравнивали её с фичей B, но у последней ниже ожидаемый эффект по метрике Retention D1. Решение опирается на результаты опроса и эксперимент Y.»

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

2. Описывай контекст понятным и доступным

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

Контекст: зачем принимается решение, какими были цели (бизнес-, пользовательские), на чём основано решение (данные, инсайты, ограничения);

Альтернативы: какие альтернативы рассматривались и почему были отброшены;

Выбор: что и почему выбрано;

Планы: в какую сторону планируется развивать решение.

Можно вести такие записи в Notion, Confluence или даже в Slack-тредах. Главное — чтобы они были доступны всем участникам команды в любой момент.

3. Общайся на одном языке

С командой — объясняй логику решений через призму ценности для пользователя и целей продукта. Это мотивирует команду и даёт понять «зачем». Важно доносить цели и мотивацию своих решений.

Со стейкхолдерами — подчёркивай бизнес-обоснование, выгоду и связь с целями бизнеса. Это выстраивает доверие. Ты не просто создаёшь видимость работы, а решаешь бизнес-задачи.

Как держать команду в фокусе?

1. Повторяй цели

Рассказывай и напоминай о целях. Даже когда кажется, что все уже знают. Тебе несложно повторить. Делай это столько раз, сколько требуется. Фокус не держится автоматически. Его нужно регулярно обновлять. Начинай спринты, созвоны, обсуждения с напоминания о краткосрочных целях. И хотя бы раз в квартал говори о долгосрочных планах продукта и компании.

Регулярное проговаривание цели помогает отсекать шум и синхронизирует мышление команды.

2. Работай с «почему», а не только с «что»

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

Все попытки согласовывать с тобой каждую мелочь нужно пресекать. Не поощряй такое поведение команды. Ничем хорошим это не кончится.

3. Визуализируй прогресс

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

Например: «Вот график retention. После запуска новой онбординговой фичи он подрос на 2 п. п. Двигаемся в верном направлении».

Как проверять, что решение было верным?

1. Не делай фичи ради фич

Правильное решение принимается задолго до непосредственного решения. Звучит как дурость, но важно понимать, что так называемый «фичизм» — это плохой паттерн. Ты не должен «делать фичу X». Должно быть: «фича X увеличит Retention на +3 п. п. среди сегмента Y за 2 недели после релиза».

Ты не можешь принять правильное решение по определению, если ты не решал какую-то конкретную задачу. Формируй ожидаемый результат и оценивай решения по соответствию фактического результата ожидаемому.

2. Перепроверяй решения

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

Критерии перепроверки могут быть абсолютно любые. Например:

• через 2 недели после релиза;

• после накопления 1000 MAU;

• при достижении определённой фазы проекта.

Без точки пересмотра можно легко попасть в ловушку самоуспокоенности: «ну, мы же сделали».

3. Говори об ошибках открыто

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

Пример:

«Мы ожидали рост метрики, но получили падение. Анализ показал, что новая фича перегрузила первый экран. Учтём это при следующих итерациях.»

Прозрачное обсуждение промахов делает команду и продукт сильнее. Главное — создавать безопасную среду для таких разговоров.

Итог седьмой главы

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

• Никогда не держись за одну идею — думай наборами альтернатив. Это снижает риск ошибочного выбора.

• При слабой уверенности приоритизируй исследования и эксперименты.

• Делать всё одновременно — значит терять фокус, замедляться и получать позднюю обратную связь.

• Направления развития нужно приоритизировать от стратегии бизнеса, а не от шума в бэклоге.

• Стратегия и приоритеты обязаны пересматриваться регулярно — фиксироваться на устаревшем плане опаснее, чем менять курс.

• При выборе между сильными вариантами сначала оценивай обратимость решения и «радиус поражения».

• Любое решение должно быть прозрачно задокументировано: контекст → альтернативы → выбор → дальнейшие планы.

• Команда держит фокус не сама по себе — его нужно постоянно проговаривать и визуализировать.

• Сильный продакт объясняет «почему», а не микроменеджерит «что».

• Фича без гипотезы — ошибка по определению. Сначала ожидаемый эффект, потом реализация.

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

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

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

1. Определи цель. Часто это влияние на какую-то продуктовую метрику;

2. Выдели сегмент аудитории, для которой хочешь изменить метрику;

3. Определи, какой именно эффект хочешь получить. Например, увеличить Retention D1 до 10%;

4. Сформулируй гипотезы.

Сначала результат, потом гипотезы. Не наоборот. Гипотеза — это инструмент решения задачи, а не сама задача. Представь, что тебе нужно забить гвоздь на 5 сантиметров. Твоё предположение, что это можно сделать молотком. Вот молоток и есть гипотеза.

Реальная практика, конечно же, суровее теории. Будут возникать ситуации, когда ты можешь определить метрику, на которую хочешь повлиять, но твоя цель — получить положительные статистически значимые изменения. Работа над зрелыми продуктами только так и складывается. Такой подход тоже работает, пусть и конкретики меньше. Но даже так сохраняется принцип «результат первичнее гипотез».

Шаблон ожидаемого результата

Для [сегмент/персона] в [сценарий/этап пути] мы добьёмся [изменения поведения], что приведёт к [бизнес-эффекту], измерим через [набор метрик], влияя на [ключевую метрику] через изменение [метрики влияния], при этом соблюдаем [ограничения].

Пример:

«Для новых пользователей на онбординге добьёмся роста активации с 38% до 45%. Измеряем: Ключевая метрика (Primary) — Activation, Метрики влияния (Input) — процент завершения онбординга, Time-to-Value; Ограничения — Retention D7 не ниже 24%, Отказы не ниже 10%.»

Корзина метрик

• Primary (North Star/целевая метрика): одна главная метрика результата;

• Input/метрики влияния: рычаги, на которые ты реально можешь повлиять;

• Guardrails/ограничения: что не должно ухудшиться (удержание, отказоустойчивость, маржинальность и т. д.).

Итого

Ожидаемый результат должен быть:

• Измерим и конкретен: (%, per user, per cohort), а не «сумма за всё время»;

• Основан на ключевой метрике эксперимента;

• Иметь цель, определённые показатели успеха;

• Привязан к сегменту и сценарию.

Пример плохого ожидаемого результата: «+20% MAU».

Как интерпретировать результаты?

Тут в вопросе небольшой обман. Под интерпретацией результата на самом деле подразумевается валидация данных. Если ты уверен в точности полученных метрик и в их правдивости, то сможешь сделать правильные выводы. Иду на этот обман осознанно, чтобы донести мысль: не делай выводы на данных, в достоверности которых не убеждён.

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

Пять вопросов к любому результату

Ниже перечислены важные вопросы к результату, а в скобках указано, что нужно проверить, чтобы убедиться, что всё в порядке.

1. Измерили ли мы то, что хотели? (валидность метрики, корректность ивентов);

2. Насколько велик эффект? (абсолютный прирост, относительный %, effect size);

3. Данные надёжны? (доверительные интервалы, статистическая мощность, риск ошибки; Sample Ratio Mismatch исключён?);

4. Нет ли предвзятости и противоречий в данных? (есть ли честный контроль; не перепутали сезонность/каналы/миграции?);

5. Учтены внешние эффекты? (не «съели» ли другие показатели: монетизация, стабильность, NPS; нет ли сезонности?).

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

Быстрый чеклист для проверки данных

• Проверь Sample Ratio Mismatch: доли трафика в группах соответствуют плану? Они распределены как задумано? Например, 50/50 для A/B-теста;

• Event-аудит: нет ли потерянных/дублированных событий? Уверен в источнике данных?

• Не навреди: метрики ограничений в норме?

• Переобучение/новизна: эффект не угас через 2–3 недели? Посмотри на ключевую метрику в динамике за период эксперимента и после его завершения.

Сегментация

Смотреть на результат «в среднем по больнице» категорически нельзя. Метрики в общем смысле могут вырасти, но при этом «обвалиться» по важным сегментам.

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

Какие сегменты можно выделить дополнительно:

• по источникам трафика;

• платящие / неплатящие;

• по устройствам / операционным системам;

• по географии (страны, регионы, города).

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

Unit-экономика

Совсем хорошо посчитать unit-экономику для каждого сегмента. Unit-экономика может «зарубить» позитивное изменение ключевой метрики, потому что вдруг окажется, что доходы упали по важным или вообще по всем сегментам.

Итого

Чтобы сделать правильно интерпретировать результаты:

1. убедись в достоверности данных;

2. делай выводы по каждому сегменту отдельно;

3. определи влияние на финансовые метрики.

Что делать, если данные неочевидны?

Бывает так, что после эксперимента ключевая метрика стала хуже, и совсем непонятно, почему это произошло. Метрика могла даже вырасти, но найти причины этого с первого взгляда не получается. Данные нередко бывают неочевидны.

Посмотри с разных сторон

• Исследуй воронку и найди шаг, на котором больше «отваливаются» пользователи. Пройди путь пользователя сам или попроси друзей/коллег и понаблюдай;

• Исследуй сценарий пользователя с помощью вебвизора или тепловых карт кликов для разных устройств. Возможно, есть что-то, что мешает пользоваться продуктом;

• Интервью / опросы: поговорить с пользователями всегда полезно.

Сделай метрику чувствительнее

• Перейди от «в среднем» к метрикам «на пользователя / на сессию»;

• Смотри DAU/MAU вернувшихся юзеров и медиану вместо среднего, если распределение с длинным хвостом;

• Введи ранние индикаторы (leading): время до перехода в ключевой сценарий, реферальный эффект, успешные установки.

Управление шумом и мощностью

• Увеличь период наблюдения или размер выборки;

• Раздели пользователей на однородные сегменты (один тип устройства, схожий возраст, схожий доход и т. д.);

• Используй квази-эксперименты (до–после, синтетический контроль), если A/B невозможен;

• Сформулируй решение при неопределённости: «Если прирост > X — раскат; если в [Y; X] — доэксперимент / улучшение дизайна; если < Y — откат».

Не бойся менять вопрос

Иногда ответ «неочевиден» потому, что вопрос был неправильным. Возвращайся к самому началу: какую поведенческую переменную ты хочешь сдвинуть? Возможно, ключевая метрика (North) была выбрана неверно, и вместо того чтобы искать ответ, нужно просто начать эксперимент заново, выбрав другие метрики.

Как избежать ловушек (vanity metrics)?

Vanity-метрики, или метрики тщеславия, красиво растут, но мало что решают: «всего регистраций», «всего скачиваний», «просмотры» без контекста, «лайки». Они:

• кумулятивны (легко растут);

• не нормированы (ни к чему не привязаны);

• слабо связаны с ценностью и деньгами;

• легко манипулируемы.

Проще говоря, такие общие метрики вообще никак не отражают качество продукта и его удобство. В твоём продукте может быть бешеное MAU, но при этом все эти пользователи проводят в продукте меньше минуты и никогда не возвращаются. И какой смысл от большого MAU тогда?

Принципы анти-vanity

• Нормируй: per user / per session / per cohort / per exposure (на контакт);

• Привязывай к поведению: activation, retention, frequency (частота), depth (глубина), conversion (конверсия);

• Следи за качеством: ARPU или ARPPU, LTV или CAC, churn (отток), payback (окупаемость), margin (маржа);

• Ставь ограничения: retention, отказоустойчивость, количество жалоб, возвраты средств;

• Избегай усреднений в тяжёлых хвостах: медиана и P75 (75-й процентиль) часто информативнее среднего.

Что использовать вместо vanity-метрик?

❌ Зарегистрировано всего
✅ Activation D1/D7, Процент завершения онбординга, Time-to-Value

❌ Просмотры страниц
✅ Конверсия по воронке, CTR в ключевое действие, Количество страниц за сессию

❌ Установки
✅ Доля запусков приложения после установки, Retention D1/D7, CAC

❌ Лайки/реакции
✅ Количество активных авторов, количество популярных публикаций

❌ MAU в целом
✅ DAU/MAU активной аудитории, WAU на когорту, доля вернувшихся от общего MAU

Мини-чеклист

Перед стартом эксперимента

• Ожидаемый результат сформулирован по шаблону, понятен сегмент/сценарий;

• Корзина метрик: ключевая + влияния + ограничения, единицы измерения нормированы;

• Гипотезы и риски записаны, метод измерения согласован (A/B, квази и т. д.);

• Ты уверен в источнике данных, распределение групп эксперимента контролируется.

После получения результата

• Эффект: абсолютный и относительный, с доверительным интервалом;

• Валидация причинности и контроль фоновых факторов (сезонность, источники привлечения, релизы в продукте);

• Сегментация: где эффект концентрируется / исчезает;

• Метрики ограничений в норме, внешних издержек нет;

• Решение и следующий шаг: раскат / итерация / откат; обнови приоритеты и карту метрик;

• Зафиксируй результаты эксперимента: контекст → гипотеза → метод → результат → решение → что делать иначе в следующий раз.

Итог шестой главы

• North Star Metric — главная метрика продукта, отражающая ценность для пользователя и коррелирующая с бизнес-результатами;

• Фреймворк HEART (Happiness, Engagement, Adoption, Retention, Task Success) — удобная структура для выбора релевантных метрик;

• Leading и Lagging метрики — нужно балансировать между предсказывающими и фиксирующими результат показателями;

• Источники данных — количественные (аналитика, CRM, финансы, логи) и качественные (интервью, саппорт, продажи); важно интегрировать их в единый «источник правды»;

• Метрики для новых функций — сначала цель, затем ключевая метрика, связанные показатели, сроки и критерии успеха;

• Если аналитики нет — начать с 3–5 базовых метрик и коробочных систем (Яндекс.Метрика, AppMetrica), постепенно выстраивая культуру работы с данными;

• Главные ошибки — гонка за vanity-метриками, игнорирование целостной картины, отсутствие сегментов, подгонка целей под результат;

• Вовлечённость — измеряется частотой, глубиной и регулярностью использования продукта, а не просто «временем в приложении»;

• Retention — зеркало вовлечённости, отражает возвращаемость за ценностью и напрямую связано с монетизацией (LTV);

• Поведение = доход — выручка растёт через активацию, глубину использования, удержание и сегментацию пользователей;

• Интерпретация результатов — важна достоверность данных, проверка эффекта, сегментация и влияние на юнит-экономику;

• Неочевидные данные — нужно копать глубже: анализировать воронку, интервьюировать пользователей, смотреть медианы, увеличивать выборку;

• Vanity-метрики — опасны, так как не отражают реальную ценность. Их заменяют нормированные и поведенческие показатели (activation, retention, ARPU и др.).

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