Продукт

Закон Гутхарда: как НЕ хакнуть метрики Мы выполнили KPI по регистрациям на 120%. Хорошо? Ну да, а чего же. Пошли на выручку смотреть, а она упала. Копнули глубже трафик, оказалось, что ботов нагнали. Премия получена, но в целом компании нехорошо. Пожалуйста, словили закон Гутхарда. Капелька истории В 1975 году британский экономист Чарльз Гудхарт сформулировал закон, который звучит так: «Когда метрика становится целью, она перестает быть хорошей метрикой». Простыми словами как только вы привязываете к конкретному показателю бонус, повышение или оценку успеха команды, люди перестают делать хороший продукт. Они начинают «хакать» систему и оптимизировать все под одну цифру даже в ущерб здравому смыслу. Примеры, когда плохо Посмотрим как не надо делать. 💩 Разработка Цель - количество строк кода. Итог: разработчики пишут раздутый код без рефакторинга. 💩 QA и Баги Цель - количество закрытых багов. Итог: тестировщики заводят микро-баги (опечатки, съехавший пиксель), а разработчики их героически фиксят. Реальные проблемы висят в бэклоге. 💩 Продукт Цель - увеличить дневную аудиторию. Итог: команда начинает спамить юзеров кликбейтными пушами. Люди заходят, плюются и закрывают приложение. DAU растет, Retention и лояльность летят в пропасть. Как лечить Два простых правила. 1. Используйте метрики-противовесы Если измеряете скорость ответа поддержки (Time to resolve), обязательно трекайте удовлетворенность (CSAT). Ускорение не должно ломать качество. 2. Не привязывайте мотивацию к одной прокси-метрике KPI должны быть комплексными и привязанными к финальной ценности для бизнеса (например, LTV или Profit), а не только к промежуточным шагам.

Бонус Если внутри компании используете North, то она неплохо будет калибровать вас и подсветит не свернули ли вы не туда в погоне за красивыми дашбордами.

Примеры, когда хорошо Посмотрим как надо. 😍 Маркетинг и Рост Цель: Снизить CPA (стоимость привлечения) или увеличить количество регистраций. Противовес: Retention 7/30 дня (Удержание) или LTV. Почему это работает: Защищает от налива дешевого «мусорного» трафика или мотивированного инсталла. Маркетологи больше не смогут выполнить KPI, просто приведя ботов или нецелевую аудиторию - им придется следить за тем, остаются ли эти люди в продукте. 😍 Разработка и DevOps Цель: Time-to-Market (скорость выкатки фич) или Velocity в стори-поинтах. Противовес: Change Failure Rate (процент релизов, приведших к сбоям) или количество багов на проде. Почему это работает: Команда не сможет гнать сырой код в продакшен просто ради того, чтобы закрыть спринт. Скорость уравновешивается стабильностью системы. 😍 E-commerce и Монетизация Цель: Conversion Rate (Конверсия в покупку). Противовес: AOV (Средний чек) и Margin (Маржинальность). Почему это работает: Самый простой способ задрать конверсию — раздать огромные скидки. Продажи взлетят, конверсия будет зеленой, но бизнес сработает в минус. Парная метрика заставляет команду искать баланс между объемом продаж и прибылью. Нюансы и конец Многие думают, что проблема в самих метриках, но закон Гудхарта работает тупо на человеческой психологии. Мы идем по пути наименьшего сопротивления. Человек не будет себе осознанно усложнять жизнь, а раз так, то зачем заведомо ему ставить цели, которые захочется хакнуть? #продуктовыеметрики

🐍 Как сделать автоматизацию 100% одной фразой 🎤 В 2018 году в одной крупной компании проходила презентация чат-бота. Команда защищала метрику автоматизации. Один из топ-менеджеров выслушал доклад и сказал: — Я знаю, как одной фразой довести вашу автоматизацию до 100%. 📊 В 2020 году уже в другой крупной компании топ-менеджера уволили за то, что он слишком успешно растил автоматизацию. Автоматизацию растили. Топ-менеджера сократили. Баланс всё-таки нашёлся — просто не там. 🤖 В 2026 году помощь понадобилась одному AI-директору. Он обратился во внутренний хелпдеск, но ответа не получил: годом ранее компания успешно выполнила цели по внедрению AI и сократила поддержку. AI внедрили. Помогать стало некому. Когда-то я уже выпускал статью о том, как сделать контактный центр автономным. Похоже, кто-то воспринял слово «автономный» слишком буквально: теперь контактный центр не зависит ни от операторов, ни от обращений, ни от необходимости кому-то отвечать. Что общего у этих историй? У метрики автоматизации есть неприятная особенность: она не умеет отличать ситуацию «клиенту помогли» от ситуации «клиент не смог ни до кого достучаться». В обоих случаях оператор не понадобился. Поэтому автоматизацию нельзя растить без второй метрики, которая показывает, не стало ли клиентам хуже. Иначе вместе с автоматизацией можно незаметно вырастить отток, а повторные покупки и кросс-продажи — так же незаметно сократить. 🐍 Говорят, на змею не действует собственный яд. Но в этой истории в конце концов подействовал. Правда, это был яд других гадюк. 💬 А теперь вопрос: какая одна фраза может сделать автоматизацию чат-бота 100%? Пишите свои версии в комментариях 👇

Сначала продакт — это фаундер. Потом это перестаёт работать В стартапе на старте продакт-менеджер не нужен — потому что он уже есть. Это фаундер. Работа продакта в сухом остатке — переводить запрос бизнеса в конкретные решения для разработки, оставляя инженерам только техническое пространство. Не «придумайте, какая кнопка нужна», а «синяя, посередине этого экрана, на ней написано „оплатить“, не „купить“ и не „узнать цену“». Пока в команде пятеро, лучше всех в компании этот перевод делает фаундер. Он разговаривал с клиентами, он слышал, на что они ругаются, он знает, откуда придут следующие деньги. Наёмный человек будет полгода вытаскивать этот контекст из его головы — и всё равно вытащит хуже. А потом наступает момент, который почти всегда проходит незамеченным. Выглядит он не как «выросли до 20 человек», а как исчезнувшее время. Продажи, переговоры, контракты, инвесторы — и вечером просто нет часа, чтобы сесть и детально описать, что нужно получить. Задачи уезжают в разработку в формате «ну вы поняли». Через месяц выясняется, что не поняли: команда что-то делает, но не то. Не медленно и не криво — а именно не то. Ментор клуба MFS и ex-Director of Engineering в Яндексе Андрей Романовский сформулировал это так:

Если кажется, что разработка делает не то, дело почти никогда не в разработке.

Ощущение «мы как будто сложно договариваемся с разработкой» почти никогда не про инженеров. Оно про то, что переводчик исчез, а работа осталась. Дальше вариантов честных два: вернуть это время себе в календарь или отдать роль отдельному человеку. Третий — «они адекватные, разберутся» — самый дорогой. Если уже проходили эту точку — расскажите в комментариях, по какому признаку поняли, что пора Андрей Резинкин | Money For Startup

Своя доставка еды vs агрегатор На днях впервые воспользовался доставкой от сети ресторанов Bistro Group — в ней больше 20 разных брендов от шикарного стейкхауса Texas Roadhouse до напитков и пончиков от Randy's Donuts. Сервис позиционируется как бесплатная доставка из всех ресторанов сети — All The Bistro Group concepts on your fingertips. Доставка действительно бесплатная и на многие позиции в меню есть дополнительные скидки. Я когда заказывал думал «Ага, видимо не хотят отдавать долю от заказа агрегаторам и для этого сделали свою службу доставки. Видимо, количество заказов позволяет сделать хорошую юнит экономику через свой штат курьеров». В условиях Филиппин с желающими работать курьером проблем нет, это вам не Москва. Каково же было моё удивление, когда мне пришло сообщение в Viber (да, здесь многие бренды используют его как основной канал коммуникации) от Foodpanda, что мой заказ едет с одним из их курьеров. В заказе стоит символическая цена в 1 пессо и пометка «уже оплачено». Давайте вместе подумаем какую продуктовую метрику и процессы оптимизирует компания таким сервисом? Какая долгосрочная цель? Мои варианты: 📌 В собственном приложении для заказа еды можно лучше управлять спросом. В группе много разных ресторанов. Какие-то очень успешные, какие-то нет. Можно использовать как инструмент онбординга в новый ресторан и растить LTV. 📌 Долгосрочная цель — полностью избавиться от зависимости от внешних сервисов доставки. Для этого любые дополнительные расходы оправданы и это временно. Возможно, это мне так повезло, и часть заказов они уже доставляют сами. 📌 Качество распределения заказов по ресторанам у Foodpanda и Grab плохое. Поэтому было выгоднее создать свою систему приема заказов и оставить на партнеров только последнюю часть — привезти заказ на указанный адрес. #producteye #philippines

Вчера говорил про гильдии в MMORPG применительно к новой функции сообществ в тг. И действительно новые сообщества имеют ровно те же механики: 🔵Паблик может вступить только в 1 сообщество 🚘 🟣 Отсюда, очевидно, будет конкуренция за них 💞 🩷 Новым вступившим пабликам надо как-то помогать и что-то давать, чтобы им было полезно и они оставались 🖱 🔴 Участникам сообщества нужно делать что-то вместе для прокачки сообщества и усиления каждого в отдельности 🚵 🟢 Конкуренция будет за сильные паблики в сообществе. Чем больше и более сильные паблики внутри, тем более привлекательным будет сообщество и тем более оно будет конкурентноспособно на фоне остальных 🌟 🔵 Нужно уделять "найму" пабликов специальное время: зазывать к себе, объяснять бонусы, предъявлять требования к отбору. Формировать пул прав и обязанностей 📃 И всё это приводит не просто к геймификации, но и к реальной мете в телеграме: стать большим сообществом, победить конкурентов, вести набор в гильдию... 🌐 Допустим, мы все это будем делать. Но надо ответить на вопрос — зачем? 🤔 Что думаете? 😳 А я уже начинаю брейнштормить, что можно сделать силами участников нашего нового сообщества и что будет для всех полезно. Пока мысли - провести онлайн фестиваль / знакомство с каналами сообщества 🤩 Поделитесь и вы своими соображениями. И, конечно, вступайте в "Практику геймдева"! 👋

Продуктовые наблюдения: идеи ограничения экранного времени

Макрон подписал закон о запрете мобильных телефонов в старшей школе. В средней школе аналогичный запрет действует с сентября 2025 года.

Еще в 2015 году я возглавлял продуктовое направление в Максимуме и мы думали над проектом мобильного приложения для школьников, которое помогает учиться путем блокировки приложения на время обучения. Мы думали над тем, как можно через это приложение сгенерировать вовлеченность в образовательный процесс. Идея помочь подростку стать сознательнее, но конечно, обучение через просвещение - это для слабаков. Лучше и эффективнее блокировать. Например, соцсети (кстати, в этом отношении во многих странах уже есть ограничения - Австралия, Индонезия и еще ряд стран) Зачем это вообще делают? Сторонники возрастных запретов утверждают, что соцсети с их «убедительным дизайном» (бесконечная прокрутка, автовоспроизведение, лайки) эксплуатируют незрелую систему вознаграждения мозга подростков, вызывая зависимость и повышая риски тревожности, депрессии, расстройств пищевого поведения и нарушений сна. Запрет также защищает детей от кибербуллинга, нежелательных контактов со взрослыми, вредного контента (порнография, насилие, дезинформация, контент о самоповреждении) и избыточного сбора персональных данных платформами. Правительства, такие как Австралия, называют это не «запретом», а «отсрочкой», чтобы дети развили цифровую грамотность, импульс-контроль и устойчивость до встречи с тяжёлым цифровым миром. Почему это не работает? Критики указывают, что нет убедительных доказательств причинно-следственной связи между запретом и улучшением ментального здоровья: исследования показывают корреляцию, но не гарантируют, что отсрочка доступа решит корень проблемы. Дети могут обходить запреты через фейковые аккаунты или уходить в менее регулируемые платформы, что делает их ещё более уязвимыми. Кроме того, блокировка лишает подростков образовательных и социальных преимуществ соцсетей (доступ к информации, сообществам по интересам, поддержке для маргинализированных групп) и может нарушать свободу слова - именно на этом основании Конституционный совет Франции заблокировал закон. Эксперты, как в Сингапуре, предлагают вместо запрета регулировать вредные функции платформ (анонимность, алгоритмические ленты, бесконечный скролл), делая среду безопаснее по дизайну. Итоги: Знаете, обычно ты думаешь, что только в России все стремяться запретить, но если так посмотреть, по всему миру политики стремяться решать радикально проблемы - не разбираясь. Мое мнение - нужно вкладывать время в образование, показывать детям пример и начинать нужно с себя. А что думаете об этом вы? стоит ли вводить такие ограничения у нас (условно на регистрацию в соц сетях или владение смартфоном?) Ставьте реакции 👍 я за 👎 я против 🔥мне нравится пост @blackproduct

Что делать, если все заинтересованные стороны по-своему правы Одна из сложных ситуаций в работе менеджера продуктов: когда в обсуждении вариантов решения каждый стейкхолдер приводит свои веские аргументы, конфликтующие друг с другом, — но нужно договориться. ➡️ Отдел продаж хочет добавить интеграцию с конкретной системой, потому что без нее крупный клиент не подпишет контракт. ➡️ Команда разработки говорит, что интеграция потребует серьезных изменений в архитектуре и создаст новую статью расходов на поддержку. ➡️ Менеджер продукта уже провел исследование среди действующих клиентов и считает, что ресурсы стоит вложить в другую проблему, которая касается большого сегмента пользователей. ➡️ CEO напоминает, что выход в сегмент, из которого пришел крупный заказчик, — одна из стратегических целей года. Решение предстоит принять, учитывая все аргументы, интересы и последствия. Что особенно важно при этом не упустить — рассмотрим ниже на примере. 1️⃣ Сначала разберитесь, что именно стоит за позицией участника Допустим, менеджер по продажам хочет закрыть сделку, чтобы выполнить KPI и закрыть свои личные финансовые нужды. В разработке треть команды уходит в отпуск, и ресурсов на быстрый запуск интеграции просто нет. Команда продукта уже прошла часть пути для повышения LTV действующих клиентов и не хочет бросать, пока есть возможность вовремя добавить востребованную функцию. А CEO делает на новый сегмент большую ставку из-за его платежеспособности — и надеется за счет этого вывести компанию на самоокупаемость, потому что привлекать инвестиции стало сложнее. 2️⃣ Сведите аргументы к общим критериям Когда каждая сторона защищает свою ценность, нужно привести аргументы к одному знаменателю — стоимости: 🔵 Каковы минимальные требования конкретного клиента и сколько ресурсов потребуется на разработку? 🔵 Какие технические последствия и статьи расходов создаст? 🔵 Какой коммерческий эффект ожидаем? 🔵 Можно ли использовать решение для других клиентов и какой объем рынка им можно охватить?  Тогда становится понятно, между какими величинами стоит выбор. 3️⃣ Проверьте цену отказа от каждого варианта Если не делаем интеграцию, то: 🟦 сохраняем архитектуру; 🟦 экономим ресурс и можем завершить разработку функции для действующих пользователей, от которой ожидаем прироста LTV на 2%; 🟦 рискуем потерять крупного клиента; 🟦 откладываем выход в новый сегмент на 3–4 месяца и теряем возможность получить критически важные Х миллионов, а это означает необходимость срочно искать инвесторов или сокращать издержки. Так становятся ясны возможные последствия не только активных действий, но и бездействия. 4️⃣ Распишите все возможные варианты и последствия Чтобы понять, какой вариант решения действительно будет оптимальным, полезно создать канву для дальнейшего обсуждения:  🔵 исходный контекст и данные; 🔵 варианты решения и их стоимость; 🔵 возможные последствия и риски по каждому варианту, в том числе в денежном выражении; 🔵 необходимые для проверки вопросы.  Это позволяет сделать логику выбора ясной для всех участников. 5️⃣ Найдите способ проверить самое дорогое неизвестное Недостаток каких данных может привести к самой дорогой ошибке в выборе решения? В нашем случае это может быть вопрос о клиенте: действительно ли для заключения сделки нужна полноценная интеграция или основную потребность можно закрыть минимальной версией или даже ручной обработкой данных?  Может быть вопрос о рынке: нужна ли интеграция с этим сервисом еще кому-то из стратегически важного сегмента?  Или технический вопрос: сколько реально будет стоить решение и можно ли сделать его проще и дешевле? На этом этапе важно понять, какой сценарий может сделать решение ошибочным, и найти самый дешевый способ это проверить. 6️⃣ Зафиксируйте, какой вариант выбрали и чем будете жертвовать, если компромисс невозможен Предположим, вы выбрали делать частичную интеграцию для одного клиента с ручными процессами на начальном этапе. Потому что стратегическая ценность клиента очевидна, но другим представителям целевого сегмента интеграция с конкретным сервисом может не понадобиться.  Если стоимость такой разработки все равно высока, нужно понять, с какой инициативы будет переброшен ресурс, который пойдет на интеграцию. А также зафиксировать, в каком случае возможен пересмотр решения. Проделав все шаги, вы получите не только матрицу оценки вариантов и рисков, но и план принятия решений для дальнейших инициатив. Если через месяц отдел продаж снова предложит сделать полноценную интеграцию, не придется заново все обсуждать: понятно, какое решение приняли, на каких основаниях и что должно измениться, чтобы его пересмотреть. @productsense

Что делать, если ты оказался на конференции POV: ты сидишь на отраслевой конференции, билет на которую стоит 30к. Со сцены вещает чиф продакт оунер, который рассказывает как они внедряли новые процессы в 100 команд разработки в своей компании. Ревью 360, аджайл, зарядка по утрам, вовлекающие тренинги и новый процесс хождения тасок в Джире. В зале вокруг тебя сидят чуваки с блокнотиками, которые старательно записывают, что они будут внедрять в своем стартапе на 20 человек, чтобы добиться таких же впечатляющих результатов. Сосед справа фоткает каждый слайд, потому что у него нет интернета, чтобы потом скачать презу с сайта конференции. На кофе-брейке вы все накачались кофе, в сравнении с которым доклад кажется отличным. И тут ты вспоминаешь, что ты клиент этого сервиса, чей сотрудник сейчас распинается на сцене. Заходишь в их приложение и видишь, что за последний год там, несмотря на диджитал трансформацию и новые процессы, не изменилось Н И Х У Я Что делать в такой ситуации? Даю пошаговую инструкцию. 1. Прикрываешь рот ладонью. 2. Начинаешь кашлять и сквозь кашель негромко кричишь «говно!» 3. Уходишь заниматься своими делами.

Куда трансформируются образовательные курсы. Продажи курсов сейчас очень сильно упали, в отрасли прям кризис-кризис. Вместе с тем, растут клубы и всякие долгосрочные подписочные истории. Я тоже в эту штуку пошел — делаю Лабу (ИИ клуб по подписке). Ссылку специально не даю, история пока закрытая и для своих, меня там овербукнули, разгребаю 😬 При этом думал запускать сейчас как раз новый курс, и вспомнил об этой рыночной особенности. Так что решил не пускать его отдельным потоком, а сделаю бесплатно для резидентов лабы (но нужно будет взять подписку на длительный срок). В общем, вижу сильный тред в комьюнити/сообщества, которые отвоевывают то место, где раньше жили курсы.

Недавно откопал, что на Ютубе (в их Studio, это так у них кабинет автора называется) есть возможность отвечать на другие похожие комменты. Типа, вот решил я ответить на КГАМ какой-нибудь вопросик про эйай под видосом про ASML. Придумал ответ, написал его. А Ютуб сразу мне намекает, что несколько других юзеров спрашивали то же самое или примерно похожее. Значит, я могу сразу открыть и ответить и им, ведь ответ уже готов. Без этого бы я на них не ответил вообще, я так - может быть. Для Ютуба это понятный способ повысить активность. Ведь если блогер больше отвечает, то зрители больше пишут, а значит растёт вовлечённость, лояльность, time in app и бла бла бла. Один большой и известный ютубер мне как-то говорил, что комменты нельзя открывать вообще, но я его не послушался. Видимо, потому что сформирован Телегой 👍

Новый продукт уже есть внутри вашего агентства 🔵 В прошлом посте закончил на том, что мы поняли, что надо что-то менять и искать новый продукт. И вот как мы это сделали. Я часто говорю в своих видосах, что идеи новых бизнесов и продуктов редко приходят откуда-то со стороны. Обычно они уже лежат внутри, надо просто их разглядеть. Вот мы и начали смотреть, что у нас в Белом Квадрате есть сильного прямо сейчас. Причём именно то, что мы сами за продукт вообще НЕ считаем. Начали перебирать и поняли: одна из самых сильных вещей у нас - это навыки работы с SEO. Не для клиентов, а для самих себя, то есть умение продвигать через поиск собственное агентство. Плюс сам сайт: он у нас пять лет сеошится, растёт в позициях, у него органический трафик, домен хорошо раскачан. И мы такие: а давайте тестово, чисто ради эксперимента, попробуем сделать несколько страниц под широкие услуги. Сделали SMM, трафик, блогеров. Подтянули туда наши старые нишевания, например SMM для медицины. И вот мы офигели, когда страницы начали быстро расти в выдаче и с них пошли лиды)) На второй месяц с каждой страницы приходило уже по 4–5 заявок. В сумме мы получили порядка десяти лидов на эти услуги и пошли с этими клиентами в пресейл. Попробуйте так же: посмотрите внутрь своего агентства и выпишите, что у вас есть сильного, что вы возможно продуктом то и не считаете. Например, то, что вы уже делаете для клиентов, что пользуется у них спросом, что хвалят, но это у вас не упаковано как отдельная услуга. Это и может стать новой точкой роста вашего агентства) Мы поняли, что идея то классная, но у нас вообще еще нет экспертизы в этой услуге... В следующем посте расскажу, что сделали дальше)

Я – ленивая жопа и мне не стыдно… Мне очень лень делать всякие штуки, которые можно не делать. Я – тот самый человек, который ищет легкие пути. Вот, например был недавно вопрос напоминаю ли я клиентам о сессиях. Боже упаси! Делать мне больше нечего! Я даже не согласовываю даты сессий.🙈🙈🙈 Я настолько ленива, что просто выбрала удобный мне сайт-календарь, и клиенты сами выбирают день и время сессии. А я настроила так, что им приходят письма-напоминалки за сутки и за час, в этих же письмах ссылка на Зум. И если надо отменить или перенести, ссылка на всё это в письме-подтверждении записи

Нафиг мне не сдалась вся эта история с «Давайте поищем окошки».

Мой максимум – это когда клиент за 2 часа до сессии внезапно пишет «Маша, я чот не успеваю, может на час сдвинуть?» И только тогда я лезу в календарь и смотрю можем или не можем. Ибо по умолчанию свободные окна показаны только на завтра и далее. Ну чтобы изменение времени не было для меня неожиданностью. Я слишком ленива, чтобы не планировать заранее. А вы где ленитесь? Тимофеева Мария в бизнес с головой

Смыслы и команда Помню как работал над одним продуктом. Задачи сыпались отовсюду. Это была стадия активного роста. Куча функционала, параллельно пересборка интерфейсов, планирование промо и много чего еще. За всем этим добром, я упустил самое важное - это смысл. То есть, у меня то в голове он был, а поделиться им со своей командой я забыл. Здесь мне становится стыдно. На уровне задач, которые шли в разработку, я старался максимально полно описывать зачем нам это и какой профит принесет. Но глобально, это лишь отдельные части пазла. Гораздо проще собирать, если видишь общую картинку. А когда ты собираешь не один, эта картинка становится чертовски важной штукой. Если твоя команда понимает: - для кого делает продукт - какие задачи он решает - что это дает бизнесу - и на какие метрики нужно смотреть ... то появляется магия. Та самая, когда все видят смысл своей работы. Когда любой может предложить идею, и она ложиться в канву продукта. Когда есть драйв делать то, что ты делаешь. И много, много других "когда". Задача продакта - донести смысл. Он отвечает за команду, за бизнес и за счастье пользователя. В свое время я упустил этот момент и сожалею, что не могу крутануть колесо обратно. Но, не все так печально. Исправить ситуацию сложно, но можно. Посмотрите на свои команды, подумайте над тем, точно ли все понимают смысл того, что делают? Донесите его и увидите, какие чудеса начнут происходить💫 #продуктовыйпуть

5 Growth-кейсов применения AI для продактов Представьте обычный понедельник продуктовой команды. На дашборде всё более-менее знакомо: трафик растёт, регистрации идут, но дальше начинается классика. Половина новых пользователей не доходит до первой ценности, Trial не конвертируется так, как хотелось бы, Retention постепенно проседает, а команда снова обсуждает, какую гипотезу тестировать следующей. В этот момент почти неизбежно появляется идея: "А давайте добавим AI". Проблема в том, что это неправильная точка старта. Гораздо интереснее спросить: где именно в нашей воронке юзер теряет ценность - и может ли AI это изменить? Если посмотреть на AI через эту призму, я вижу пять особенно интересных Growth-кейсов. 1. Activation. Представьте сложный B2B-продукт. Один пользователь пришёл построить отчёт для CEO, другой - автоматизировать процесс, третий - просто проверить, подходит ли ему продукт. Но всем троим мы показываем один и тот же Onboarding из пяти экранов. AI позволяет развернуть этот сценарий. Вместо "вот наш продукт, разбирайся" начать с простого вопроса: "Что вы хотите получить?" Дальше система понимает JTBD, адаптирует Onboarding, помогает настроить продукт и ведёт человека к первому полезному результату. В таком сценарии меня интересует не количество диалогов с AI, а сократился ли Time-to-Value и вырос ли Activation Rate. 2. Conversion. Большая часть персонализации сегодня всё ещё работает по принципу: пользователь попал в Segment X - показываем Offer Y. Но два человека из одного Segment могут находиться в совершенно разном контексте. Один уже почти готов купить, другой пока пытается понять базовую ценность продукта. AI даёт возможность персонализировать не только баннер или рекомендацию, а сам путь к покупке: аргументацию, CTA, Landing, предложение тарифа, следующий шаг. То есть перейти от Segment → Rules → Experience к Context → Intent → Personalized Experience. И снова важно не попасть в ловушку Vanity Metrics: если CTR вырос, а Trial → Paid остался прежним, Growth-кейса здесь нет. 3. Retention. Мне кажется, это один из самых недооценённых сценариев. Пользователь часто уходит не потому, что продукт плохой, а потому что в какой-то момент перестаёт понимать, что делать дальше. Особенно в сложных B2B, Analytics и Productivity-продуктах, где ценность появляется после последовательности действий. Здесь AI может превратить продукт из набора функций в систему, которая понимает контекст и говорит: "Вот следующий лучший шаг, который приблизит тебя к результату". Если это действительно работает, мы должны увидеть эффект уже не в AI Engagement, а в повторном достижении Value Event, D7/D30 Retention и Churn. 4. Monetization. Классический Upsell выглядит примерно так: "Вы использовали 80% лимита - купите Pro". Это удобно для продукта, но не обязательно полезно для пользователя. Гораздо интереснее определить момент, когда платная Capability действительно помогает человеку решить его текущую задачу. То есть искать не момент, когда мы можем продать, а момент, когда пользователю выгодно купить. Если AI понимает Intent и контекст достаточно хорошо, Upsell перестаёт быть рекламной вставкой и становится естественной частью пользовательского результата. Тогда уже имеет смысл смотреть на Free → Paid, ARPU, Expansion Revenue и NRR. 5. Скорость экспериментов самой продуктовой команды. У продакта постоянно копятся User Interviews, Support Tickets, Reviews, Product Analytics, результаты прошлых экспериментов. Сигналов много, а времени на их синтез мало. AI здесь может работать как Product/Research Copilot: собирать эти сигналы вместе, находить повторяющиеся проблемы, помогать формулировать гипотезы и анализировать результаты. Ценность появляется, если сокращается весь цикл Signal → Hypothesis → Experiment → Learning → Decision, а команда за то же время принимает больше качественных продуктовых решений. Не так важно, сколько пользователей нажали на кнопку с бонусом. Важно, изменилось ли что-то дальше на всем пути юзера.

Как защититься от потребительского экстремизма На маркетплейсах всё чаще встречаются случаи потребительского экстремизма: покупатели подменяют товар муляжами и оформляют возврат, ссылаясь на дефекты или несоответствие описанию. Чаще всего страдают продавцы техники и электроники. Чтобы обезопасить бизнес: — Фиксируйте факт подмены при возврате товара — Подавайте жалобу через платформу, затем официальную претензию — Обращайтесь в суд, если платформа не реагирует Быстрая реакция и грамотно оформленные доказательства помогают не только вернуть убытки, но и сохранить высокий рейтинг, доверие покупателей и стабильность бизнеса. Фаундер | Бизнес и Стартапы

Как заставить зумера со спауном внимания 8 секунд пройти онбординг из 15 экранов? 🤨 кмооооон да никак 😳 В 2026м году медианный completion rate онбордингов по приложениям всего 50%. 50, КАРЛ Посмотрите сессии своих пользователей - едва ли они вдумчиво отвечают на каждый вопрос, наверняка большинство кто доходит до конца пролетает онбординг на автопилоте, не читая ни одного экрана и это уже стандарт индустрии, спасибо тик току и другим платформам шорт контента за клиповое мышление у целого поколения 😂 Ну а чего, представьте показывать восьмилетнему ребенку вместо мгновенной выгоды слайды, которые можно пролистнуть не читая Новые проблемы как обычно требуют новых решений и мне кажется мой друг @eduardbaksheev (Эдик кстати нам оч помогает с дизайном aesty!) придумал интересное решение для своей прилы peri ai (вопросы по женскому здоровью), у него онбординг это чат с персонализированными вопросами и голосовым вводом 🧠 Прокликать такое невозможно - следующий вопрос не появится пока не ответишь, и каждый ответ меняет сценарий. Через минуту апп знает обо мне больше чем классический онбординг узнал бы за 15 экранов и мне лично отвечать было интереснее, чем заполнять форму, так как я получала какой-то отклик после каждого вопроса (но справедливости ради зумер я по нижней границе 😧) Мне стало интересно, где еще это есть и я нашла парочку примеров. Airtable собирает воркспейс из разговора с AI, Clay генерит первый воркфлоу из ответов welcome survey, Pi и Replika знакомятся с тобой как человек, ну и конечно Duolingo вообще ставит урок до регистрации, так что думаю это вполне можно считать новым трендом - персонализированный чат вместо формы ответов на онбординге 🐵 Ну и вишенка на торте - если продукт сам по себе чат, значит онбординг это уже первое использование продукта. Наталкивает на мысли что надо пробовать у себя, мы сейчас как раз первую сессию переделываем - показать функционал и объяснить, что не надо все вещи фоткать отдельно скорее всего будет очень удобно, как будут цифры - поделюсь Ставлю на то что через год чат-онбординг будет у половины consumer аппов, скриньте 😅 @neural_prosecco

Зачем ускорять разработку? Просто через раз вижу этот вопрос, во всех постах про агентов и новую эру автоматического кодинга. Переубедить конечно никого не получится, но написать надо, чтобы получилось структурировано. Погнали. Нет такого количества задач Если вы поговорите не с менеджерами, а владельцами бизнесов, то окажется, что количество идей у них такое, что за всю жизнь не сделать. То что из этого не всегда доходит до низов, проблема размера и процессов, которые тоже пытаются решать, поэтому так много разговоров про sdd и аналогичные истории. Если разработка стала в два раза дешевле/быстрее, становятся экономически оправданными задачи, которые раньше вообще не попадали в backlog. Это никому не нужно В конкурентном мире невозможно сделать продукт до конца и сидеть сложа руки. А конкуренция приводит еще к тому, что кто первый встал, того и тапки. Сегодня вы на высоте, завтра ваш бизнес угрохали потому что вы не успели адаптироваться. Ну если вы работаете у монополиста/госа/стратегического игрока, то можете игнорировать этот пункт 🙂 Фичи не принесут деньги Может принесут, а может и нет, это невозможно обобщать не зная конкретных обстоятельства конкретных ситуаций. Например мы годами не могли сделать b2b кабинет таким как хотели наши клиенты, потому что у нас никогда не хватало ресурсов на эту часть. С помощью агентов мы это сделали и смогли получить хорошие контракты, которые от нас раньше уплывали. Ускорение разработки меняет не только скорость выполнения уже выбранных задач, но и сам набор задач, которые становится рационально делать. Покажите как это сократило фот? По правде говоря у многих сократило. Но последовательность другая. Последние годы у многих были сокращения по экономическим причинам, а потом заморозка найма при одновременном росте производительности за счет ИИ. Поэтому ии больше повлиял не на сокращение как таковое, а на отсутствие найма Покажите как это увеличило прибыль? В экономике есть только два способа растить маржинальность: рост производительности и повышение цены. Когда то массовое внедрение компьютеров и экселя привело к такому же эффекту. Итого Ускорение разработки само по себе не цель. Реальная цель это снизить стоимость изменения продукта, поэтому помимо разработки одновременно ускоряется еще много всего, но об том просто говорят в других местах, куда разработчики не ходят, поэтому у них часто складывается такое одностороннее представление о происходящем Telegram | YouTube | AI Клуб

🎾 как за час навайбкодил прототип > протестил > сменил направление в последний месяц дико влюбился в падел, играю постоянно, и для меня это стало способом не выгорать ну и, как это бывает, в какой-то момент начал смотреть на это уже как продакт стал валидировать гипотезу, что у людей есть частая боль — быстро найти 4-го игрока, когда кто-то в последний момент сливается с игры, из инсайтов - множественные сообщения в чатиках побрейнштормил с гпт, выделил сегменты, подумал про риски, потом пошел в клод и буквально за час навайбкодил простой прототип на джанго с базой данных и вот в процессе понял самое интересное: история, скорее всего, не про b2c в лоб логичнее идти через b2b-модель и делать продукт в первую очередь для клубов, а b2c использовать как канал лидогенерации и тебе не нужно рисовать прототипы в фигме, не нужно сливать сотни тысяч на мвп, чтобы быстро протестировать гипотезу навайбкодил пре-мвп > продолжил в том же направлении или же сменил вектор

Есть тезис, который команды произносят с гордостью: стратегию не пишем, вместо этого быстро проверяем гипотезы. То есть между стратегией и скоростью выбрали скорость, потому что стратегия в этой картине мира что-то долгое и тяжёлое, что мешает бежать. Выбор мнимый. Хорошая стратегия вообще не про то, сколько её строили и сколько нужно строить. Она про то, понимаешь ли ты систему, в которой работаешь: какие в ней причинно-следственные связи, где узкие места, в какой точке небольшое усилие даёт непропорционально большой эффект. Такое понимание можно собрать за неделю, если знаешь, куда смотреть. Можно не собрать и за год. Я уже писал, что гипотеза в научном смысле описывает наблюдаемый феномен и требует экспериментальной проверки, а «сделаем X, получим Y» — это идея. В бэклоге команд, гордящихся скоростью, чаще лежит именно второе. Поэтому если этого самого понимания системы нет, быстрая проверка гипотез превращается в брутфорс идей в надежде, что какая-то стрельнёт. Скорость тут не спасает, ибо пространство вариантов огромное, а выигрышных в нём единицы. И даже когда идея стреляет, на следующем шаге это почти ничего не даёт. Гипотеза в стратегии живёт внутри связанного плана, где несколько линий бьют в один рычаг, поэтому её проверка даёт больше, чем ответ на один вопрос. Подтвердилась или нет, картина системы обновилась целиком. Соседние гипотезы стали сильнее или потеряли смысл. Появились новые данные, которые теперь надо объяснять, и следующий шаг выбирается уже из обновленный картины мира. Идея же ничего не объясняет. Проверил, получил плюс два процента к метрике, порадовался и пошёл к следующему, никак не связанному пункту бэклога. Почему сработало и куда копать дальше, непонятно. Знание не накапливается, и даже десяток удачных идей даёт десять локальных улучшений, которые не складываются в одно большое. Проверять нужно, но без понимания системы проверять нечего, остаётся перебирать идеи и гордо называть это «культурой экспериментов».

Метакогниция и йогачара наблюдают за тобой с твоим продуктом В 1970-х психолог Джон Флавелл обнаржил, что дети с возрастом не просто лучше запоминают, а начинают отслеживать, что именно они запоминают и как они управляют этим процессом. Так в 1979 году появился термин метакогниция. За полторы тысячи лет до Флавелла последователи ветви буддизма Йогачара разбирали тот же вопрос с другой стороны: может ли сознание знать само себя напрямую, или для этого ему нужен ~ещё~один~слой~и~акт~сознания. Обычное сознание устроено простейшими слоями: №1. Слой хранилища Потока, накапливающий следы всех прошлых действий, восприятий и/от объектов; №2. Слой управления-контроля, который берёт этот поток и принимает его за устойчивое «я» или «это»; №3. Слой создания нового восприятия, работающий с текущим действием, восприятием и объектом. Но ни один из этих слоёв не видит Единого-Целого, потому что каждый слой фиксируется лишь на своей когнитивной функции, порождая на каждом уровне те самые когнитивные искажения На практике мы останавливаемся на первом-втором слое, считая это достаточным и принимая первую мысль как решение. И делаем это не потому, что дальше нечего смотреть, а... просто дальше смотреть Некому. Так и получается, что для контроля мышления нужен ещё один слой мышления, для контроля этого слоя следующий, для него ещё один... Кто наблюдает за наблюдателем? Никто-Ничто В йогачаре это называется виджняпти-матра или «только представление». А то, что кажется устойчивым объектом наблюдения, само есть лишь продукт смотрящего "ума". Потому что любая система поддерживает себя, воспроизводя себя заново на каждом шаге и наблюдение за собой средствами самой системы это акт её самокопирования. Сознание смотрит на себя тем же взглядом, из которого оно было сделано, и потому не открывает новый факт, а лишь заново пытается "пересобрать" старый. То, что кажется в этот момент «иным взглядом», сделано теми же слоями, что и всё остальное. Система не выходит за свой контур и не открывает новый взгляд и факт и не создаёт иную версию в момент наблюдения.

Мониторинг конституирует то, что потом контролирует

Пересборка идёт, а нового не прибавляется. Разнообразие нельзя нарастить изнутри если оно не приходит иным извне. Продакты натыкаются на это каждый день, в момент реакции на ситуации или на паттерны, которые сами же копируют и пересоздают прошлыми установками (паттерны и/или реакции?). А в постоянном стрессе тот слой, что должен создавать восприятие текущего объекта, вместо этого достаёт старый готовый слепок из слоя хранилища, и выдаёт его за "новую" реакцию на настоящее. То же самое происходит с реакцией на неправоту Пока слой контроля принимает поток мыслей за устойчивое «я/это/так», любое доказательство против одной из этих мыслей читается мозгом как угроза и атака на всё «я» целиком, и человек упорствует тем сильнее, чем больше доказательств против «этого» «вот так» и «я». Та же слепота определяет умение делегировать задачи Продакт, который не видит, что его «я уверен» и его «я умею» это два разных слоя, путает одно с другим вместо того, чтобы спросить того/То, кто разбирается/умеет лучше него, поэтому замечать моменты подмены тем же слоем, который его наблюдает, очень и очень сложно. Но когда «я» и «это» каждый раз пересобираются заново, неправота перестаёт быть угрозой и становится просто очередной логичной пересборкой под текущую реальность Нужно выйти Туда, откуда видно иначе и где наблюдающий перестаёт быть одним из слоёв, хватающихся за свои функции и оттуда спросить:

Что ощущается? Что изменяет это?

Чтобы понять объект-процесс, нужно стать объектом и процессом. Заметить Это – стать и перестать быть Этим. Существует дзенская загадка: если дерево падает в лесу и рядом нет никого, кто мог бы это услышать, издаёт ли оно звук?

Оценка мелких задач убивает ваше время Типовая ситуация: клиент постоянно присылает небольшие задачи и переживает, сколько времени займёт каждая. Команда начинает оценивать каждую задачу отдельно, согласовывать, потом объяснять, почему не попали в оценку. По факту оценка иногда занимает больше времени, чем сама работа. С маленькими задачами точность вообще плохо работает. Чтобы нормально оценить некоторые из них, задачу надо почти сделать. А если оценивать «на глаз», погрешность по каждой отдельной задаче будет большой. В итоге коммуникация с клиентом превращается не в работу, а в бесконечный цикл согласования бюджета и времени для мелких задач. Что с этим делать: отказаться от точной оценки мелких задач. Учитываем мелкие задачи постфактум. Сделали задачу, зафиксировали, сколько реально ушло. Чтобы клиент на это согласился, нужно немного изменить процесс: 1) Оценка остаётся, но она становится очень примерной: маленькая, средняя, большая задача. Менеджер проекта это может сделать без похода к разработчику. Клиент и Агентство соглашаются, что это грубая оценка. 2) Договориться о месячном лимите. Обычно поток таких задач укладывается в 10-20 часов в месяц. 3) При явном выходе задачи за лимиты или не попадании в оценку - заранее говорим об этом с клиентом. Большие, сложные и непонятные задачи нужно выносить отдельно и нормально оценивать. А поток маленьких задач лучше продавать почти оптом: грубо обозначать размер, следить за лимитом, заранее предупреждать о выходе за ожидания и оплачивать по фактически потраченным ресурсам. Пост помог подготовить резидент Галеры Михаил Сенсеев 🔵