RAT: проверяем самое рискованное в идее
Riskiest Assumption Test - проверка самого рискованного допущения в идее
MVP проверяет жизнеспособность: ценность, сценарий, решение, иногда экономику.
RAT нужен раньше, когда еще страшно тратить недели команды даже на маленькую версию продукта.
Пример:
Хотим сделать быстрые ответы для родителей в чат-боте по питанию.
Самое рискованное допущение: родители вообще хотят задавать такие вопросы на платформе.
В этом случае можно проверить через fake door: показать кнопку "Задать вопрос по питанию",
посчитать клики и собрать реальные формулировки вопросов.
За дверью может быть ручная обработка, форма или честное "скоро запустим".
Плюс RAT: быстрее проходим путь до знания, меньше влюбляемся в решение
Минус RAT: принять решение по реализации, проверив RATом слишком узкий кусок
Проводите RAT или всегда проверяете через MVP?
❤️ да, было
😈 из RAT только крысиный чатик на работе
#pm #product #словарикпродакта
Riskiest Assumption Test - проверка самого рискованного допущения в идее
MVP проверяет жизнеспособность: ценность, сценарий, решение, иногда экономику.
RAT нужен раньше, когда еще страшно тратить недели команды даже на маленькую версию продукта.
Пример:
Хотим сделать быстрые ответы для родителей в чат-боте по питанию.
Самое рискованное допущение: родители вообще хотят задавать такие вопросы на платформе.
В этом случае можно проверить через fake door: показать кнопку "Задать вопрос по питанию",
посчитать клики и собрать реальные формулировки вопросов.
За дверью может быть ручная обработка, форма или честное "скоро запустим".
Плюс RAT: быстрее проходим путь до знания, меньше влюбляемся в решение
Минус RAT: принять решение по реализации, проверив RATом слишком узкий кусок
Проводите RAT или всегда проверяете через MVP?
❤️ да, было
😈 из RAT только крысиный чатик на работе
#pm #product #словарикпродакта
😈7❤2🔥1
Парадокс Симпсона: средняя метрика умеет врать
Simpson’s Paradox - ситуация, где общий результат показывает рост, а внутри важных сегментов всё становится хуже.
Например, выкатываем новый чекаут. В агрегате конверсия выросла с 6% до 6,5%, команда открывает шампанское и катит на всех.
Потом смотрим глубже: у новых пользователей и старых просадка, на iOS просадка. В итоге просто в тест случайно попало больше теплого трафика, который и так покупал чаще.
Защита от ошибки обычная: заранее определить ключевые сегменты, проверить баланс трафика.
Удивляюсь, что попадаются термины, с которыми работал, но не знал их академического названия, а вы?
❤️ структурирует мысли
😈 это всё ЭмВиПи
#pm #product #словарикпродакта
Simpson’s Paradox - ситуация, где общий результат показывает рост, а внутри важных сегментов всё становится хуже.
Например, выкатываем новый чекаут. В агрегате конверсия выросла с 6% до 6,5%, команда открывает шампанское и катит на всех.
Потом смотрим глубже: у новых пользователей и старых просадка, на iOS просадка. В итоге просто в тест случайно попало больше теплого трафика, который и так покупал чаще.
Защита от ошибки обычная: заранее определить ключевые сегменты, проверить баланс трафика.
Удивляюсь, что попадаются термины, с которыми работал, но не знал их академического названия, а вы?
❤️ структурирует мысли
😈 это всё ЭмВиПи
#pm #product #словарикпродакта
1❤5✍3👍1😈1
Diff-in-Diff: когда A/B-тест невозможен
Difference-in-Differences помогает оценить эффект изменений без рандомизации.
Метод сравнивает изменение метрики относительно изменения от начального показателя похожей контрольной группы.
Например, изменение воронки сначала запустили только в одном регионе. Продажи выросли на 10%.
Это успех или просто сезонность?
DiD сравнит изменение с регионом, где ничего не запускали, и попробует отделить эффект релиза от всего остального.
Метод давно используют в экономике, медицине и государственной политике, где эксперименты часто невозможны или неэтичны.
Важное ограничение: метод предполагает, что без изменений обе группы продолжили бы двигаться примерно одинаково. Если это не так, выводам доверять уже нельзя.
Если нельзя провести A/B, DiD становится наилучшей альтернативой оценить эффект.
❤️ да, было
😈 сравнивал до/после
#pm #product #словарикпродакта
Difference-in-Differences помогает оценить эффект изменений без рандомизации.
Метод сравнивает изменение метрики относительно изменения от начального показателя похожей контрольной группы.
Например, изменение воронки сначала запустили только в одном регионе. Продажи выросли на 10%.
Это успех или просто сезонность?
DiD сравнит изменение с регионом, где ничего не запускали, и попробует отделить эффект релиза от всего остального.
Метод давно используют в экономике, медицине и государственной политике, где эксперименты часто невозможны или неэтичны.
Важное ограничение: метод предполагает, что без изменений обе группы продолжили бы двигаться примерно одинаково. Если это не так, выводам доверять уже нельзя.
Если нельзя провести A/B, DiD становится наилучшей альтернативой оценить эффект.
❤️ да, было
😈 сравнивал до/после
#pm #product #словарикпродакта
👍6❤4🔥2
Brand Health Tracking: чекап бренда
Brand Health Tracking помогает понять, что пользователи думают о бренде и почему выбирают именно его.
Обычно в рамках BHT в динамике замеряют знание бренда, предпочтение относительно аналогов, ключевые ассоциации и готовность рекомендовать.
Например, знание бренда выросло после рекламной кампании, а предпочтение осталось прежним: люди запомнили рекламу, но причины выбрать продукт пока не появилось. Эти разрывы и помогает находить Brand Health Tracking.
Метрикой обычно владеет маркетинг, сильный бренд повышает органическое привлечение, рекомендации и конверсию в первую покупку.
Brand Health Tracking часто рассматривают как опережающий индикатор будущего роста продуктовых метрик.
❤️ измеряем здоровье бренда
#словарикпродакта #pm #product #marketing
Brand Health Tracking помогает понять, что пользователи думают о бренде и почему выбирают именно его.
Обычно в рамках BHT в динамике замеряют знание бренда, предпочтение относительно аналогов, ключевые ассоциации и готовность рекомендовать.
Например, знание бренда выросло после рекламной кампании, а предпочтение осталось прежним: люди запомнили рекламу, но причины выбрать продукт пока не появилось. Эти разрывы и помогает находить Brand Health Tracking.
Метрикой обычно владеет маркетинг, сильный бренд повышает органическое привлечение, рекомендации и конверсию в первую покупку.
Brand Health Tracking часто рассматривают как опережающий индикатор будущего роста продуктовых метрик.
❤️ измеряем здоровье бренда
#словарикпродакта #pm #product #marketing
❤4👍3🔥2
Stage-Gate: инвестиционные ворота продукта
Stage-Gate, или Phase-Gate, это фреймворк управления разработкой продукта через инвестиции.
В классике проект проходит путь:
Discovery → Scoping → Business Case → Develop → Test & Validate → Launch
из нестандартных названий этапов:
Scoping - оценка рынка, пользователя и технической реализации
Business Case - формирование концепции продукта, его экономики и плана разработки.
Между этапами стоят гейты, где команда подтверждает готовность двигаться дальше. На встрече обсуждают три вещи:
1 - deliverables - обязательные артефакты этапа
2 - criteria - критерии оценки проекта
3 - outputs - решения по итогам
Решений обычно четыре:
Go означает продолжить и выделить ресурсы
Kill закрывает проект
Hold ставит его на паузу
Recycle возвращает команду на доработку текущего этапа.
Вместе с решением фиксируют ресурсы, ответственных и дату следующего Gate.
Историческая справка:
Stage-Gate появился в 1980-х в работах Роберта Купера по управлению разработкой новых продуктов. Он не вырос из Double Diamond, который появился позже. Double Diamond помогает организовать поиск проблемы и решения, Stage-Gate управляет инвестициями, доказательствами и допуском проекта к следующему этапу.
Самостоятельность Stage-Gate в том, что он управляет всем инвестиционным циклом продукта: задает этапы, правила допуска,
набор доказательств и моменты остановки проекта.
❤️ проходил Gate
😈 сначала запустили, потом собрали Business Case
#pm #product #словарикпродакта
Stage-Gate, или Phase-Gate, это фреймворк управления разработкой продукта через инвестиции.
В классике проект проходит путь:
Discovery → Scoping → Business Case → Develop → Test & Validate → Launch
из нестандартных названий этапов:
Scoping - оценка рынка, пользователя и технической реализации
Business Case - формирование концепции продукта, его экономики и плана разработки.
Между этапами стоят гейты, где команда подтверждает готовность двигаться дальше. На встрече обсуждают три вещи:
1 - deliverables - обязательные артефакты этапа
2 - criteria - критерии оценки проекта
3 - outputs - решения по итогам
Решений обычно четыре:
Go означает продолжить и выделить ресурсы
Kill закрывает проект
Hold ставит его на паузу
Recycle возвращает команду на доработку текущего этапа.
Вместе с решением фиксируют ресурсы, ответственных и дату следующего Gate.
Историческая справка:
Stage-Gate появился в 1980-х в работах Роберта Купера по управлению разработкой новых продуктов. Он не вырос из Double Diamond, который появился позже. Double Diamond помогает организовать поиск проблемы и решения, Stage-Gate управляет инвестициями, доказательствами и допуском проекта к следующему этапу.
Самостоятельность Stage-Gate в том, что он управляет всем инвестиционным циклом продукта: задает этапы, правила допуска,
набор доказательств и моменты остановки проекта.
❤️ проходил Gate
😈 сначала запустили, потом собрали Business Case
#pm #product #словарикпродакта
❤5👍3🔥3😈1
Selection bias: когда выборка решила за вас
Закрываю гештальт по A/B, кто знает - тот в курсе:)
Selection bias - смещение отбора, которое возникает, когда пользователи в анализе системно отличаются от тех, о ком команда хочет сделать вывод.
Например, запустили новую механику рекомендаций и посмотрели конверсию сегменты: результат отличный! Вот только воспользовались ей самые активные пользователи, которые и раньше покупали чаще.
В итоге команда приписывает продукту эффект, который появился из-за состава выборки, а не из-за продуктового изменения.
Selection bias встречается в опросах, исследованиях, пилотах и A/B-тестах. Например, когда NPS собирают только у постоянных клиентов, анализируют только завершивших onboarding или исключают пользователей, которые перестали пользоваться продуктом после изменения.
С SRM (Sample Ratio Mismatch) есть пересечение, но это разные проблемы. SRM показывает, что участники распределились между группами не в ожидаемой пропорции. Selection bias шире: группы могут идеально разделиться 50/50, но выборка все равно окажется смещенной из-за того, кого включили в анализ.
Хорошая метрика на плохой выборке дает плохое решение с красивым графиком😎
❤️ проверяю состав выборки, осознанно выбираю сегменты
😈 спрашиваю мнение только у выживших
#pm #product #словарикпродакта #ab #analytics
Закрываю гештальт по A/B, кто знает - тот в курсе:)
Selection bias - смещение отбора, которое возникает, когда пользователи в анализе системно отличаются от тех, о ком команда хочет сделать вывод.
Например, запустили новую механику рекомендаций и посмотрели конверсию сегменты: результат отличный! Вот только воспользовались ей самые активные пользователи, которые и раньше покупали чаще.
В итоге команда приписывает продукту эффект, который появился из-за состава выборки, а не из-за продуктового изменения.
Selection bias встречается в опросах, исследованиях, пилотах и A/B-тестах. Например, когда NPS собирают только у постоянных клиентов, анализируют только завершивших onboarding или исключают пользователей, которые перестали пользоваться продуктом после изменения.
С SRM (Sample Ratio Mismatch) есть пересечение, но это разные проблемы. SRM показывает, что участники распределились между группами не в ожидаемой пропорции. Selection bias шире: группы могут идеально разделиться 50/50, но выборка все равно окажется смещенной из-за того, кого включили в анализ.
Хорошая метрика на плохой выборке дает плохое решение с красивым графиком😎
❤️ проверяю состав выборки, осознанно выбираю сегменты
😈 спрашиваю мнение только у выживших
#pm #product #словарикпродакта #ab #analytics
❤5👍3😁1😈1
Human-in-the-loop: оставьте человеку красную кнопку
HITL - подход, при котором ИИ выполняет часть работы, а человек остается внутри процесса: проверяет результат, принимает сложные решения и корректирует систему.
Например, модель обрабатывает обращения в поддержку:
• простые вопросы закрывает сама
• спорные передает оператору
• решение оператора использует как новый контекст обучения
Чем выше риск и ниже уверенность модели, тем раньше подключается человек.
Для продукта важно заранее определить границы автономности: какие решения ИИ принимает сам, где нужен контроль, какой уровень confidence запускает эскалацию и как сохраняется обратная связь.
Но есть проблема, что человек постепенно перестаёт быть судьёй и превращается в оператора подтверждений: система чаще подкидывает готовые ответы, критическое мышление человека проседает, решения сводятся к формальному оку.
Хороший HITL сокращает ручную работу и сохраняет контроль над критичными решениями.
❤️ оставляю человеку финальное решение
😈 подключаю человека после инцидента
#pm #product #HITL #словарикпродакта
HITL - подход, при котором ИИ выполняет часть работы, а человек остается внутри процесса: проверяет результат, принимает сложные решения и корректирует систему.
Например, модель обрабатывает обращения в поддержку:
• простые вопросы закрывает сама
• спорные передает оператору
• решение оператора использует как новый контекст обучения
Чем выше риск и ниже уверенность модели, тем раньше подключается человек.
Для продукта важно заранее определить границы автономности: какие решения ИИ принимает сам, где нужен контроль, какой уровень confidence запускает эскалацию и как сохраняется обратная связь.
Но есть проблема, что человек постепенно перестаёт быть судьёй и превращается в оператора подтверждений: система чаще подкидывает готовые ответы, критическое мышление человека проседает, решения сводятся к формальному оку.
Хороший HITL сокращает ручную работу и сохраняет контроль над критичными решениями.
❤️ оставляю человеку финальное решение
😈 подключаю человека после инцидента
#pm #product #HITL #словарикпродакта
❤4👍3✍1😈1
Сторипоинты: абстракция сложности по Фибоначчи
В Agile-командах оценка обычно учитывает объём, сложность и неопределённость задачи. Сторипоинты используют вместе с планинг-покером и выставляют по шкале Фибоначчи: 1, 2, 3, 5, 8.
По канону пять сторипоинтов не означают пять дней. Задача просто больше тройки и меньше восьмёрки относительно понятного команде примера.
А в гайде по Scrum сторипоинтов вообще нет! Это отдельная практика оценки, выросшая из Extreme Programming.
По моему опыту, абстрактная конструкция плохо переживает встречу с реальностью: при финальном планировании сторипоинты всё равно превращались в дни по курсу один к одному.
Сторипоинты полезны скорее как повод обсудить сложность, риски и уверенность команды в оценке. В том числе понять, какой Confidence ставить инициативе в RICE.
Вы как работаете со сторипоинтами?
❤️ реально относительные
😈 один сторипоинт = один день
#pm #product #словарикпродакта
Story points — относительная единица трудоёмкости, которой команда оценивает усилия, необходимые для выполнения задачи, сравнивая её с другими задачами.
В Agile-командах оценка обычно учитывает объём, сложность и неопределённость задачи. Сторипоинты используют вместе с планинг-покером и выставляют по шкале Фибоначчи: 1, 2, 3, 5, 8.
По канону пять сторипоинтов не означают пять дней. Задача просто больше тройки и меньше восьмёрки относительно понятного команде примера.
А в гайде по Scrum сторипоинтов вообще нет! Это отдельная практика оценки, выросшая из Extreme Programming.
По моему опыту, абстрактная конструкция плохо переживает встречу с реальностью: при финальном планировании сторипоинты всё равно превращались в дни по курсу один к одному.
Сторипоинты полезны скорее как повод обсудить сложность, риски и уверенность команды в оценке. В том числе понять, какой Confidence ставить инициативе в RICE.
Вы как работаете со сторипоинтами?
❤️ реально относительные
😈 один сторипоинт = один день
#pm #product #словарикпродакта
❤4🔥2😈2👍1
Среднее и медиана: у нас всё хорошо, но это не точно
Зарплаты пяти сотрудников: 100, 110, 120, 130 и 1 000 тысяч.
👉 Среднее: сумма значений / их количество = 292 тысячи.
👉 Медиана: значение посередине ряда = 120 тысяч.
Один руководитель поднял среднюю зарплату компании почти в 2,5 раза.
Среднее полезно для расчёта экономики: средний чек, ARPU.
Медиана лучше показывает типичный опыт: время доставки, загрузки или ответа поддержки.
Пример из отслеживания здоровья сайта: типичный запрос занимал около 50 мс, но 6% запросов были в 20 раз медленнее. Среднее не показывало проблему, поэтому вместо него смотрим перцентили:
p50 - это медиана, то есть время, быстрее которого выполняется 50% запросов
p95 - значение, быстрее которого укладываются 95% запросов
p99 - почти все запросы, кроме самых редких задержек
Одна цифра редко описывает всё распределение. Лучше смотреть и на центр, и на хвосты.
❤️ смотрю распределение целиком
😈 беру цифру, которая красивее в презентации
#pm #product #аналитика #словарикпродакта
Зарплаты пяти сотрудников: 100, 110, 120, 130 и 1 000 тысяч.
👉 Среднее: сумма значений / их количество = 292 тысячи.
👉 Медиана: значение посередине ряда = 120 тысяч.
Один руководитель поднял среднюю зарплату компании почти в 2,5 раза.
Среднее полезно для расчёта экономики: средний чек, ARPU.
Медиана лучше показывает типичный опыт: время доставки, загрузки или ответа поддержки.
Пример из отслеживания здоровья сайта: типичный запрос занимал около 50 мс, но 6% запросов были в 20 раз медленнее. Среднее не показывало проблему, поэтому вместо него смотрим перцентили:
p50 - это медиана, то есть время, быстрее которого выполняется 50% запросов
p95 - значение, быстрее которого укладываются 95% запросов
p99 - почти все запросы, кроме самых редких задержек
Одна цифра редко описывает всё распределение. Лучше смотреть и на центр, и на хвосты.
❤️ смотрю распределение целиком
😈 беру цифру, которая красивее в презентации
#pm #product #аналитика #словарикпродакта
❤5💯4👍3
Contextual Product Management: подход зависит от задачи
Заметил интересный термин в статье, делюсь.
Все любят универсальные рецепты: исследовать пользователей, быстро проверять, скопировать процессы успешных компаний. Но есть проблема, что условные банковский продукт и внутренняя HR система требуют разных способов подхода.
Contextual Product Management предлагает сначала понять среду: насколько продукт зрелый, велика ли неопределённость, какова цена ошибки... после этого выбирать процессы, метрики и глубину исследований.
Термин нужен как защита от слепого копирования практик: что ускоряет одну команду, может замедлить другую.
В научных работах понятие закрепилось недавно, хотя сам принцип вырос из теории ситуационного управления, держу в курсе.
❤️ контекст - всему голова
😈 RICE и SMART на все случаи
#pm #product #productmanagement #словарикпродакта
Заметил интересный термин в статье, делюсь.
Все любят универсальные рецепты: исследовать пользователей, быстро проверять, скопировать процессы успешных компаний. Но есть проблема, что условные банковский продукт и внутренняя HR система требуют разных способов подхода.
Contextual Product Management предлагает сначала понять среду: насколько продукт зрелый, велика ли неопределённость, какова цена ошибки... после этого выбирать процессы, метрики и глубину исследований.
Термин нужен как защита от слепого копирования практик: что ускоряет одну команду, может замедлить другую.
В научных работах понятие закрепилось недавно, хотя сам принцип вырос из теории ситуационного управления, держу в курсе.
❤️ контекст - всему голова
😈 RICE и SMART на все случаи
#pm #product #productmanagement #словарикпродакта
❤8👍5😈1
Формальный результат: не перепутать движение с прогрессом
Мы часто целимся в формальный результат не потому, что он важнее, а потому что к нему проще построить маршрут. Получить диплом, запустить проект, выполнить план легче, чем ответить на более неприятный вопрос: что в реальности изменилось благодаря моим действиям?
Формальный результат даёт ощущение завершённости и контроля.
И в этом его главная ловушка: можно очень дисциплинированно двигаться вперёд, но не туда.
В продукте происходит то же самое: метрики тщеславия растут охотнее, чем метрики реальной ценности.
Формальный результат, конечно, лучше полного бездействия, но его стоит воспринимать как промежуточную отметку, а не доказательство успеха.
Поэтому, кажется, одна из самых важных привычек это периодически отрываться от собственного плана и спрашивать себя: я действительно приближаюсь к результату или становлюсь успешнее в выполнении его формальных признаков?
❤️ стараюсь рефлексировать
😈 котлетка растет от зеленого KPI
#pm #productmanagement #мысли
Мы часто целимся в формальный результат не потому, что он важнее, а потому что к нему проще построить маршрут. Получить диплом, запустить проект, выполнить план легче, чем ответить на более неприятный вопрос: что в реальности изменилось благодаря моим действиям?
Формальный результат даёт ощущение завершённости и контроля.
И в этом его главная ловушка: можно очень дисциплинированно двигаться вперёд, но не туда.
В продукте происходит то же самое: метрики тщеславия растут охотнее, чем метрики реальной ценности.
Формальный результат, конечно, лучше полного бездействия, но его стоит воспринимать как промежуточную отметку, а не доказательство успеха.
Поэтому, кажется, одна из самых важных привычек это периодически отрываться от собственного плана и спрашивать себя: я действительно приближаюсь к результату или становлюсь успешнее в выполнении его формальных признаков?
❤️ стараюсь рефлексировать
😈 котлетка растет от зеленого KPI
#pm #productmanagement #мысли
❤5👍1😈1
Observability: что происходит внутри IT-системы
Я тут микроскопом забиваю гвозди на проектах, которые навайбкодил, и решил разобраться в инструментах работы с данными в широком смысле: техническими, продуктовыми и бизнесовыми.
Впереди серия постов, комментарии экспертов приветствуются!
Observability (наблюдаемость системы) помогает понять, что происходит внутри IT-системы и почему: мониторить ее в обычное время и расследовать, что пошло не так при инциденте.
Обычно выделяют три основных типа телеметрии:
Metrics - числа во времени: запросы, ошибки, задержки
Logs - записи о конкретных событиях и ошибках
Traces - путь конкретного запроса через сервисы
А Grafana и Prometheus... уже инструменты внутри observability, о них в следующем посте.
❤️ знаю, что метрики и логи это разное
😈 не поднимался тот сервис, который не падал
#pm #product #cловарикпродакта #observability
Я тут микроскопом забиваю гвозди на проектах, которые навайбкодил, и решил разобраться в инструментах работы с данными в широком смысле: техническими, продуктовыми и бизнесовыми.
Впереди серия постов, комментарии экспертов приветствуются!
Observability (наблюдаемость системы) помогает понять, что происходит внутри IT-системы и почему: мониторить ее в обычное время и расследовать, что пошло не так при инциденте.
Термин пришел в IT из теории управления observability означает возможность определить внутреннее состояние системы по ее внешним сигналам. Термин формализовал математик Рудольф Кальман в 1960-х. Позже идея перекочевала в эксплуатацию сложных программных систем.
Monitoring отвечает «всё ли работает?», observability помогает разобраться «а что именно произошло?»
Обычно выделяют три основных типа телеметрии:
Metrics - числа во времени: запросы, ошибки, задержки
Logs - записи о конкретных событиях и ошибках
Traces - путь конкретного запроса через сервисы
А Grafana и Prometheus... уже инструменты внутри observability, о них в следующем посте.
❤️ знаю, что метрики и логи это разное
😈 не поднимался тот сервис, который не падал
#pm #product #cловарикпродакта #observability
❤8👍3😈2
Grafana и Prometheus: что я забыл в DevOps-инструментах
В прошлом посте было три типа телеметрии для Observability: Metrics, Logs и Traces
Prometheus работает прежде всего с Metrics - числовыми показателями состояния системы во времени.
Например, метрика покажет: 12:03 → 2% запросов завершились ошибкой
Лог сохранит конкретное событие: 12:03:14 → / payment → ошибка 500
Поэтому метрики помогают увидеть, что с системой происходит по конкретным параметрам, а логи - разобраться, что именно происходило в конкретном случае.
Сервис может вести счетчики запросов и ошибок, а Prometheus регулярно забирать их значения.
Бывает и наоборот: показатель рассчитывают из множества логов - это logs-based metrics.
Grafana подключается к Prometheus и другим источникам и превращает эти данные в графики, дашборды с алертами.
Отсюда мой микроскоп для гвоздей:
Grafana хорошо показывает техническое здоровье системы во времени, но продуктовая аналитика часто требует восстановить поведение конкретного пользователя.
В следующем посте: почему для этого используют другие инструменты и причем тут BI
❤️ смотрю в Графану сам
😈 узнаю о проблемах от пользователей
#pm #product #словарик #grafana #prometheus #observability
В прошлом посте было три типа телеметрии для Observability: Metrics, Logs и Traces
Prometheus работает прежде всего с Metrics - числовыми показателями состояния системы во времени.
Например, метрика покажет: 12:03 → 2% запросов завершились ошибкой
Лог сохранит конкретное событие: 12:03:14 → / payment → ошибка 500
Поэтому метрики помогают увидеть, что с системой происходит по конкретным параметрам, а логи - разобраться, что именно происходило в конкретном случае.
Сервис может вести счетчики запросов и ошибок, а Prometheus регулярно забирать их значения.
Бывает и наоборот: показатель рассчитывают из множества логов - это logs-based metrics.
Grafana подключается к Prometheus и другим источникам и превращает эти данные в графики, дашборды с алертами.
Отсюда мой микроскоп для гвоздей:
Grafana хорошо показывает техническое здоровье системы во времени, но продуктовая аналитика часто требует восстановить поведение конкретного пользователя.
В следующем посте: почему для этого используют другие инструменты и причем тут BI
❤️ смотрю в Графану сам
😈 узнаю о проблемах от пользователей
#pm #product #словарик #grafana #prometheus #observability
❤5👍4✍2🔥1
Grafana, BI и продуктовая аналитика: если везде графики, в чем разница?
В прошлых постах разобрались:
• Grafana хорошо показывает техническое здоровье системы
• я использовал ее и для простых продуктовых метрик
Зачем тогда вообще нужны другие инструменты?
Разница в вопросах, на которые они помогают отвечать:
Grafana - что происходит с системой?
ошибки, нагрузка, задержки, изменение метрик во времени
BI (Business Intelligence) - что происходит с бизнесом?
выручка по продуктам, продажи по регионам, динамика показателей
Tableau, Power BI и Metabase - примеры BI-инструментов(чтоб потом потом поиском по каналу найти:) )
Продуктовая аналитика - что делают пользователи?
воронки, retention, когорты, путь внутри продукта.
Amplitude, MyTracker и похожие системы работают с событиями пользователей
MyTracker заодно закрывает задачи маркетинговой аналитики и атрибуции
Под красивыми графиками лежит еще один слой - хранение и обработка данных.
Например, DWH(Data Warehouse) - аналитическое хранилище
ClickHouse - конкретная СУБД
YT/YTsaurus - распределенная платформа для хранения и обработки больших данных, про нее отдельно
Итого, графики могут выглядеть одинаково, но под ними разные модели данных и задачи.
Границы размыты: продажи можно вывести и в Grafana, технические метрики - в BI.
Вопрос скорее в том, для какой задачи создавался инструмент и какие операции с данными в нем делать удобно, а там и его быстродействие с отказостойкостью.
❤️ знаю, где какой дашборд лежит
😈 иксель закроет все три задачи, топ СУБД
#pm #product #словарик #bi #analytics #grafana
В прошлых постах разобрались:
• Grafana хорошо показывает техническое здоровье системы
• я использовал ее и для простых продуктовых метрик
Зачем тогда вообще нужны другие инструменты?
Разница в вопросах, на которые они помогают отвечать:
Grafana - что происходит с системой?
ошибки, нагрузка, задержки, изменение метрик во времени
BI (Business Intelligence) - что происходит с бизнесом?
выручка по продуктам, продажи по регионам, динамика показателей
Tableau, Power BI и Metabase - примеры BI-инструментов(чтоб потом потом поиском по каналу найти:) )
Продуктовая аналитика - что делают пользователи?
воронки, retention, когорты, путь внутри продукта.
Amplitude, MyTracker и похожие системы работают с событиями пользователей
MyTracker заодно закрывает задачи маркетинговой аналитики и атрибуции
Под красивыми графиками лежит еще один слой - хранение и обработка данных.
Например, DWH(Data Warehouse) - аналитическое хранилище
ClickHouse - конкретная СУБД
YT/YTsaurus - распределенная платформа для хранения и обработки больших данных, про нее отдельно
Итого, графики могут выглядеть одинаково, но под ними разные модели данных и задачи.
Границы размыты: продажи можно вывести и в Grafana, технические метрики - в BI.
Вопрос скорее в том, для какой задачи создавался инструмент и какие операции с данными в нем делать удобно, а там и его быстродействие с отказостойкостью.
❤️ знаю, где какой дашборд лежит
😈 иксель закроет все три задачи, топ СУБД
#pm #product #словарик #bi #analytics #grafana
❤5👍2🙏2😈2
YT/YTsaurus: база данных на максималках?
В прошлом посте я свалил в один блок DWH, ClickHouse и YT. Разберемся, что из этого что.
YT (сейчас YTsaurus) - распределенная платформа для хранения и обработки больших объемов данных, изначально разработанная в Яндексе.
Если совсем упростить, обычная база отвечает на запрос: дай мне эти данные. YT решает задачу шире: где хранить огромный объем данных и как параллельно обработать его на множестве машин.
Внутри поэтому есть и хранение таблиц, и вычисления над ними. Например, аналитик может взять миллиарды событий пользователей, отфильтровать нужные, объединить с заказами и посчитать метрику.
Отсюда и связь с прошлым постом:
YT - платформа хранения и вычислений
DWH - концепция аналитического хранилища
ClickHouse - СУБД для быстрых аналитических запросов
BI - инструменты, через которые результаты анализа доходят до человека
Поэтому фраза «данные лежат в YT» вполне нормальна, но описывает только часть возможностей YT
А еще поверх YT можно встретить YQL, CHYT и другие способы добраться до данных - но это уже следующий уровень кроличьей норы.
❤️ работал с YT
😈 моя распределенная система - Excel с презами по папкам
#pm #product #словарик #yt #ytsaurus #data
В прошлом посте я свалил в один блок DWH, ClickHouse и YT. Разберемся, что из этого что.
YT (сейчас YTsaurus) - распределенная платформа для хранения и обработки больших объемов данных, изначально разработанная в Яндексе.
Если совсем упростить, обычная база отвечает на запрос: дай мне эти данные. YT решает задачу шире: где хранить огромный объем данных и как параллельно обработать его на множестве машин.
Внутри поэтому есть и хранение таблиц, и вычисления над ними. Например, аналитик может взять миллиарды событий пользователей, отфильтровать нужные, объединить с заказами и посчитать метрику.
Отсюда и связь с прошлым постом:
YT - платформа хранения и вычислений
DWH - концепция аналитического хранилища
ClickHouse - СУБД для быстрых аналитических запросов
BI - инструменты, через которые результаты анализа доходят до человека
Поэтому фраза «данные лежат в YT» вполне нормальна, но описывает только часть возможностей YT
А еще поверх YT можно встретить YQL, CHYT и другие способы добраться до данных - но это уже следующий уровень кроличьей норы.
❤️ работал с YT
😈 моя распределенная система - Excel с презами по папкам
#pm #product #словарик #yt #ytsaurus #data
❤4🔥3😈2👍1
S3: где приложение хранит файлы
Для меня S3 всегда звучал как техническое файловое хранилище. В целом это недалеко от истины.
S3 (Simple Storage Service) - сервис Amazon, который позволяет отделить хранение файлов от серверов самого приложения.
Он настолько популяризировал подход Object Storage, что сегодня многие другие хранилища поддерживают тот же S3 API и называются S3-compatible.
В S3 удобно хранить картинки, видео, документы, бэкапы и другие файлы приложения.
В итоге серверы можно менять и масштабировать, а файлы продолжают жить в отдельном хранилище, рассчитанном на большие объемы данных и высокую надежность.
При этом Object Storage подходит не для любых данных. Объекты удобно положить и забрать целиком, но это не лучший вариант для постоянного изменения маленьких частей данных или сложных запросов по их содержимому.
Кроме Object Storage существуют еще File Storage и Block Storage - это уже другие модели хранения под другие задачи.
❤️ знаю, где у продукта лежат картинки
😈 папка uploads на сервере надежнее
#pm #product #словарик #s3 #storage
Для меня S3 всегда звучал как техническое файловое хранилище. В целом это недалеко от истины.
S3 (Simple Storage Service) - сервис Amazon, который позволяет отделить хранение файлов от серверов самого приложения.
Он настолько популяризировал подход Object Storage, что сегодня многие другие хранилища поддерживают тот же S3 API и называются S3-compatible.
В S3 удобно хранить картинки, видео, документы, бэкапы и другие файлы приложения.
В итоге серверы можно менять и масштабировать, а файлы продолжают жить в отдельном хранилище, рассчитанном на большие объемы данных и высокую надежность.
При этом Object Storage подходит не для любых данных. Объекты удобно положить и забрать целиком, но это не лучший вариант для постоянного изменения маленьких частей данных или сложных запросов по их содержимому.
Кроме Object Storage существуют еще File Storage и Block Storage - это уже другие модели хранения под другие задачи.
❤️ знаю, где у продукта лежат картинки
😈 папка uploads на сервере надежнее
#pm #product #словарик #s3 #storage
❤5👍2🔥2
Сетапим задачи по-модному
Я перестал писать промпты руками. Почти..
В прошлом году смотрел первую конфу у Вани Замесина про вайбкодинг. Он тогда только погружался в вйбкодинг, но собрал ребят, которые уже напилили рабочие SaaSочки.
У меня был шок, когда на демо Сева Устинов или Харитон Матвеев показали, как дают команды голосом через SpeechKit. Я тогда сказал жене: "Посмотри, это же работа с Джарвисом, как у Тони Старка. Вот тебе будущее"
У меня оно наступило. Круто!)
Создаю новый диалог и надиктовываю весь поток мыслей: что хочу сделать, зачем, какой вижу план, что проверить.
Могу повторяться, перескакивать и менять решение по ходу.
Дальше прошу агента самому собрать из этого план решения, но не выполнять его сразу. Сначала он кратко пишет, как понял задачу, и задает вопросы, если чего-то не хватает.
Для меня это убрало проблему белого листа.
Не нужно одновременно думать, структурировать и писать. Сначала выгружаешь мысли, модель собирает структуру под моим контролем.
Вторая часть сетапа - контекст. Многое не нужно объяснять заново.
Я храню его в Obsidian, сами файлы лежат в GitLab.
При этом ответ от агента тоже прошу делать коротким
Мне не нужно читать заново весь контекст, который я и так знаю.
Достаточно плана верхнего уровня, чтобы заметить, если что-то потерялось.
По сути, весь мой сетап сейчас: голос + база контекста.
А какие вы используете приемы?
#pm #Obsidian #AIagents #продуктовыйменеджмент
Я перестал писать промпты руками. Почти..
В прошлом году смотрел первую конфу у Вани Замесина про вайбкодинг. Он тогда только погружался в вйбкодинг, но собрал ребят, которые уже напилили рабочие SaaSочки.
У меня был шок, когда на демо Сева Устинов или Харитон Матвеев показали, как дают команды голосом через SpeechKit. Я тогда сказал жене: "Посмотри, это же работа с Джарвисом, как у Тони Старка. Вот тебе будущее"
У меня оно наступило. Круто!)
Создаю новый диалог и надиктовываю весь поток мыслей: что хочу сделать, зачем, какой вижу план, что проверить.
Могу повторяться, перескакивать и менять решение по ходу.
Дальше прошу агента самому собрать из этого план решения, но не выполнять его сразу. Сначала он кратко пишет, как понял задачу, и задает вопросы, если чего-то не хватает.
Для меня это убрало проблему белого листа.
Не нужно одновременно думать, структурировать и писать. Сначала выгружаешь мысли, модель собирает структуру под моим контролем.
Вторая часть сетапа - контекст. Многое не нужно объяснять заново.
Я храню его в Obsidian, сами файлы лежат в GitLab.
При этом ответ от агента тоже прошу делать коротким
Мне не нужно читать заново весь контекст, который я и так знаю.
Достаточно плана верхнего уровня, чтобы заметить, если что-то потерялось.
По сути, весь мой сетап сейчас: голос + база контекста.
А какие вы используете приемы?
#pm #Obsidian #AIagents #продуктовыйменеджмент
🔥7❤3😎3
Cost of Delay: сколько стоит подождать
Дано:
В бэклоге две задачи
Обе - месяц разработки, стоят одинаково, риски и уверенность в оценке схожи
Первая может принести 3 млн рублей/год
Вторая - 500 тысяч
Какую берём первой?
.
.
.
Не все вводные были в условии.
Первая сохранит ценность и через месяц. А у второй открыто короткое окно возможностей:
- партнёр готов к интеграции сейчас
- HR-коммуникации могут включить запуск в ближайшую рассылку
- начался высокий сезон
Если не успеть сейчас, следующая возможность появится через квартал. Или не появится вообще.
Cost of Delay показывает, как быстро задача теряет ожидаемую ценность, пока лежит в бэклоге.
Сама задача не стала ценнее, просто её ценность может протухать
Поэтому при приоритизации стоит учитывать: Что останется от ценности, если подождать месяц?
❤️ знаю цену ожидания
😈 важная задача и в следующем квартале важная
#pm #product #приоритизация #costofdelay
Дано:
В бэклоге две задачи
Обе - месяц разработки, стоят одинаково, риски и уверенность в оценке схожи
Первая может принести 3 млн рублей/год
Вторая - 500 тысяч
Какую берём первой?
.
.
.
Не все вводные были в условии.
Первая сохранит ценность и через месяц. А у второй открыто короткое окно возможностей:
- партнёр готов к интеграции сейчас
- HR-коммуникации могут включить запуск в ближайшую рассылку
- начался высокий сезон
Если не успеть сейчас, следующая возможность появится через квартал. Или не появится вообще.
Cost of Delay показывает, как быстро задача теряет ожидаемую ценность, пока лежит в бэклоге.
Сама задача не стала ценнее, просто её ценность может протухать
Поэтому при приоритизации стоит учитывать: Что останется от ценности, если подождать месяц?
❤️ знаю цену ожидания
😈 важная задача и в следующем квартале важная
#pm #product #приоритизация #costofdelay
👍7❤5✍2
Мы всё считали в Hyundai Solaris
Когда в презентации написано "сэкономили много миллионов", бывает сложно воспринять результат.
Можно это решить проверкой бенчмарок по рынку, сравнением период к периоду, или....
Оценить в Hyundai Solaris
В Маркете у нас был жирный проект по оборотной таре. Делали его год. Смотрели, как он влияет на GMV, считали экономию и в какой-то момент начали переводить её в Hyundai Solaris.
Почему именно Solaris?
Один из руководителей разработки купил себе солярис, чем очень гордился, машина стала локальным мемом, а потом превратилась в единицу измерения
На внутренних синках результат становился понятнее. Его можно было запомнить, обсудить и объяснить человеку, который не сидел вместе с нами в таблицах, не знал бенчмарок.
Поэтому, чтоб тепло объяснить пользу работы, можно через эквивалент в чем-то понятном: корпоративы, подписки на кодекс, хёндаи...
Пока думал над этим постом, понял, что в быту у меня есть похожий подход:
Личные траты иногда перевожу в кружки кофе или походы в кафе.
Можно быстро понять, что это нормальная трата в кофе/ресторанах и не париться о потраченных деньгах.
А у вас есть своя единица измерения?
❤️ понимаю деньги через кофе
😈 всё считаю в сторипоинтах
@product_lev
#pm #productmanagement #ценность #мотивация #метрики
Когда в презентации написано "сэкономили много миллионов", бывает сложно воспринять результат.
Можно это решить проверкой бенчмарок по рынку, сравнением период к периоду, или....
Оценить в Hyundai Solaris
В Маркете у нас был жирный проект по оборотной таре. Делали его год. Смотрели, как он влияет на GMV, считали экономию и в какой-то момент начали переводить её в Hyundai Solaris.
Почему именно Solaris?
Один из руководителей разработки купил себе солярис, чем очень гордился, машина стала локальным мемом, а потом превратилась в единицу измерения
На внутренних синках результат становился понятнее. Его можно было запомнить, обсудить и объяснить человеку, который не сидел вместе с нами в таблицах, не знал бенчмарок.
Поэтому, чтоб тепло объяснить пользу работы, можно через эквивалент в чем-то понятном: корпоративы, подписки на кодекс, хёндаи...
Пока думал над этим постом, понял, что в быту у меня есть похожий подход:
Личные траты иногда перевожу в кружки кофе или походы в кафе.
Можно быстро понять, что это нормальная трата в кофе/ресторанах и не париться о потраченных деньгах.
А у вас есть своя единица измерения?
❤️ понимаю деньги через кофе
😈 всё считаю в сторипоинтах
@product_lev
#pm #productmanagement #ценность #мотивация #метрики
❤6👍5🔥5
Что почитать?
Нарративное лидерство, Артём Мушин-Македонский
Кому: тем, кому приходится убеждать, обучать и вести людей за собой
Оценка: 10 историй из 10
Отзыв:
В книжном клубе читали книгу после "Наш айсберг тает" Джона Коттера, поэтому я ждал больших управленческих речей, главного пингвина, чего-то вроде "I have a dream".
Но книга оказалась заметно прикладнее.
Нарратив здесь нужен не только для большой мотивационной речи: история помогает объяснить изменение, продать идею, обучить, провести коучинговый разговор.
А иногда с помощью истории можно просто уговорить ребёнка надеть шапку:)
Что забрал себе:
1) Нарратив - это управленческий инструмент, а не только красивые тексты
2) Начать применять его можно с простой истории о том, что хорошего произошло в компании
3) Истории особенно полезны в маркетинге, продажах, обучении и коучинге
4) История не всегда лучше прямой просьбы
5) ИИ уже неплохо помогает собрать структуру истории, но остаётся металлический привкус
Главная мысль для меня: продакт постоянно объясняет, почему сейчас нужно взяться именно за эту задачу, зачем менять процесс, или чего хорошего сделала команда. Можно ограничиться сухим фактом, а можно показать ситуацию, действие и результат с потенциалом изменить слушателя.
Часть 2. Как читали в клубе
Книгу обсудили вместе с автором! 💥
С Артёмом поговорили про Chief Story Officer - человека, который помогает распространять практику работы с нарративами по всей компании.
Галя(главный чтец) собрала скилл по инструкциям Артёма. Посмотрели, где заканчивается автоматизация и начинается человеческая интонация.
Если интересно читать не только про инструменты управления, но и про то, как люди понимают смысл и принимают решения, присоединяйтесь к нашему Книжному клубу для менеджеров.
#чтопочитать #книжныйклуб #управление #лидерство #нарратив #сторителлинг #productmanagement
Нарративное лидерство, Артём Мушин-Македонский
Кому: тем, кому приходится убеждать, обучать и вести людей за собой
Оценка: 10 историй из 10
Отзыв:
В книжном клубе читали книгу после "Наш айсберг тает" Джона Коттера, поэтому я ждал больших управленческих речей, главного пингвина, чего-то вроде "I have a dream".
Но книга оказалась заметно прикладнее.
Нарратив здесь нужен не только для большой мотивационной речи: история помогает объяснить изменение, продать идею, обучить, провести коучинговый разговор.
А иногда с помощью истории можно просто уговорить ребёнка надеть шапку:)
Что забрал себе:
1) Нарратив - это управленческий инструмент, а не только красивые тексты
2) Начать применять его можно с простой истории о том, что хорошего произошло в компании
3) Истории особенно полезны в маркетинге, продажах, обучении и коучинге
4) История не всегда лучше прямой просьбы
5) ИИ уже неплохо помогает собрать структуру истории, но остаётся металлический привкус
Главная мысль для меня: продакт постоянно объясняет, почему сейчас нужно взяться именно за эту задачу, зачем менять процесс, или чего хорошего сделала команда. Можно ограничиться сухим фактом, а можно показать ситуацию, действие и результат с потенциалом изменить слушателя.
Часть 2. Как читали в клубе
Книгу обсудили вместе с автором! 💥
С Артёмом поговорили про Chief Story Officer - человека, который помогает распространять практику работы с нарративами по всей компании.
Галя(главный чтец) собрала скилл по инструкциям Артёма. Посмотрели, где заканчивается автоматизация и начинается человеческая интонация.
Если интересно читать не только про инструменты управления, но и про то, как люди понимают смысл и принимают решения, присоединяйтесь к нашему Книжному клубу для менеджеров.
#чтопочитать #книжныйклуб #управление #лидерство #нарратив #сторителлинг #productmanagement
1❤4🔥3✍1👍1
Задача ушла, продукт остался
Когда я переходил из логистики в коммерцию в Яндексе, то полностью передавал продукт самовывоза новому менеджеру.
На переходный период я ещё ходил на статусные встречи: помогал войти в контекст и подсвечивал, если что-то выпадало. Потом она уже сама управляла бэклогом и приоритизацией.
В какой-то момент разработка начала принимать решения вместе с ней, не сверяясь со мной.
Для меня это был главный сигнал: продукт действительно передан.
С точки зрения теории делегирование - это передача не только действия, но и полномочий, необходимых для результата.
Можно делегировать:
- отдельную задачу
- участок работы
- целый продукт
В последнем случае нужно передать:
- контекст и ограничения
- таргет
- право принимать решения
- контрольные точки
Если человек только исполняет твой план, ты делегировал задачу. Если сам решает, что делать и почему - передал продукт.
В моём случае после короткого переходного периода продукт спокойно жил без меня.
А у вас чаще делегируют задачи или действительно отдают продукт?
❤️ отдаю продукт
😈 отдаю только задачи
@product_lev
#pm #productmanagement #управление #делегирование #команда
Когда я переходил из логистики в коммерцию в Яндексе, то полностью передавал продукт самовывоза новому менеджеру.
На переходный период я ещё ходил на статусные встречи: помогал войти в контекст и подсвечивал, если что-то выпадало. Потом она уже сама управляла бэклогом и приоритизацией.
В какой-то момент разработка начала принимать решения вместе с ней, не сверяясь со мной.
Для меня это был главный сигнал: продукт действительно передан.
С точки зрения теории делегирование - это передача не только действия, но и полномочий, необходимых для результата.
Можно делегировать:
- отдельную задачу
- участок работы
- целый продукт
В последнем случае нужно передать:
- контекст и ограничения
- таргет
- право принимать решения
- контрольные точки
Если человек только исполняет твой план, ты делегировал задачу. Если сам решает, что делать и почему - передал продукт.
В моём случае после короткого переходного периода продукт спокойно жил без меня.
А у вас чаще делегируют задачи или действительно отдают продукт?
❤️ отдаю продукт
😈 отдаю только задачи
@product_lev
#pm #productmanagement #управление #делегирование #команда
❤8👍3🤝2🔥1