Одиночка против команды
Ты построил продукт, юзеры регистрируются, показатели растут... А потом БАЦ – потолок. Всё застопорилось. Почему? Потому что ты сделал ставку только на одиночных пользователей и проигнорировал команды. Давайте посмотрим на рыночек.
B2B-софт давно перенял логику B2C: удобный интерфейс, быстрый онбординг, все максимально персонализировано. Но если ты работаешь по PLG модели, то 10 000 юзеров без команд — это тупик. Нужны корпоративные клиенты, которые платят не за одного пользователя, а за всю компанию. А значит, продукт должен вести людей от одиночного использования к командному взаимодействию.
Как исправить?
1. Сразу привлекай команды.
При регистрации — намёк на командную работу. В онбординге — предложение пригласить коллег. В продукте — фичи для совместной работы: шеринг, комментарии, доступы.
2. Поправь метрики.
Забудь про DAU/WAU, Смотри на WAT (активные команды):
— Новые команды: сколько пользователей превратились в группы?
— Командная активация: сколько работают вместе?
— Следи за ростом команд: расширяется ли использование?
3. Не трогай одиночек (ты как минимум на них рос).
Соло-юзер не должен чувствовать ограничения. Но он должен видеть плюсы от возможности поделиться аккаунтом. Показывай, намекай на ценность командной игры.
Кто уже это делает?
— Notion: начинали как персональный органайзер, но быстро добавили командные фишки: шеринг, роли, комментарии. Теперь продают корпам и сместили модель в B2B.
— Miro: в начале был инструмент для дизайнеров, теперь — лидер в коллаборации для команд. Живые курсоры, совместная работа — всё это привлекло корпоративных клиентов. Не так давно из-за санкций - ушли из страны, но форкнулись в holst.so (разрабы то русские).
— Slack: вся его суть в командной работе. Это не просто чат, а платформа для совместной коммуникации, где каждый новый участник делает инструмент полезнее для всех.
— Evernote: наоборот, слишком долго оставался "личным блокнотом". Командные функции добавили поздно и без глубокого продумывания. Они выглядели как запоздалое дополнение, а не как часть изначальной стратегии, из-за чего интеграция с рабочими процессами оказалась невнятной (от слова "вообще"). В итоге Notion его обогнал.
Если твой продукт становится ценнее с каждым новым пользователем в команде — ты победил. Это как тусовка, где каждый приносит что-то крутое, и чем больше людей, тем веселее.
Пример: в ESP (сервисы почтовых рассылок) один человек — может мало из-за 24 часов в сутках и двух лапках, но добавь ещё трёх — и начинается магия. Это же сразу воркшоп - один рассылает письма, второй работает с контактной базой, третий занят А/Б тестами или автоматизацией. Больше фич - больше возможностей распределить команду по ним.
К чему я?
Ставка только на одиночных пользователей = медленный рост и потолок. Хочешь заработать? Думай о командах.
Добавляй командные функции, стимулируй совместную работу, меряй WAT, а не WAU (ну или DAU, тут от параметра stickiness вашего продукта, насколько он необходим ежедневно или даже ежечасно).
Пожалуйста, не делай ещё один B2C, мимикрируя под B2B. Думай о команде — и ROI улетит ввысь.
Ты построил продукт, юзеры регистрируются, показатели растут... А потом БАЦ – потолок. Всё застопорилось. Почему? Потому что ты сделал ставку только на одиночных пользователей и проигнорировал команды. Давайте посмотрим на рыночек.
B2B-софт давно перенял логику B2C: удобный интерфейс, быстрый онбординг, все максимально персонализировано. Но если ты работаешь по PLG модели, то 10 000 юзеров без команд — это тупик. Нужны корпоративные клиенты, которые платят не за одного пользователя, а за всю компанию. А значит, продукт должен вести людей от одиночного использования к командному взаимодействию.
Как исправить?
1. Сразу привлекай команды.
При регистрации — намёк на командную работу. В онбординге — предложение пригласить коллег. В продукте — фичи для совместной работы: шеринг, комментарии, доступы.
2. Поправь метрики.
Забудь про DAU/WAU, Смотри на WAT (активные команды):
— Новые команды: сколько пользователей превратились в группы?
— Командная активация: сколько работают вместе?
— Следи за ростом команд: расширяется ли использование?
3. Не трогай одиночек (ты как минимум на них рос).
Соло-юзер не должен чувствовать ограничения. Но он должен видеть плюсы от возможности поделиться аккаунтом. Показывай, намекай на ценность командной игры.
Кто уже это делает?
— Notion: начинали как персональный органайзер, но быстро добавили командные фишки: шеринг, роли, комментарии. Теперь продают корпам и сместили модель в B2B.
— Miro: в начале был инструмент для дизайнеров, теперь — лидер в коллаборации для команд. Живые курсоры, совместная работа — всё это привлекло корпоративных клиентов. Не так давно из-за санкций - ушли из страны, но форкнулись в holst.so (разрабы то русские).
— Slack: вся его суть в командной работе. Это не просто чат, а платформа для совместной коммуникации, где каждый новый участник делает инструмент полезнее для всех.
— Evernote: наоборот, слишком долго оставался "личным блокнотом". Командные функции добавили поздно и без глубокого продумывания. Они выглядели как запоздалое дополнение, а не как часть изначальной стратегии, из-за чего интеграция с рабочими процессами оказалась невнятной (от слова "вообще"). В итоге Notion его обогнал.
Если твой продукт становится ценнее с каждым новым пользователем в команде — ты победил. Это как тусовка, где каждый приносит что-то крутое, и чем больше людей, тем веселее.
Пример: в ESP (сервисы почтовых рассылок) один человек — может мало из-за 24 часов в сутках и двух лапках, но добавь ещё трёх — и начинается магия. Это же сразу воркшоп - один рассылает письма, второй работает с контактной базой, третий занят А/Б тестами или автоматизацией. Больше фич - больше возможностей распределить команду по ним.
К чему я?
Ставка только на одиночных пользователей = медленный рост и потолок. Хочешь заработать? Думай о командах.
Добавляй командные функции, стимулируй совместную работу, меряй WAT, а не WAU (ну или DAU, тут от параметра stickiness вашего продукта, насколько он необходим ежедневно или даже ежечасно).
Пожалуйста, не делай ещё один B2C, мимикрируя под B2B. Думай о команде — и ROI улетит ввысь.
👍1
Поговорим про PLG
Product-Led Growth (PLG) - это когда продукт продает сам себя. Без агрессивных продаж, без тонн маркетинга. Пользователь заходит, пробует, понимает ценность и остается. Давай представим, что мы создаем сервис для хранения доступов сотрудников компании. Пока человек работает, у него есть доступ к сервису. Уволился - хранилище исчезло.
Как построить продукт по PLG? Начнем с фреймворков.
Первый - AARRR (или пиратские метрики, карамба!). Это метрики, которые помогут понять, на каком этапе проблемы. Мы смотрим, как пользователи узнают о продукте (Acquisition), насколько быстро получают ценность (Activation), возвращаются ли (Retention), платят ли (Revenue) и рекомендуют ли другим (Referral). В нашем случае важно сделать так, чтобы HR и IT-отдел моментально увидели пользу - например, наглядно представили, сколько уволенных сотрудников еще имеют доступы. Это может быть триггером к покупке.
Второй фреймворк - PLG Flywheel. Продукт должен работать по циклу: привлечь пользователей, быстро дать ценность, вовлечь их в процесс, а потом превратить их в адвокатов продукта. Что мы делаем? Даем бесплатную версию на 10 сотрудников. В IT-отделе пробуют, видят удобство (HR плачут от счастья, ведь выдаются доступы в пару кликов), подключают весь офис. Затем они увольняют кого-то и замечают, как сервис в один клик удаляет все доступы и закрывает сессии. Это их вау-момент, после которого они уже не хотят возвращаться к старому способу хранения паролей в таблицах или куче разных софтов.
Третий - Hook Model. Нужно создать привычку. Пусть сервис сам напоминает IT-отделу о возможных рисках: "Эти сотрудники уволены, но все еще имеют доступ". Это внутренний триггер - ощущение тревоги. IT-специалист делает действие - удаляет доступы. Видит награду - снижен риск утечек. Постепенно он начинает заходить в сервис каждый раз, когда кто-то увольняется. Аналогично HRы и остальной менеджмент.
Теперь про фичи. Тут пригодится модель Kano. Мы делим фичи на три группы. Базовые - без них продукт не работает (хранение доступов, автоматическое удаление). Ожидаемые - повышают удобство (интеграция с HRM-системами). Вау-фичи - делают продукт особенным (график безопасности с прогнозами, кто может представлять угрозу).
Так мы получаем продукт, который быстро решает боль пользователя, создает привычку и сам распространяется по компаниям. Это и есть PLG в чистом виде.
Когда-то я делал DigitalKeep, закрывающий потребность аутсорс-разработки в выдаче и хранении сотен админок от клиентских сайтов, SSH, PMA и т.д. И даже продал проект одной студии как внутренний инструмент, но по какой-то причине не пошел дальше. Подобные хранилища тогда были в основном в финтехе (и сейчас есть, конечно) - но это слишком энтерпрайзно и сложно, а я пытался закрыть потребности попроще.
Может быть что-то подобное уже существует, но мы не об этом - мы тут о моделях.
Product-Led Growth (PLG) - это когда продукт продает сам себя. Без агрессивных продаж, без тонн маркетинга. Пользователь заходит, пробует, понимает ценность и остается. Давай представим, что мы создаем сервис для хранения доступов сотрудников компании. Пока человек работает, у него есть доступ к сервису. Уволился - хранилище исчезло.
Как построить продукт по PLG? Начнем с фреймворков.
Первый - AARRR (или пиратские метрики, карамба!). Это метрики, которые помогут понять, на каком этапе проблемы. Мы смотрим, как пользователи узнают о продукте (Acquisition), насколько быстро получают ценность (Activation), возвращаются ли (Retention), платят ли (Revenue) и рекомендуют ли другим (Referral). В нашем случае важно сделать так, чтобы HR и IT-отдел моментально увидели пользу - например, наглядно представили, сколько уволенных сотрудников еще имеют доступы. Это может быть триггером к покупке.
Второй фреймворк - PLG Flywheel. Продукт должен работать по циклу: привлечь пользователей, быстро дать ценность, вовлечь их в процесс, а потом превратить их в адвокатов продукта. Что мы делаем? Даем бесплатную версию на 10 сотрудников. В IT-отделе пробуют, видят удобство (HR плачут от счастья, ведь выдаются доступы в пару кликов), подключают весь офис. Затем они увольняют кого-то и замечают, как сервис в один клик удаляет все доступы и закрывает сессии. Это их вау-момент, после которого они уже не хотят возвращаться к старому способу хранения паролей в таблицах или куче разных софтов.
Третий - Hook Model. Нужно создать привычку. Пусть сервис сам напоминает IT-отделу о возможных рисках: "Эти сотрудники уволены, но все еще имеют доступ". Это внутренний триггер - ощущение тревоги. IT-специалист делает действие - удаляет доступы. Видит награду - снижен риск утечек. Постепенно он начинает заходить в сервис каждый раз, когда кто-то увольняется. Аналогично HRы и остальной менеджмент.
Теперь про фичи. Тут пригодится модель Kano. Мы делим фичи на три группы. Базовые - без них продукт не работает (хранение доступов, автоматическое удаление). Ожидаемые - повышают удобство (интеграция с HRM-системами). Вау-фичи - делают продукт особенным (график безопасности с прогнозами, кто может представлять угрозу).
Так мы получаем продукт, который быстро решает боль пользователя, создает привычку и сам распространяется по компаниям. Это и есть PLG в чистом виде.
Когда-то я делал DigitalKeep, закрывающий потребность аутсорс-разработки в выдаче и хранении сотен админок от клиентских сайтов, SSH, PMA и т.д. И даже продал проект одной студии как внутренний инструмент, но по какой-то причине не пошел дальше. Подобные хранилища тогда были в основном в финтехе (и сейчас есть, конечно) - но это слишком энтерпрайзно и сложно, а я пытался закрыть потребности попроще.
Может быть что-то подобное уже существует, но мы не об этом - мы тут о моделях.
У нас в компании одну тему зацепили, так что давайте поговорим о программах лояльности и удержании подписчиков (ну вот это вот про LTV-UP и прочее).
В целом на рынке механика беспрерывных подписок простая: скидка за период. Плати вперед – получай дешевле. Но у меня есть еще:
— Предупреждающий страх – Вводим систему бонусов за неразрыв в платежах. При попытке отключить автоплатеж система грозно заявляет, что все бенефиты сгорят. Нормально работает, кстати. Можно облегчить в виде: вы хотя бы просто на "Лайт" временно переключитесь, тогда и бонусы сохраним, и платить меньше будете.
— Рефералка – Ну тут классика, приведи друга, получи звездочки, которыми можно оплатить подписку. Условно "бесплатно", но сервису выгодно.
— Геймификация – Регулярные подписчики участвуют в розыгрышах и получают эксклюзивные плюшки. В духе «останешься – может, айфончик перепадёт». Все это громко анонсируем во всех дайджестах и соцсетях.
— Бонус за верность – Раньше встречалось чаще: «9 месяцев без перерывов – 10-й в подарок». Сейчас редкость, но концепция все еще рабочая.
— Благотворительность – Скидки для НКО, а в промо обязательно пишем «помогаем тиграм». Вот кто не любит тигров?
Варианты «давайте спрячем кнопку отмены» или «юридически запрем в подписке» – то такое. Будем честными — выиграем все.
В целом на рынке механика беспрерывных подписок простая: скидка за период. Плати вперед – получай дешевле. Но у меня есть еще:
— Предупреждающий страх – Вводим систему бонусов за неразрыв в платежах. При попытке отключить автоплатеж система грозно заявляет, что все бенефиты сгорят. Нормально работает, кстати. Можно облегчить в виде: вы хотя бы просто на "Лайт" временно переключитесь, тогда и бонусы сохраним, и платить меньше будете.
— Рефералка – Ну тут классика, приведи друга, получи звездочки, которыми можно оплатить подписку. Условно "бесплатно", но сервису выгодно.
— Геймификация – Регулярные подписчики участвуют в розыгрышах и получают эксклюзивные плюшки. В духе «останешься – может, айфончик перепадёт». Все это громко анонсируем во всех дайджестах и соцсетях.
— Бонус за верность – Раньше встречалось чаще: «9 месяцев без перерывов – 10-й в подарок». Сейчас редкость, но концепция все еще рабочая.
— Благотворительность – Скидки для НКО, а в промо обязательно пишем «помогаем тиграм». Вот кто не любит тигров?
Варианты «давайте спрячем кнопку отмены» или «юридически запрем в подписке» – то такое. Будем честными — выиграем все.
❤1
Небольшая заметка о ресерче, а конкретнее о матрице знаний.
Вообще, исходная форма называлась "матрица Рамсфелда" (бывший мин.обороны США), можете почитать, на английском это "Knowledge Quadrant". Давайте поговорим про эту концепцию применив к продуктам.
Начиная какой-либо продукт ты всегда начинаешь с анализа рынка/ниши/инструментов/конкурентов и далее по списку. Матрица может помочь устранить неопределенности или задать правильные вопросы, чтобы донести до клиента ценность. Тут нужно помнить, что продукт он про "ценность", а не про фичи или их количество.
Неизвестное и казалось бы "известное" - это твое отражение внутреннего опыта как специалиста, но не стоит путать это с предвзятостью - именно по этой причине матрицу нужно собирать полностью. Вопросы помогут поставить цели, факты опираются на данные, а интуиция должна дать направление, но не стать основной решения.
Неизвестное-неизвестное - это уже про стратегическую сторону продуктового менеджмента. В процессе диалогов с клиентами, анализе рынков вы можете делать для себя открытия или подмечать инсайты, которые через новую призму неожиданно могут закрыть потребность пользователя. ВСЕ открытия рождаются через исследования, гипотезы и эксперименты.
Управление продуктом - это ровно про закрытие областей неизвестного создавая эффективные решения для пользователей, одновременно поддерживая и развивая бизнес.
Старайтесь помнить про баланс - вы получаете бизнес-ценность только тогда, когда решаете "ценность" клиента.
Вообще, исходная форма называлась "матрица Рамсфелда" (бывший мин.обороны США), можете почитать, на английском это "Knowledge Quadrant". Давайте поговорим про эту концепцию применив к продуктам.
Начиная какой-либо продукт ты всегда начинаешь с анализа рынка/ниши/инструментов/конкурентов и далее по списку. Матрица может помочь устранить неопределенности или задать правильные вопросы, чтобы донести до клиента ценность. Тут нужно помнить, что продукт он про "ценность", а не про фичи или их количество.
Неизвестное и казалось бы "известное" - это твое отражение внутреннего опыта как специалиста, но не стоит путать это с предвзятостью - именно по этой причине матрицу нужно собирать полностью. Вопросы помогут поставить цели, факты опираются на данные, а интуиция должна дать направление, но не стать основной решения.
Неизвестное-неизвестное - это уже про стратегическую сторону продуктового менеджмента. В процессе диалогов с клиентами, анализе рынков вы можете делать для себя открытия или подмечать инсайты, которые через новую призму неожиданно могут закрыть потребность пользователя. ВСЕ открытия рождаются через исследования, гипотезы и эксперименты.
Управление продуктом - это ровно про закрытие областей неизвестного создавая эффективные решения для пользователей, одновременно поддерживая и развивая бизнес.
Старайтесь помнить про баланс - вы получаете бизнес-ценность только тогда, когда решаете "ценность" клиента.
Давно не писал: погружался в ИИ-агентов и запускал новый продукт. Но хочу поделиться наблюдением про интерфейсы будущего.
Мой эскиз для ESP SaaS подтвердился: экраны поделятся на 2 или 3 части. Слева — ассистент в виде сайдбара (сворачиваемый, но всегда рядом). По центру — настройки и детали задачи. Справа — результат или предпросмотр.
Зачем? Во-первых, прозрачность: пользователь видит, что делает агент, и доверяет процессу. Во-вторых, это привычный флоу слева направо: помощь → настройка → результат. Это даже когнитивно проще, потому что роли не смешиваются. Есть место для диалога, есть зона для параметров, есть поле итога.
Такую схему уже подтверждают практики в продуктах. OpenAI Operator, Copilot в Microsoft 365, IDE с Copilot Chat — все идут к модели «чат + рабочая область». Reforge (очень рекомендую их подписку) пишет, что именно встроенные ассистенты повышают вовлеченность и удержание, потому что контекст помощи всегда под рукой.
Интерфейсы с маленьким чат-виджетом в углу скоро будут восприниматься архаикой.
Будущее — за полноценной интеграцией ИИ прямо в рабочее пространство, с выделенной колонкой и четкой ролью. Если хотите - у каждого пользователя в СааСах появится личный ассистент.
Главный оппонент подобного подхода - появляющиеся ИИ-агенты как плагины для браузеров, или даже сторонний софт на ПК. Единственный шанс отстройки - это сделать собственных секретарей умнее, скормив им в виде моделей инсайды и страшные внутренние секретные тайны о своем продукте.
Мой эскиз для ESP SaaS подтвердился: экраны поделятся на 2 или 3 части. Слева — ассистент в виде сайдбара (сворачиваемый, но всегда рядом). По центру — настройки и детали задачи. Справа — результат или предпросмотр.
Зачем? Во-первых, прозрачность: пользователь видит, что делает агент, и доверяет процессу. Во-вторых, это привычный флоу слева направо: помощь → настройка → результат. Это даже когнитивно проще, потому что роли не смешиваются. Есть место для диалога, есть зона для параметров, есть поле итога.
Такую схему уже подтверждают практики в продуктах. OpenAI Operator, Copilot в Microsoft 365, IDE с Copilot Chat — все идут к модели «чат + рабочая область». Reforge (очень рекомендую их подписку) пишет, что именно встроенные ассистенты повышают вовлеченность и удержание, потому что контекст помощи всегда под рукой.
Интерфейсы с маленьким чат-виджетом в углу скоро будут восприниматься архаикой.
Будущее — за полноценной интеграцией ИИ прямо в рабочее пространство, с выделенной колонкой и четкой ролью. Если хотите - у каждого пользователя в СааСах появится личный ассистент.
Главный оппонент подобного подхода - появляющиеся ИИ-агенты как плагины для браузеров, или даже сторонний софт на ПК. Единственный шанс отстройки - это сделать собственных секретарей умнее, скормив им в виде моделей инсайды и страшные внутренние секретные тайны о своем продукте.
Активация как основа роста продукта
Иногда ловлю себя на мысли, что мы (продакты), слишком легко соглашаемся решать задачи роста "по верхам". Увидели просадку в выручке — думаем о скидках и новых пакетах. Увидели отток — пытаемся чинить ретеншн или запускаем очередную программу лояльности. Логика кажется правильной: чинить там, где болит. Но опыт показывает, что метрика роста — это активация пользователя.
О чем я? Активация — это тот самый момент, когда новый пользователь впервые чувствует ценность продукта. До этой точки все наши маркетинговые усилия бессмысленны: мы заливаем людей в систему, но они не понимают, зачем им оставаться (и тогда никакие скидки, пуши и рефералки не помогут).
Конечно же все это из личного опыта - мы много времени тратили на оптимизацию цен и тарифов, увеличение среднего чека. Но стоило чуть глубже копнуть онбординг и довести больший процент новых юзеров до первой реальной ценности при помощи продуктовых туров — метрики ожили. LTV и ретеншн вырос сам собой. Маркетинговый бюджет стал работать эффективнее: пользователи начали задерживаться и платить чаще.
Ранее я понимал активацию как важный этап, но не как стратегический приоритет, а теперь понимаю, что это ключевая точка роста. Если активация не выстроена, рост превращается в иллюзию. Мы гоним пользователей в продукт, а они уходят так же быстро, как пришли.
Команды, кстати, часто делают наоборот, т.е. они ставят перед собой цель «поднять монетизацию» или «улучшить удержание», не трогая базовую проблему. В результате бесконечные эксперименты оказываются "чопиками" в дырявой трубе. Это, кстати, напрямую влияет на то, как формировать "рост-команды". Если в компании появляется возможность собрать отдельный спецотряд для экспериментов, то в первую очередь решаем вопрос активации. Каждый процент улучшения здесь мультиплицируется по всей воронке: больше людей дойдут до ценности > больше вернутся завтра > больше купят через месяц.
Как понять, что активация хромает? Это сильный разрыв между регистрациями и активными пользователями в рамках пары дней. Значит, люди приходят, но ценность не получают. В этом случае часто не проблема в маркетинге, а в том, что продукт не встречает новых пользователей правильно.
При работе с Нотифлоу я понимаю, что работа с активацией должна быть постоянной. Это не "сделали онбординг и забили про него". У продукта всегда появляются новые фичи, меняется аудитория, меняются ожидания пользователей. Это рутинная, но охренительно стратегическая работа.
Очень сложно убеждать команду, и не выжечь ее при этом, снова и снова пересобирать первые флоу. Но именно это приносит максимальный возврат.
Активация - это та точка, где любой вложенный час и рубль имеют наибольший мультипликатор в последствии.
Иногда ловлю себя на мысли, что мы (продакты), слишком легко соглашаемся решать задачи роста "по верхам". Увидели просадку в выручке — думаем о скидках и новых пакетах. Увидели отток — пытаемся чинить ретеншн или запускаем очередную программу лояльности. Логика кажется правильной: чинить там, где болит. Но опыт показывает, что метрика роста — это активация пользователя.
О чем я? Активация — это тот самый момент, когда новый пользователь впервые чувствует ценность продукта. До этой точки все наши маркетинговые усилия бессмысленны: мы заливаем людей в систему, но они не понимают, зачем им оставаться (и тогда никакие скидки, пуши и рефералки не помогут).
Конечно же все это из личного опыта - мы много времени тратили на оптимизацию цен и тарифов, увеличение среднего чека. Но стоило чуть глубже копнуть онбординг и довести больший процент новых юзеров до первой реальной ценности при помощи продуктовых туров — метрики ожили. LTV и ретеншн вырос сам собой. Маркетинговый бюджет стал работать эффективнее: пользователи начали задерживаться и платить чаще.
Ранее я понимал активацию как важный этап, но не как стратегический приоритет, а теперь понимаю, что это ключевая точка роста. Если активация не выстроена, рост превращается в иллюзию. Мы гоним пользователей в продукт, а они уходят так же быстро, как пришли.
Команды, кстати, часто делают наоборот, т.е. они ставят перед собой цель «поднять монетизацию» или «улучшить удержание», не трогая базовую проблему. В результате бесконечные эксперименты оказываются "чопиками" в дырявой трубе. Это, кстати, напрямую влияет на то, как формировать "рост-команды". Если в компании появляется возможность собрать отдельный спецотряд для экспериментов, то в первую очередь решаем вопрос активации. Каждый процент улучшения здесь мультиплицируется по всей воронке: больше людей дойдут до ценности > больше вернутся завтра > больше купят через месяц.
Как понять, что активация хромает? Это сильный разрыв между регистрациями и активными пользователями в рамках пары дней. Значит, люди приходят, но ценность не получают. В этом случае часто не проблема в маркетинге, а в том, что продукт не встречает новых пользователей правильно.
При работе с Нотифлоу я понимаю, что работа с активацией должна быть постоянной. Это не "сделали онбординг и забили про него". У продукта всегда появляются новые фичи, меняется аудитория, меняются ожидания пользователей. Это рутинная, но охренительно стратегическая работа.
Очень сложно убеждать команду, и не выжечь ее при этом, снова и снова пересобирать первые флоу. Но именно это приносит максимальный возврат.
Активация - это та точка, где любой вложенный час и рубль имеют наибольший мультипликатор в последствии.
Пользователи "гигантов" рынка
New MRR - ложная метрика на зрелом рынке, где фокус на прирост новых подписок создает стратегическую иллюзию. Рынок уже структурирован, основные игроки заняли позиции, и единственный источник устойчивого роста - это миграция пользователей из других продуктов. Все пути привлечения должны быть калиброваны под логику "забери у конкурента", а не под расширение рынка, которого просто нет.
Самая частая проблема продуктов - отсутствие нативных интеграций для импорта от этих самых игроков (ну или смежных CRM, как хранилищ лидов). И это не техдолг, а стратегический барьер. Пока вы оперируете только загрузками .csv, то миграция из Bitrix, AmoCRM и т.д. остается процессом, требующим ручного труда, что убивает вероятность конверсии потенциальных "перебежчиков". При этом наличие API - это не продукт-фича, а базовое условие для любого продукта. И это самое наличие не решает вопрос выше: нужно дать удобный UI инструмент любому рядовому пользователю.
А что делать?
Как вариант - перейти от New MRR расчетов к трем прогнозам. Большим продуктам вместо учета New MRR лучше фокусироваться на трех драйверах:
1) Увеличение ARPU за счет миграции текущей базы на планы повыше (апгрейд подписки)
2) Ретеншн MRR - удержание и понижение churn-а существующей подписки (держим текущую стабильную прибыль)
3) Миграционный MRR - перетягивание базы конкурентов. И тут в игру вступает маховик flywheel: реализуем интеграции (Bitrix, AmoCRM) → облегчаем миграцию (снижаем трение на переходе) → забираем "чужих" клиентов → они рекомендуют нас в своих экосистемах → еще больше клиентов переходит от конкурентов → замыкаем в цикл (то самое колесо). На каждом звене цикла нужна аналитика, быстрые итерации и постоянный диалог с переходящими клиентами.
Это позволяет маркетингу и продукту (которые так себе дружат, как правило) синхронизировать усилия вокруг понятного портрета и избежать распыления на новые или устаревшие каналы, где в условиях зрелого рынка много "мимокрокодильного" трафика.
New MRR - ложная метрика на зрелом рынке, где фокус на прирост новых подписок создает стратегическую иллюзию. Рынок уже структурирован, основные игроки заняли позиции, и единственный источник устойчивого роста - это миграция пользователей из других продуктов. Все пути привлечения должны быть калиброваны под логику "забери у конкурента", а не под расширение рынка, которого просто нет.
Самая частая проблема продуктов - отсутствие нативных интеграций для импорта от этих самых игроков (ну или смежных CRM, как хранилищ лидов). И это не техдолг, а стратегический барьер. Пока вы оперируете только загрузками .csv, то миграция из Bitrix, AmoCRM и т.д. остается процессом, требующим ручного труда, что убивает вероятность конверсии потенциальных "перебежчиков". При этом наличие API - это не продукт-фича, а базовое условие для любого продукта. И это самое наличие не решает вопрос выше: нужно дать удобный UI инструмент любому рядовому пользователю.
А что делать?
Как вариант - перейти от New MRR расчетов к трем прогнозам. Большим продуктам вместо учета New MRR лучше фокусироваться на трех драйверах:
1) Увеличение ARPU за счет миграции текущей базы на планы повыше (апгрейд подписки)
2) Ретеншн MRR - удержание и понижение churn-а существующей подписки (держим текущую стабильную прибыль)
3) Миграционный MRR - перетягивание базы конкурентов. И тут в игру вступает маховик flywheel: реализуем интеграции (Bitrix, AmoCRM) → облегчаем миграцию (снижаем трение на переходе) → забираем "чужих" клиентов → они рекомендуют нас в своих экосистемах → еще больше клиентов переходит от конкурентов → замыкаем в цикл (то самое колесо). На каждом звене цикла нужна аналитика, быстрые итерации и постоянный диалог с переходящими клиентами.
Это позволяет маркетингу и продукту (которые так себе дружат, как правило) синхронизировать усилия вокруг понятного портрета и избежать распыления на новые или устаревшие каналы, где в условиях зрелого рынка много "мимокрокодильного" трафика.
Кривая выживания
Интересный способ прогнозировать потери выручки - через кривую выживания клиентов.
У меня есть исторические данные по клиентам: средний срок жизни - 17 месяцев, минимум - 9, максимум - 26. Хотел понять, сколько пользователей и какой объём месячной выручки естественным образом уйдёт в 2026 году. Просто взять средний чек и умножить? Нет, это слишком грубо. Вместо этого я разбил всех клиентов по когортам (по месяцам подключения) и посмотрел, сколько из них доживают до ключевых точек - 9-го, 17-го и 26-го месяца.
Получилось, что можно спрогнозировать точные даты оттока: вот в марте 2026-го уйдут (могут уйти) те, кто подключился год назад и чей срок как раз истекает. Тут я могу понять, когда именно выручки станет меньше по календарю.
Кривая выживания на практике
Представьте график: по горизонтали - линия времени, по вертикали - исходное кол-во пользователей. На старте юзеров у нас 100% (все у кого 9, 17 и 26 месяцев выпадут на 2026), потом каждый месяц линия ползёт вниз. К 9-му месяцу жизни аккаунта остаётся, допустим, 60%; к 17-му 30%; к 26-му 5%. Из кривой я вытаскиваю прогноз: для когорты из января 2025-го в апреле 2026-го (через 15 месяцев) уйдёт ровно столько, сколько исторически не доживает до этого срока. Умножаю на их текущую месячную выручку - и вижу точную сумму потерь.
А зачем оно надо продукту?
Потому что теперь вы можете предусмотреть "смерть". Теперь вместо расплывчатого «чёрн прогноза» у меня есть план: в январе 2026-го готовимся потерять 15% выручки от когорты 2024-го, потому что у них срок как раз подходит. Нужно заранее запустить удержание - персональные письма, скидки на продление, анализ причин ухода именно в эти месяцы. Вообще процесс "лечения смертельно больных" должен быть отполирован до идеала.
В общем, простой инструмент - пользуйтесь. Положите в дорожную карту маркетинга - пусть все эти "отделы Заботы" окутывают зону риска заранее.
Upd. Кстати, усилия приложенные в этом году - дадут положительный эффект на пару лет вперед.
Интересный способ прогнозировать потери выручки - через кривую выживания клиентов.
У меня есть исторические данные по клиентам: средний срок жизни - 17 месяцев, минимум - 9, максимум - 26. Хотел понять, сколько пользователей и какой объём месячной выручки естественным образом уйдёт в 2026 году. Просто взять средний чек и умножить? Нет, это слишком грубо. Вместо этого я разбил всех клиентов по когортам (по месяцам подключения) и посмотрел, сколько из них доживают до ключевых точек - 9-го, 17-го и 26-го месяца.
Получилось, что можно спрогнозировать точные даты оттока: вот в марте 2026-го уйдут (могут уйти) те, кто подключился год назад и чей срок как раз истекает. Тут я могу понять, когда именно выручки станет меньше по календарю.
Кривая выживания на практике
Представьте график: по горизонтали - линия времени, по вертикали - исходное кол-во пользователей. На старте юзеров у нас 100% (все у кого 9, 17 и 26 месяцев выпадут на 2026), потом каждый месяц линия ползёт вниз. К 9-му месяцу жизни аккаунта остаётся, допустим, 60%; к 17-му 30%; к 26-му 5%. Из кривой я вытаскиваю прогноз: для когорты из января 2025-го в апреле 2026-го (через 15 месяцев) уйдёт ровно столько, сколько исторически не доживает до этого срока. Умножаю на их текущую месячную выручку - и вижу точную сумму потерь.
А зачем оно надо продукту?
Потому что теперь вы можете предусмотреть "смерть". Теперь вместо расплывчатого «чёрн прогноза» у меня есть план: в январе 2026-го готовимся потерять 15% выручки от когорты 2024-го, потому что у них срок как раз подходит. Нужно заранее запустить удержание - персональные письма, скидки на продление, анализ причин ухода именно в эти месяцы. Вообще процесс "лечения смертельно больных" должен быть отполирован до идеала.
В общем, простой инструмент - пользуйтесь. Положите в дорожную карту маркетинга - пусть все эти "отделы Заботы" окутывают зону риска заранее.
Upd. Кстати, усилия приложенные в этом году - дадут положительный эффект на пару лет вперед.
Как поменяется продуктовая работа в будущем
Если коротко - продакт станет ближе к product creator: меньше согласований ради согласований, больше быстрых прототипов, черновых спецификаций, тест-кейсов и сценариев, которые можно быстро показать пользователю или команде. Правда это еще и рост ответственности: у AI-фич много рисков (качество, доверие, данные), и продакт должен уметь их заранее видеть и оформлять в решения, а не "передавать ниже".
Но главный поворот в том, что ИИ не делает команду автоматически сильнее - он усиливает то, что уже есть. Очень корректное суждение - это AI is an amplifier: если у вас нормальный CI, тесты и дисциплина - станет быстрее; если хаос - станет быстрее ломаться.
Выводы из процессов и общения с СТО и техническими командами:
1) ИИ - это ускоритель цикла discovery/delivery: быстрее проверить гипотезу и собрать артефакты, но не гарантия лучшего результата без процесса.
2) Docs-as-code - естественная база для работы с агентами: markdown в git, PR-ревью, автосборка, понятная история изменений.
3) Процессы становятся важнее "выбора модели": тесты, CI, правила по данным, метрики качества - иначе вы увеличите техдолг.
4) Риски (приватность, ретеншн, комплаенс, утечки) нужно проектировать заранее и фиксировать в политиках, а не обсуждать постфактум.
На практике это означает переход от "чатик для идей" сразу к валидации гипотез: агент пишет через PR, запускает проверки, помогает ревью, а человек утверждает риски и финальную поставку.
Именно этим уже активно занимается разработка, а я в свою очередь активно обучаюсь новым подходам через Claude/Cursor. В частности - изучаю их модель работы с продуктовой документацией в Git, а не по старинке в Confluence etc. Эффект ускорения на уровне задач у ассистентов подтверждается экспериментами (например, с Copilot), но выигрыш в продуктовых метриках появляется только при правильных guardrails и измерении качества.
Помимо эффекта от хранения контекста и работы с ним для агента, ты получаешь прямой инструмент к быстрой генерации любых отчетов, графиков, презентаций и всего чего угодно, потому что markdown превратить в HTML (и даже красивый) - теперь стоит пару кликов и двух команд.
Если коротко - продакт станет ближе к product creator: меньше согласований ради согласований, больше быстрых прототипов, черновых спецификаций, тест-кейсов и сценариев, которые можно быстро показать пользователю или команде. Правда это еще и рост ответственности: у AI-фич много рисков (качество, доверие, данные), и продакт должен уметь их заранее видеть и оформлять в решения, а не "передавать ниже".
Но главный поворот в том, что ИИ не делает команду автоматически сильнее - он усиливает то, что уже есть. Очень корректное суждение - это AI is an amplifier: если у вас нормальный CI, тесты и дисциплина - станет быстрее; если хаос - станет быстрее ломаться.
Выводы из процессов и общения с СТО и техническими командами:
1) ИИ - это ускоритель цикла discovery/delivery: быстрее проверить гипотезу и собрать артефакты, но не гарантия лучшего результата без процесса.
2) Docs-as-code - естественная база для работы с агентами: markdown в git, PR-ревью, автосборка, понятная история изменений.
3) Процессы становятся важнее "выбора модели": тесты, CI, правила по данным, метрики качества - иначе вы увеличите техдолг.
4) Риски (приватность, ретеншн, комплаенс, утечки) нужно проектировать заранее и фиксировать в политиках, а не обсуждать постфактум.
На практике это означает переход от "чатик для идей" сразу к валидации гипотез: агент пишет через PR, запускает проверки, помогает ревью, а человек утверждает риски и финальную поставку.
Именно этим уже активно занимается разработка, а я в свою очередь активно обучаюсь новым подходам через Claude/Cursor. В частности - изучаю их модель работы с продуктовой документацией в Git, а не по старинке в Confluence etc. Эффект ускорения на уровне задач у ассистентов подтверждается экспериментами (например, с Copilot), но выигрыш в продуктовых метриках появляется только при правильных guardrails и измерении качества.
Помимо эффекта от хранения контекста и работы с ним для агента, ты получаешь прямой инструмент к быстрой генерации любых отчетов, графиков, презентаций и всего чего угодно, потому что markdown превратить в HTML (и даже красивый) - теперь стоит пару кликов и двух команд.
❤1