Как траблшутинг помогает решать проблемы продакт-менеджера?
В большинстве компаний проблемы диагностируют очень поверхностно. Упала конверсия - значит проблема в UX. Упали продажи - значит проблема в маркетинге. Пользователи жалуются - значит проблема в продукте. Но если посмотреть разборы крупных инцидентов в банках, маркетплейсах, финтехе и SaaS-компаниях, оказывается, что реальная причина почти всегда находится на один-два уровня глубже. Например, команда несколько месяцев улучшает онбординг из-за падения регистрации, а потом выясняется, что проблема появилась после изменения логики атрибуции рекламных каналов и пользователи никуда не исчезали. Просто аналитика начала считать их по-другому. Нужна помощь с ростом бизнеса и процессов? Пишите @SKoloskov или заполните короткую форму тут.
1. Один из самых полезных приемов в траблшутинге - искать не проблему, а первое место, где данные начинают отличаться от нормы. Допустим, выручка маркетплейса упала на 15%. Большинство команд начинают анализировать выручку. Сильные команды начинают раскручивать цепочку: количество заказов, количество покупателей, конверсия в покупку, добавления в корзину, просмотры карточек, поисковые запросы. Очень часто оказывается, что падение выручки началось не в оплате и не в корзине, а в поиске, где после обновления алгоритма пользователи стали хуже находить нужные товары. Внешне проблема выглядит как финансовая, а источник находится в совершенно другом месте продукта.
2. Еще одна распространенная ошибка - смотреть на средние показатели. Например, удержание пользователей снизилось с 35% до 30%. На первый взгляд проблема общая. Но когда начинается нормальный траблшутинг, выясняется, что удержание осталось прежним у всех старых пользователей и даже выросло у Android-аудитории. Просадка целиком создается новыми пользователями iPhone из одного рекламного канала. Половина продуктовых кризисов перестает быть кризисами после нормальной сегментации данных. Поэтому сильные продакты редко смотрят на общий показатель. Они почти всегда ищут сегмент, который создает проблему.
3. Отдельный класс проблем связан с так называемыми "ложными виновниками". Например, после релиза резко выросло количество ошибок. Все начинают искать проблему в коде последнего релиза. Через неделю выясняется, что реальная причина - партнерская интеграция, которая изменила формат данных. Или наоборот: команда месяц обвиняет внешних партнеров, а проблема оказывается в новом механизме кэширования. Поэтому хороший траблшутинг всегда начинается с карты изменений. Что поменялось в продукте, инфраструктуре, процессах, данных, маркетинге и внешних интеграциях за последние недели. Очень часто ответ находится именно там.
4. Есть интересное правило крупных продуктовых компаний: если причина кажется очевидной в первые 30 минут расследования, скорее всего она неверная. Потому что настоящие системные проблемы обычно возникают на стыке функций. Продажи обвиняют продукт, продукт обвиняет разработку, разработка обвиняет инфраструктуру, а проблема находится в процессе между ними. Например, одна команда отвечает за привлечение пользователей, другая за активацию, третья за удержание. Пока каждая смотрит только на свой участок, никто не видит полную картину.
Сильные продакты часто кажутся медленными в первые часы кризиса. Они не бегут сразу чинить. Они сначала ставят диагноз. А в продукте правильный диагноз обычно стоит намного дороже самого решения.
Нужна помощь с ростом бизнеса и процессов? Пишите @SKoloskov или заполните короткую форму тут.
Всем роста! Сайт команды с курсами и полезными материалами.
В большинстве компаний проблемы диагностируют очень поверхностно. Упала конверсия - значит проблема в UX. Упали продажи - значит проблема в маркетинге. Пользователи жалуются - значит проблема в продукте. Но если посмотреть разборы крупных инцидентов в банках, маркетплейсах, финтехе и SaaS-компаниях, оказывается, что реальная причина почти всегда находится на один-два уровня глубже. Например, команда несколько месяцев улучшает онбординг из-за падения регистрации, а потом выясняется, что проблема появилась после изменения логики атрибуции рекламных каналов и пользователи никуда не исчезали. Просто аналитика начала считать их по-другому. Нужна помощь с ростом бизнеса и процессов? Пишите @SKoloskov или заполните короткую форму тут.
1. Один из самых полезных приемов в траблшутинге - искать не проблему, а первое место, где данные начинают отличаться от нормы. Допустим, выручка маркетплейса упала на 15%. Большинство команд начинают анализировать выручку. Сильные команды начинают раскручивать цепочку: количество заказов, количество покупателей, конверсия в покупку, добавления в корзину, просмотры карточек, поисковые запросы. Очень часто оказывается, что падение выручки началось не в оплате и не в корзине, а в поиске, где после обновления алгоритма пользователи стали хуже находить нужные товары. Внешне проблема выглядит как финансовая, а источник находится в совершенно другом месте продукта.
2. Еще одна распространенная ошибка - смотреть на средние показатели. Например, удержание пользователей снизилось с 35% до 30%. На первый взгляд проблема общая. Но когда начинается нормальный траблшутинг, выясняется, что удержание осталось прежним у всех старых пользователей и даже выросло у Android-аудитории. Просадка целиком создается новыми пользователями iPhone из одного рекламного канала. Половина продуктовых кризисов перестает быть кризисами после нормальной сегментации данных. Поэтому сильные продакты редко смотрят на общий показатель. Они почти всегда ищут сегмент, который создает проблему.
3. Отдельный класс проблем связан с так называемыми "ложными виновниками". Например, после релиза резко выросло количество ошибок. Все начинают искать проблему в коде последнего релиза. Через неделю выясняется, что реальная причина - партнерская интеграция, которая изменила формат данных. Или наоборот: команда месяц обвиняет внешних партнеров, а проблема оказывается в новом механизме кэширования. Поэтому хороший траблшутинг всегда начинается с карты изменений. Что поменялось в продукте, инфраструктуре, процессах, данных, маркетинге и внешних интеграциях за последние недели. Очень часто ответ находится именно там.
4. Есть интересное правило крупных продуктовых компаний: если причина кажется очевидной в первые 30 минут расследования, скорее всего она неверная. Потому что настоящие системные проблемы обычно возникают на стыке функций. Продажи обвиняют продукт, продукт обвиняет разработку, разработка обвиняет инфраструктуру, а проблема находится в процессе между ними. Например, одна команда отвечает за привлечение пользователей, другая за активацию, третья за удержание. Пока каждая смотрит только на свой участок, никто не видит полную картину.
Сильные продакты часто кажутся медленными в первые часы кризиса. Они не бегут сразу чинить. Они сначала ставят диагноз. А в продукте правильный диагноз обычно стоит намного дороже самого решения.
Нужна помощь с ростом бизнеса и процессов? Пишите @SKoloskov или заполните короткую форму тут.
Всем роста! Сайт команды с курсами и полезными материалами.