8 советов по работе с логами продукта
1. Ведите decision log с условиями пересмотра, а не просто с решениями
Записывайте не только «что решили», но и «при каком сигнале пересмотрим», например, «откатим, если retention упадёт ниже X».
Так решение превращается из мнения в понятную и для всех проверяемую ставку, а вы с командой перестаёте каждый раз спорить о том, что уже обсуждали ранее. Полгода спустя этот лог будет лучшим свидетельством того, какие (и чьи) гипотезы сбылись, а какие нет.
2. Калибруйте собственные прогнозы и лог: дата релиза, ожидаемое внедрение, ожидаемый эффект и через время сверяйте их с фактом.
Почти никто этого не делает, поэтому почти никто не знает, систематически ли он оптимист по срокам или пессимист по импакту. В то время, как через десяток подобных записей вы начнёте давать оценки, которым можно доверять всё больше и больше.
3. Размечайте решения как «дверь в одну сторону» или «в две стороны»
Обратимые решения принимайте быстро и дёшево, необратимые – с реальной строгостью.
Ошибка многих продактов в том, что они тратят одинаковую энергию себя и команды на оба типа, и в этом главная утечка скорости. Само наличие такого тега заставляет команду не раздувать процессы там, где цена ошибки это просто один откат фичи.
4. Инструментируйте спеку, а не продукт
Определяй метрики и названия событий прямо в PRD, ещё ДО разработки (а не «допишем аналитику потом»). Потому что «мы забыли это трекать» это самая частая и самая дорогая (и лекго предотвратимая) ошибка продакта.
5. Ведите в лог карту допущений с осями «уверенность × влияние»
Отделяйте discovery-долг от delivery-долга как список открытых вопросов и допущений с явной пометкой, насколько вы в них уверены.
6. Делайте pre-mortem с триггерами, а не как разовое упражнение
Опишите провал до запуска, а к каждому сценарию провала привяжите опережающий индикатор из пункта 1 и 2.
Так pre-mortem превращается из психологической разминки в настройку, благодаря которой вы заранее знаете, какую метрику и график будете смотреть и какое его значение означает, что пора вмешаться.
7. Заведите «кладбище» отклонённых идей с причинами. Каждая зарезанная фича отправляется в searchable-список продуктовой wiki с строкой «почему нет».
Это лекарство от бесконечного цикла переобсуждения одного и того же командой и одновременно ваш самый честный материал для раздела «Не делаем» в новых PRD.
8. Кодифицируй ход мышления-решений
«Как ты узнал?» / «У нас метрика Х упала, ааачоделать?» / «СЕО опять принёс идею, что ответить» и прочее повторяющееся изо дня в день выпиши как личную библиотеку подходов и приёмов.
Ответы: «Подумал, уточнил, проверил» / «Проверил фичи, что релизили недавно» / «Вернём ему проблему»
Управление контекстом вокруг контента и есть тот самый недооценённый актив команды продукта и главный навык продакта.
1. Ведите decision log с условиями пересмотра, а не просто с решениями
Записывайте не только «что решили», но и «при каком сигнале пересмотрим», например, «откатим, если retention упадёт ниже X».
Так решение превращается из мнения в понятную и для всех проверяемую ставку, а вы с командой перестаёте каждый раз спорить о том, что уже обсуждали ранее. Полгода спустя этот лог будет лучшим свидетельством того, какие (и чьи) гипотезы сбылись, а какие нет.
2. Калибруйте собственные прогнозы и лог: дата релиза, ожидаемое внедрение, ожидаемый эффект и через время сверяйте их с фактом.
Почти никто этого не делает, поэтому почти никто не знает, систематически ли он оптимист по срокам или пессимист по импакту. В то время, как через десяток подобных записей вы начнёте давать оценки, которым можно доверять всё больше и больше.
3. Размечайте решения как «дверь в одну сторону» или «в две стороны»
Обратимые решения принимайте быстро и дёшево, необратимые – с реальной строгостью.
Ошибка многих продактов в том, что они тратят одинаковую энергию себя и команды на оба типа, и в этом главная утечка скорости. Само наличие такого тега заставляет команду не раздувать процессы там, где цена ошибки это просто один откат фичи.
4. Инструментируйте спеку, а не продукт
Определяй метрики и названия событий прямо в PRD, ещё ДО разработки (а не «допишем аналитику потом»). Потому что «мы забыли это трекать» это самая частая и самая дорогая (и лекго предотвратимая) ошибка продакта.
События/метрик нет в документе = их и не будет после
5. Ведите в лог карту допущений с осями «уверенность × влияние»
Отделяйте discovery-долг от delivery-долга как список открытых вопросов и допущений с явной пометкой, насколько вы в них уверены.
Де-рискинг самого опасного допущения и вот вы уже перестаёте строить уверенно поверх того, во что на самом деле не верите
6. Делайте pre-mortem с триггерами, а не как разовое упражнение
Опишите провал до запуска, а к каждому сценарию провала привяжите опережающий индикатор из пункта 1 и 2.
Так pre-mortem превращается из психологической разминки в настройку, благодаря которой вы заранее знаете, какую метрику и график будете смотреть и какое его значение означает, что пора вмешаться.
7. Заведите «кладбище» отклонённых идей с причинами. Каждая зарезанная фича отправляется в searchable-список продуктовой wiki с строкой «почему нет».
Это лекарство от бесконечного цикла переобсуждения одного и того же командой и одновременно ваш самый честный материал для раздела «Не делаем» в новых PRD.
Сильный продакт узнаётся по тому, как быстро он объясняет, почему "нет"
8. Кодифицируй ход мышления-решений
«Как ты узнал?» / «У нас метрика Х упала, ааачоделать?» / «СЕО опять принёс идею, что ответить» и прочее повторяющееся изо дня в день выпиши как личную библиотеку подходов и приёмов.
Ответы: «Подумал, уточнил, проверил» / «Проверил фичи, что релизили недавно» / «Вернём ему проблему»
Управление контекстом вокруг контента и есть тот самый недооценённый актив команды продукта и главный навык продакта.