Как растить продукт и клиента в нем?
В этом году я дважды публично рассказывал про расчет A-ha moment, до этого проходил Retention + Engagement Deep Dive от Reforge, ездил на мастер-класс North Star Metric от Amplitude. В целом, в последнее время меня волнует только один вопрос: на чем фокусировать продуктовую команду, чтобы продукт в любой момент времени приносил максимальную ценность клиенту.
Ответ на этот вопрос часто лежит на стыке нескольких дисциплин, команд и ролей.
С одной стороны, продуктовая команда, как правило, смотрит далеко вперед и стратегически развивает продукт. Наличие функционала, его связанность с другими фичами и общая работоспособность продукта это, как правило, основные задачи продуктовых команд.
С другой стороны, команда роста (если таковая есть) сильно зафокусирована на улучшении конверсий на пути пользования продукта клиентом. Здесь акцент смещен в стороны growth hacks, A/B-тестов и других подходов, которые позволяют расширить воронку.
При этом обе команды не всегда имеют время на то, чтобы остановиться на мгновение и подумать над следующим:
Многие компании сильно вкладываются в аналитику платного привлечения, чтобы, по возможности, (a) улучшить конверсии (b) уменьшить CAC (c) выйти на окупаемость рекламных каналов. Но очень быстро такие усилия упираются в потолок.
Unit economics это всегда про соотношение LTV / CAC, а значит, нравится нам это или нет, нам нужно углубиться в драйверы роста LTV. Чтобы клиент продолжал платить, очень важно определить за решение какой проблемы (за какую ценность) клиент платит вам деньги, зачем тратит на ваше решение свое время.
Чтобы это понять, обычно, нужно посмотреть, что клиент делал до оплаты, а также, что он делает с продуктом после. И здесь, по логике вещей, на сцену должна была бы выйти продуктовая аналитика. Но этого не происходит.
На мой взгляд проблема в следующем.
С одной стороны, часто продакты и/или аналитики рассматривают локальные проблемы: зарелизили фичу, запустили A/B-тест, посмотрели какой uplift это принесло. Таким образом идет оптимизация продукта, но не клиентского опыта. Клиент часто выпадет из этого уравнения.
С другой стороны, часто и сам продукт не рассматривается как элемент роста. Но, по-сути, продукт это такой же инструмент роста как и Google Ads или Email notifications. Ведь именно от такого как продукт решает проблему будет зависеть продолжит ли клиент пользоваться и платить за него, порекомендует его друзьям.
Т.о. в разные моменты времени нам нужно переходить на разные уровни понимания и детализации проблем то продукта, то клиента.
Как можно было бы решать вопрос по построению продукта и развитию клиента в нем?
На сейчас мне известно 3 разных фреймворка про то, как растить клиента в продукте, куда развивать продукт.
North Star Metric approach (Amplitude)
Этот фреймворк в значительной степени стратегический. Основной фокус: развитие продукта.
Он заставляет тебя определить одну метрику (North Star Metric), затем декомпозировать ее на суб-компоненты и разрабатывать функционал, который улучшает каждую из суб-компонент.
Retention + Engagement approach (Reforge)
Это фреймворк в значительной степени тактическо-стратегический. Основной фокус: развитие клиентской базы.
Он заставляет тебя определить X-moments, сформировать и управлять сегментами с разной степенью вовлеченности, определить циклы перехода от вовлеченного состояния в отстраненное и обратно, влиять на них.
User trajectories (Retentioneering)
Этот фреймворк в значительной степени тактический. Основной фокус: развитие клиента в продукте.
Он заставляет тебя определить события, которые будет генерировать клиент пользуясь продуктом, записывать их в хранилище, анализировать траектории движения пользователя с тем, чтобы находить и устранять узкие места.
Каждый фреймворк в отдельности отвечает четко лишь на часть вопросов.
И вот здесь у меня возник вопрос...
Можно ли объединить эти 3 фреймворка так, чтобы эффективно делать zoom in/out и единообразно управлять как развитием продукта так и развитием клиента?
Ответ на этот вопрос часто лежит на стыке нескольких дисциплин, команд и ролей.
С одной стороны, продуктовая команда, как правило, смотрит далеко вперед и стратегически развивает продукт. Наличие функционала, его связанность с другими фичами и общая работоспособность продукта это, как правило, основные задачи продуктовых команд.
С другой стороны, команда роста (если таковая есть) сильно зафокусирована на улучшении конверсий на пути пользования продукта клиентом. Здесь акцент смещен в стороны growth hacks, A/B-тестов и других подходов, которые позволяют расширить воронку.
При этом обе команды не всегда имеют время на то, чтобы остановиться на мгновение и подумать над следующим:
- какую 1-2 проблемы продукт решает в каждый момент времени,
- насколько продукт "говорит" на одном и том же языке с клиентом,
- какие альтернативы решения своей проблемы клиент оценивает "в реальной жизни",
- как клиент пользуется продуктом на самом деле.
Многие компании сильно вкладываются в аналитику платного привлечения, чтобы, по возможности, (a) улучшить конверсии (b) уменьшить CAC (c) выйти на окупаемость рекламных каналов. Но очень быстро такие усилия упираются в потолок.
Unit economics это всегда про соотношение LTV / CAC, а значит, нравится нам это или нет, нам нужно углубиться в драйверы роста LTV. Чтобы клиент продолжал платить, очень важно определить за решение какой проблемы (за какую ценность) клиент платит вам деньги, зачем тратит на ваше решение свое время.
Чтобы это понять, обычно, нужно посмотреть, что клиент делал до оплаты, а также, что он делает с продуктом после. И здесь, по логике вещей, на сцену должна была бы выйти продуктовая аналитика. Но этого не происходит.
На мой взгляд проблема в следующем.
С одной стороны, часто продакты и/или аналитики рассматривают локальные проблемы: зарелизили фичу, запустили A/B-тест, посмотрели какой uplift это принесло. Таким образом идет оптимизация продукта, но не клиентского опыта. Клиент часто выпадет из этого уравнения.
С другой стороны, часто и сам продукт не рассматривается как элемент роста. Но, по-сути, продукт это такой же инструмент роста как и Google Ads или Email notifications. Ведь именно от такого как продукт решает проблему будет зависеть продолжит ли клиент пользоваться и платить за него, порекомендует его друзьям.
Т.о. в разные моменты времени нам нужно переходить на разные уровни понимания и детализации проблем то продукта, то клиента.
Как можно было бы решать вопрос по построению продукта и развитию клиента в нем?
На сейчас мне известно 3 разных фреймворка про то, как растить клиента в продукте, куда развивать продукт.
- North Star Metric approach (Amplitude)
- Retention + Engagement approach (Reforge)
- User trajectories (Retentioneering)
 |
| North Star Metric approach (Amplitude). |
Этот фреймворк в значительной степени стратегический. Основной фокус: развитие продукта.
Он заставляет тебя определить одну метрику (North Star Metric), затем декомпозировать ее на суб-компоненты и разрабатывать функционал, который улучшает каждую из суб-компонент.
Retention + Engagement approach (Reforge)
 |
| Retention & Engagement approach (Reforge) |
Это фреймворк в значительной степени тактическо-стратегический. Основной фокус: развитие клиентской базы.
Он заставляет тебя определить X-moments, сформировать и управлять сегментами с разной степенью вовлеченности, определить циклы перехода от вовлеченного состояния в отстраненное и обратно, влиять на них.
User trajectories (Retentioneering)
Этот фреймворк в значительной степени тактический. Основной фокус: развитие клиента в продукте.
 |
| Users trajectories (Retentioneering). |
Он заставляет тебя определить события, которые будет генерировать клиент пользуясь продуктом, записывать их в хранилище, анализировать траектории движения пользователя с тем, чтобы находить и устранять узкие места.
Каждый фреймворк в отдельности отвечает четко лишь на часть вопросов.
И вот здесь у меня возник вопрос...
Можно ли объединить эти 3 фреймворка так, чтобы эффективно делать zoom in/out и единообразно управлять как развитием продукта так и развитием клиента?
Comments
С 1-м фреймворком сложнее через фокусировку на продукте. Тут наверное могут быть разные вариации в зависимости от типа продукта, так как по факту от качества продукта зависит структура сегментов.
Для таких вопросов наверное нужно какие-то брейнштормы устраивать, где будут люди с разными точками зрения и опытом.
Post a Comment