Продукт

Запись подкаста "Директор бренда", где говорили про VK Знакомства и обсудили много интересного: - Как мы строим доверие в одном из крупнейших цифровых сервисов России - Как нам удаётся сохранять идентичность бренда внутри большой экосистемы - Рассказал про кейс масштабного ребрендинга Badoo, который я проводил - Почему я считаю, что крупные продукты постепенно отказываются от манипуляций и темных паттернов - Как алгоритмы знакомств решают, кого вам показывать - Поделился главным инсайтом о людях, который я вынес за 15 лет работы в дейтинге - Чем, на мой взгляд, российский рынок знакомств отличается от мирового - Каким я вижу будущее рынка знакомств и главные тренды ближайших лет Смотрите подробнее https://youtu.be/Cv019gk8VEI

Почему AI-персоны так убедительно врут Как-то я писала про подход, суть которого юзер-ресерч с помощью AI-персон. Ты описываешь портрет клиента, а LLM отыгрывает его и отвечает на вопросы как живой человек. Звучит как мечта соло-билдера: ноль рекрутинга, ноль созвонов, а “инсайты” можно собрать за один вечер. Но не так однозначно. Что с ними не так: • Модели склонны подстраиваться под рамку вопроса. Дашь чуть наводящую формулировку, и нейронка очень убедительно подтвердит то, что ты и так хотел услышать. • Если не дать модели свежие реальные данные, она опирается на усреднённое прошлое: тексты, паттерны и представления, на которых её обучали. А не на поведение конкретных пользователей сегодня. • Они плохо преподносят сюрпризы. Хороший ресерч часто ценен именно тем, что человек говорит или делает что-то, чего ты вообще не ожидал. AI-персона чаще выдаёт правдоподобное. Но правдоподобное мы и сами можем придумать. В итоге ответы часто получаются плоскими, слишком аккуратными и слишком благожелательными. Synthetic users могут хвалить то, что реальные люди потом игнорируют, не понимают или отвергают. Но это не значит, что инструмент бесполезный. Просто он работает ДО ресерча, а не вместо него: • Прогнать гайд интервью и поймать кривые, скучные или наводящие вопросы. • Быстро накидать гипотезы, чтобы прийти на живые созвоны более подготовленным. • Сделать pre-mortem концепта перед тем, как тратить бюджет на рекрутинг. • Проверить, какие возражения или edge кейсы стоит отдельно послушать у реальных людей. Источник: https://userevaluation.com/post/synthetic-users-vs-real-participants/ #PG_education @productgames

Да кто такие эти ваши producer-side A/B-тесты? В своей яндексовской эре работы над рекомендациями я точечно работал над качеством ранжирующей модели и не выглядывал за пределы этой области. Та же история была и в рекомендательном периоде работы в X. Но тут один добрый человек рассказал мне, что я оказывается жизни-то вообще и не знаю. Качество системы с точки зрения пользователя это ещё половина проблемы. Дело в том, что для долгосрочного качества платформы и процветания бизнеса необходимо смотреть на то, как изменение системы влияет на производителей контента (что в соцсети, что в маркетплейсе). В самом экстремальном случае система может показывать пользователям очень маленькую прослойку разнообразных авторов и игнорировать остальных. Те могут расстроиться и перестать постить, тем самым ухудшить долгосрочную ситуацию. Влияние на авторов и замеряется с помощью этого самого producer-side A/B теста. Посмотрим на то, как выглядит наивная её реализация в контексте рекомендаций. Среди всех авторов выделяем 2 группы - контрольную и тестовую - к примеру, по 1%. Скор для (98+1)% документов считается дефолтной моделью, тогда как для тестового набора из 1% будем предсказывать новой моделькой. Допустим, что она отдаёт большее предпочтения мелким авторам. Такой тест покажет прекрасный результат - все мелкие авторы счастливы и стали генерировать больше контента. Классический user-side тест, допустим, показал нейтральные метрики. Вроде бы всё в шоколаде, и вы шипаете изменение в прод, но вот беда - эффект испарился. Задроты вам укажут - на лицо нарушение Stable Unit Treatment Value Assumption. Перевожу на русский - изменение ведёт себя по-разному в зависимости от доли, на которую его раскатили. Тот кусочек мелких авторов среди 1%-ной выборки получил преимущество перед 99% таких же вне её. Раскатив изменение, весь рост показов, которые они получили в AB-тесте, размажется на остальные 99%. Чтобы побороть этот эффект, нужен фреймворк посложнее. Одно из решений предлагается в статье от Меты - "A Counterfactual Framework for Seller-Side A/B Testing on Marketplaces". Не знаю, насколько в ней это впервые предложили - может и нет, мне не важно. Иллюстрация на картинке. Итак, теперь мы будем оценивать 100% постов обеими системами - старой и новой (синей и зелёной). Для документов из контрольной выборки мы получаем их финальные позиции, как если бы мы ранжировали все 100% документов так, как обычно - они обозначены как C_1 и C_2. В то же время, документы из тестовой выборки получают свои финальные позиции так, как если бы все 100% документов ранжировала новая система - это T_1 и T_2. Финальную выдачу для пользователя мы создаём, расставляя эти документы на их соответствующие позиции, закрывая глаза на коллизии и помещая случайно друг под другом, если позиции точно совпали. Самый прикол этой схемы в том, что на ранжирование остальных 98% документов в принципе всё равно - до выкатки это будет старая система, после выкатки это будет новая система, но размер эффекта на документы в обоих случаях ожидается одинаковый. Именно это в том числе и проверяют авторы данной работы. В нижней части слева расположена выдача до выкатки - pre-test, а справа после выкатки - back-test. Авторы приводят результаты своих тестов, в которых демонстрируют одинаковость эффекта на измеряемые документы. Такая схема тестирования гораздо ближе к SUTVA. Надо понимать, что эта грёбаная SUTVA никогда не выполняется полностью. Любая выкатка изменяет распределение данных для обучения и последующее ранжирование. В обычных пользовательских A/B-тестах на это закрывают глаза и надеются, что эффект сохранится, что часто подтверждается holdback-экспом. А вот с авторскими A/B-тестами приходится проделывать такую гимнастику, чтобы хоть как-то подобраться к честному замеру. @knowledge_accumulator

Грустный #producthumor на тему событий прошлой недели, когда Apple удалил все приложения VK из стора. Хочется понять как работает такой подход и почему им активно не пользуются мошенники. Помню был период, когда Альфабанк почти каждую неделю публиковал новое приложение в сторе. Всякие Учёты доходов, Холдеры, A-интерьеры и BizKey-и. Их регулярно удаляли, а компания запускала новые. Интересно, как это выглядит с точки зрения команды безопасности? У каждого приложения есть возможность авторизовать клиента в мобильном банкинге с доступом ко всем деньгам? А поддержка как с этим работает? Для мошенников, кажется, вообще идеальный способ. Делаешь приложение, заманиваешь клиентов банка, получаешь реквизиты доступа, делаешь запрос на OTP, используешь его и реквизиты для входа в настоящее приложение, выводишь деньги. Или я что-то не понимаю? Поделитесь в комментариях, если знаете. #producteye

Как запустить новый продукт — и не разругаться, когда стратегия начинает ломаться Кейс «Авито Премиум» Продолжаем разбирать, как продукту и бизнесу работать на равных, — уже на примере запуска нового продукта. В «Авито» была стратегическая задача: стать лидером премиум-ресейл-сегмента и привлечь новую аудиторию в фешен-категорию. Но бизнес и продукт изначально смотрели на реализацию по-разному: ➡️ Бизнес видел точку роста в профессиональных продавцах — бутиках и ресейл-магазинах люксовых брендов. Логика была понятной: у таких продавцов уже проверенный ассортимент, и не придется масштабно вкладываться в проверку подлинности товаров. ➡️ Продуктовая команда пошла исследовать поведение пользователей — и увидела, что основной запрос — возможность безопасно покупать оригинальные вещи массового премиум-сегмента: Adidas, Michael Kors и других брендов, где особенно много реплик. Из этого сформировалась гипотеза, что пользователям нужны: — проверка на подлинность; — отдельное пространство с проверенными товарами. А еще на старте казалось, что основу ассортимента составят профессиональные продавцы. Но в ходе запуска выяснилось, что пользователи намного активнее реагируют на предложения частных продавцов. И тогда исходная стратегия начала меняться. Потому что вместе с ростом частного ассортимента вырос и объем проверок. А модель, в которой проверка оплачивалась платформой, перестала сходиться по экономике. Командам пришлось быстро перестраивать подход: ➡️ пересматривать позиционирование; ➡️ менять финансовую модель; ➡️ аккуратно тестировать платную проверку; ➡️ искать баланс между экономикой, ассортиментом и пользовательским опытом. При этом продукт и бизнес не начали тянуть систему в разные стороны: — бизнес — в сторону прибыли, — продукт — в сторону пользовательского опыта. Команды заранее договорились об общей целевой метрике — GMV (общий объем продаж), но разделили зоны влияния: 🔵 Бизнес отвечал за ассортимент и средний чек. 🔵 Продукт — за конверсии внутри воронки проверки и организацию премиального пространства. Помогло и то, что работа была синхронизирована не только на уровне метрик — она включала: — регулярные встречи; — совместные продуктовые разборы; — общие ассортиментные стратегии; — единые годовые цели; — прозрачные каналы коммуникации. А еще — совместное погружение в контекст: команды вместе запускали премиальный пункт выдачи на Патриарших прудах, общались с продавцами, собирали обратную связь и сами проходили операционные сценарии пользователей. В итоге запуск показал, что налаженная совместная работа продукта и бизнеса позволяет вовремя отследить важные сигналы рынка и пересобрать стратегию под его запросы. Чек-лист Что помогает продукту и бизнесу не развалиться, когда стратегия меняется уже после запуска: 1️⃣ Договориться о единых терминах. Чтобы продуктовые процессы не звучали для бизнеса как «птичий язык». 2️⃣ Связать продуктовые метрики с бизнес-целями Чтобы команда могла объяснять влияние продукта на языке бизнеса. 3️⃣ Провести взаимный онбординг: — продукта в бизнес; — бизнеса в продукт. 4️⃣ Обсудить стратегию развития продукта заранее: — видение бизнеса; — драйверы и барьеры продукта; — допустимые компромиссы; — систему метрик. 5️⃣ Зафиксировать зоны ответственности: — кто принимает решения; — где границы бизнеса; — где границы продукта; — кто подключается в спорных ситуациях. 6️⃣ Планировать не только дорожную карту, но и критерии гибкости. Что команда будет делать, если рынок или экономика покажут другую картину? 7️⃣ Регулярно погружаться в контекст друг друга: — совместные интервью; — просмотр пользовательских сценариев; — участие в операционных процессах; — тестирование продукта своими руками. Потому что в реальности почти ни один запуск не идет ровно по первоначальному плану. По мотивам доклада «Продукт и бизнес на равных: как договариваться и влиять на деньги, приоритеты и общие цели» Алены Медведевой на конференции ProductSense’25. 💙 VK 🖤 YouTube @productsense

Народная карта бензина собрала почти 2 млн посетителей за три дня. Её навайбкодил один человек Бэкенд кое-как держит нагрузку, но от нормальной монетизации автор отказывается из принципа — пока есть только донаты. На фоне топливного кризиса появился ГдеБЕНЗ: народная карта, на которой водители сами в реальном времени отмечают, где топливо есть, где очередь, где машин мало и куда ехать уже бессмысленно. Логика простая до примитива: любой публичной заправке можно выдать эти четыре статуса, никакой регистрации нет, как и отдельного приложения, карта работает прямо в браузере. Один водитель отметил, что бензин появился, второй подтвердил, третий уточнил марку и очередь — и десятки людей рядом уже понимают, где стоит пытаться заправиться, а где нет. За первые дни ГдеБЕНЗ собрал больше 100 тысяч отметок, 2 тысячи добавленных вручную заправок и 80 тысяч установок карты на главный экран. Я поговорил с его автором Евгением Чудовым: судя по присланным скринам из Яндекс.Метрики, у проекта за трое суток — 1,8 млн уникальных посетителей, 3,5 млн визитов и 13,2 млн просмотров. Для сравнения: за первые двое суток было 812 тысяч уникальных пользователей. То есть сегодня у сервиса плюс миллион аудитории. Чудов — маркетолог и предприниматель, основатель биржи рекламы Marketly в каналах MAX. Он ведёт сетку каналов на 2 млн+ подписчиков, сделал популярного бота автопостинга «Отложка» (им пользуются 30 тысяч+ каналов). Думаю, можно сказать, что он запускался не с нуля — у него уже были готовая дистрибуция, как и привычка строить инструменты самому под себя. ГдеБЕНЗ, по его словам, он придумал в самолёте, по приземлении накидал план — и к вечеру всё работало. Сервис собран с помощью Claude. На вопрос про разработку Чудов ответил лаконично: «Токенов не счесть» — за эти дни он спалил почти два недельных лимита тарифа Claude Max (который даёт x20 к обычным лимитам). Конечно, ГдеБЕНЗ работает не идеально. Первые сутки автор прыгал с сервера на сервер, наращивая мощность по чуть-чуть, чтобы сайт работал — потом увеличил ресурсы кратно, но лаги и недогруз карты у части пользователей остаются. Инфраструктура к такому наплыву готова не была, и это нормально для сервиса, которому всего несколько дней от роду. Монетизировать ГдеБЕНЗ Чудов хочет, но «исключительно полезной рекламой»: говорит, скамеры и чёрная реклама уже набежали, и «лучше уйду в минус, чем буду толкать людям грязь». Пока — только добровольные чаевые на сервера. Самым диким событием за эти дни он назвал то, что криптаны на хайпе уже успели выпустить монету «ГдеБЕНЗ», а он к этому не имел отношения — пришлось публично открещиваться. Отдельная примета — каналы ГдеБЕНЗ в MAX и Telegram уже насчитывают десятки тысяч подписчиков. В MAX их больше, чем в Telegram, что косвенно говорит о реальной популярности в регионах, а не только в столично-питерском пузыре. На вопрос, сколько процентов заправок сейчас сталкиваются с нехваткой, Чудов отвечать отказался — по его словам, его и так подозревают, что проект «чей-то» и сделан не из благих побуждений. В одном из постов от ГдеБЕНЗ подробно развенчивалась конспирология, что проект — это OSINT для поиска объектов для нанесения ударов. Ну и из топливных компаний и регуляторов с ним пока никто не связывался; говорит, был бы рад, если бы написали те же Яндекс Заправки. Нечасто случается, что вот прям резко и массово оказываются нужны такие узкоспециализированные коммуникационные сервисы — а когда такая потребность возникает, с инструментами типа Claude Code одинокий вайбкодер закрывает её быстрее, чем любая корпорация. И дело не только в скорости разработки (хотя в большой компании ты такое за три дня не выкатишь), но и в рисках того, чтобы показывать дефицит в реальном времени — сегодня это может быть социально радиоактивно. Бензин из воздуха ГдеБЕНЗ, конечно, не создаёт. Но честно отвечает на единственный вопрос, который сейчас волнует полстраны: ехать или не стоит.

Услышьте гениального интроверта ❤ Защита инициативы в компании часто происходит ярко, с презентацией и красноречивым спикером. Но что, если за всеми красками скрывается посредственная идея? Точно ли вы сможете это увидеть? Мы в Авито опасаемся таких ситуаций и поэтому на защите вместо спича и презентаций принимаем только 6-пейджер. Это шестистраничный текстовый документ, в котором по строгим правилам описана инициатива. Да, это скучно, зато работает гениально: структурирует логику, нивелирует харизму и позволяет сравнивать идеи объективно. 📌 Георгий Степанов из продуктового офиса Авито недушно рассказал о процессе в статье: читайте и берите в работу.

Знаете, от чего прям противно? Вот эти вот прогрессбары, которые движутся не от настоящего прогресса, а с предзаданной скоростью. Типа, чтобы пользователь не пугался. В чем вообще идея прогрессбара? Вот у тебя есть N файлов, ты скопировал M из них, и показал на прогрессбаре M / N × 100%. Ну и ты видишь, сколько работы сделано, а сколько осталось. Некоторые прогрессбары даже время примерное до конца показывали! Потом люди заметили, что иногда прогресс неравномерен. Например, с теми же файлами, большой файл копируется дольше, а прогресс мы считаем по количеству. Тогда на большом файле 1% прогресса будет продвигаться дольше, чем на маленьких. Или скачивание из интренета, там вообще непредсказуемо. Если ты начнешь тут считать время, оставшееся до конца, оно у тебя будет плясать — 30 секунд, полдня, неделя, о, снова 30! Пошли сразу шутки, про 99%, про квантовую природу прогрессбаров и так далее. Но — что важно — отображаемый прогресс был связан хоть с чем-то реальным! Можно было поставить курсор мыши на текущее положение, и если оно через 15 минут сдвинулось, значит программа еще что-то делает, а не зависла. Понятно, что прогресс можно предсказать не всегда. Какая-нибудь установка софта, или, не знаю, обработка фотки плагином, короче, какая-то операция, которая не бьется так легко на N шагов, и в которой не всегда понятно, что такое прогресс. Для таких случаев придумали крутилки и недетерменированные прогресс-бары — это такие, в которых полосы нет, а просто все закрашено паттерном и крутится бесконечно по циклу. Типа, идея та же, операция делается, но сколько там прошло и сколько осталось мы фиг его знает. Это все нормальные идеи. Пока что все хорошо. Элементы используются по назначению, коммуникация честная, претензий нет. А потом какой-то маркетолог, или, может, таролог или астролог, в общем, человек с выдуманной профессией, подумал: смотрите. Допустим, мы логиним пользователя. Это сколько-то времени займет. Сколько? Никто не знает. Может, секунду. Может, десять. Вряд ли больше десяти. Но и не мнгновенно. То есть подождать придется. Так? Так. Это значит что? Что пользователь будет переживать. Надо ему что-то показать. Давайте покажем ему детерменированный прогресс-бар! Программисты сразу такие: ну нет, мы прогресс не посчитаем, там сложно, или еще какое-то му-хрю, расписались в беспомощности. И тут мораль/сила воли/система ценностей, которой ни у кого из присуствующих и не было, дала слабину. «Давайте рисовать прогресс от балды!» — сказали они. За первую секунду закрасим 25%. Равномерно, будем добавлять 1% каждые 40 мс. За вторую закрасим, условно, 20%, за третью 15% и так далее. Как только загрузимся, то сразу дорисовываем до 100%, все же радуются, когда кажется, что куча времени еще осталась, а тут хоба и все сразу сделано! Ну а если не загрузимся за 10 секунд, то последние 5% будем тянуть сколько сможем, по какой-нибудь бесконечно приближающейся асимптоте (я уверен, что на том митинге, где это решили, прозвучало слово асимптота, мне нужно хоть что-то приятное про него представлять, иначе хана). Так родилось самое противное изобретение современного интерфейсостроения — лживый прогрессбар. По сути своей он недетерменированный. Но выглядит как детерменированный. Он намеренно лжет и о совершенном прогрессе, и об оставшемся времени. Лжет прямо вам в лицо и не стесняется этого. Еще и выдает это под соусом заботы о пользователе. А ничо тот факт, что мне, как пользователю, нравилось знать, что происходит? Что мне настоящий прогресс, сколь угодно неравновномерный, дороже любых лживых ваших мультфильмов? К настоящему можно было приспособиться, можно было выводы какие-то делать. Им можно было ПОЛЬЗОВАТЬСЯ. А со лживым можно только пить водку, грустно смотреть и плакать. Хватит прятать от меня компьютер! Хватит кормить меня пустыми обещаниями! Я взрослый человек, я хочу знать, что происходит! Я готов принять любой прогресс, пока он правдивый. А обещаниями своими в веб-интерфейсах друг друга кормите.

По мере того как роли в сферах разработки продуктов, дизайна, Data Science и других сливаются воедино благодаря ИИ, я размышлял о том, как они могут выглядеть в будущем (Boris Cherny, Claude Code) Например, глядя на команду Claude Code, я выделяю пять архетипов: 1. Прототипировщик (Prototyper): генерирует совершенно новые идеи; выдает множество идей, большинство из которых не доходят до стадии реализации. 2. Создатель (Builder) быстро превращает прототип или идею в готовый к эксплуатации продукт или инфраструктуру. 3. Упорядочиватель (Sweeper): приводит в порядок интерфейс, упрощает код и систему, удаляет лишнее, оптимизирует производительность. 4. Развиватель (Grower): берёт уже созданный продукт и дорабатывает его для улучшения соответствия продукта рынку (Product-Market Fit). 5. Поддержка (Maintainer): отвечает за зрелую систему, обеспечивая её безопасность, надёжность, быстродействие и эффективность по мере масштабирования. Многие специалисты совмещают две, а иногда и три роли. Я также заметил, что эти роли не жестко привязаны к должностным обязанностям. Например, в Anthropic есть дизайнеры, соответствующие категориям 1, 2 или 3; то же самое касается инженеров, продакт-менеджеров и специалистов по данным.

Здоровой команде требуется сочетание этих ролей в зависимости от продукта:

- Для нового продукта, ещё не нашедшего соответствие рынку (pre-PMF), нужны люди с сильными навыками типов 1, 2 и 3. - Для растущего продукта, нашедшего соответствие рынку, нужны типы 2, 3, 4 и отчасти 5. - Для продукта с сильным соответствием рынку нужны типы 3, 4, 5 и отчасти 2. Возможно, именно так будут выглядеть продуктовые роли будущего, а не как нынешние узкоспециализированные должности. – 3 основных типа лидеров продукта – Новая структура любого отдела в компании – Командные роли по Белбину

Вспомните свой самый потрясающий клиентский опыт. Который вот прямо «вау». Я вспоминал несколько дней и к моменту выхода поста так и не выбрал подходящий пример. Потому что такой опыт редок. Для его возникновения должны сойтись три фактора, которых нормальный бизнес старается избегать. Ингредиент №1 - катастрофа. Покупатель должен оказаться в по-настоящему затруднительной ситуации. Опоздать на самолет, потерять паспорт, случайно оказаться без денег в чужом городе. В общем – испытать жесточайший стресс. Ингредиент №2 - сопереживание. Сотрудник, которому выпало решать нашу проблему, искренне нам сочувствовал. А не футболил от одного чат-бота к другому, заставляя по пять раз пересказывать одну и ту же историю, теряя драгоценное время. Ингредиент №3, самый главный - саботаж системы. Сочувствующий нам сотрудник не говорит: "к сожалению, ничем не могу помочь, система показывает, что все в порядке, обратитесь лично с паспортом в МФЦ". Нет, он идет на явное нарушение должностной инструкции, закрывает за нами очередь, кому-то звонит, куда-то ходит. В общем - не бросил нас наедине с бедой. Хороший человек. Это парадокс восстановления сервиса - клиент, у которого блестяще решили проблему, становится более лояльным, чем тот, у кого проблем не было вовсе. Однако, должностные инструкции прямо противоречат созданию такого опыта. Их для того и придумали, чтобы, не дай Бог, не переобслужить клиентов. Да и искреннего сочувствия от сотрудников не требуют - иначе повыгорают. Собственно говоря, это и ответ на то, почему мы так редко испытываем прекрасный клиентский опыт. | MAX | подкаст |Treads| X | | Личная жизнь и мысли - Молчанов.Life |

Покажи за 30 секунд — Расскажу про проект, — начал продакт — Лучше покажи В 2008 году стартапер объяснял инвесторам про свой продукт: «Облако, которое использует кроссплатформенный механизм для синхронизации файлов». Они покивали — но денег не дали. Со злости Дрю Хьюстон записал трехминутный ролик: вот файл на одном компьютере — а вот он появился на втором. Никакой инфографики, объяснений, бюджета — просто видео, как живой человек кладет файл в папку. Залил видюшку в сообщество Digg и получил 75 000 регистраций за сутки. С этого начался Dropbox. Семнадцать лет прошло, а мы все пишем лендинги, ищем хитрые ходы, продающие офферы. Но принцип прост — покажи. За 30 секунд станет понятно, чего стоит продукт. Не смотрят — не понимаешь рынка. Не понимают — не знаешь аудиторию. Нет людей — вообще влажные фантазии. 30-секундное видео — это и есть MVP. Попробуй сделать его. «Не все можно показать, — скажет читатель. — Есть сложные В2В-решения; ценность, раскрывающаяся на 3-й месяц; кастомизация...». Это — так. Но тогда возникает вопрос: если не можешь привлечь и удержать 30-секунд внимание клиента, как собираешься повторить этот трюк с его деньгами?!

За кулисами страт.сессий🎭 Сейчас в ИТ-корпорациях в самом разгаре циклы стратегического планирования. Тайминг по рынку классический: - Май-июнь — сборка стратегии - Июль — защита у акционеров - Август-сентябрь — бюджетирование Под сборку стратегии обычно устраивают страт.сессии на 1–3 дня, где заявленная цель — вытащить менеджмент из рутины, сгенерить идеи и упаковать их в стройный план. Но это далеко не полный комплект. Я прошел через десятки таких мероприятий в разных составах. Помимо базовых задач (набросать скелет стратегии, покачать команду друг об друга), начал замечать скрытые эффекты, которые мало кто использует потом. По сути, страт.сессия — это стресс-тест и диагностика команды по трем параметрам. Давайте про каждый. 1. Краш-тест социальных связей Способны ли люди вообще работать друг с другом в замкнутом пространстве? В офисе можно спрятаться за долгими переписками, но здесь время жестко ограничено. Нужно договариваться здесь и сейчас. Если спроецировать скорость взаимодействия этой группы на обычную опер.деятельность - сразу видно, где система будет буксовать. 2. Проверка на масштаб мышления Может ли команда выдавать качественно другие решения? Не «давайте делать то же самое на 10% быстрее», а системно менять: - рынок - ценность - дистрибуцию - монетизацию. На сессиях всегда виден контраст: кто-то челленджит и пушит амбиции, а кто-то отмалчивается в зоне комфорта. Еще один индикатор силы команды. 3. Уровень энергии Горят ли глаза? Слушают ли друг друга? Готовы ли объединяться, чтобы защищать идею? Эти сигналы показывают реальный заряд «батарейки». Если на страт.сессии все вялые и ждут вечера, а дискуссия утопает в телефонных экранах, на этапе реализации чуда точно не случится. А дальше что Дальше используйте всю эту фактуру (связи, амбиции, энергию) для следующих забегов. Качайте команду, развивайте компетенции и направляйте в нужное русло. Главное — смотреть шире флипчартов и стикеров, а там глядишь то, что собрали на страт.сессии и реальность превратится🔥 #продуктовыйпуть.

Google не ждёт смерти поиска. Google сам его меняет Пока многие обсуждают, убьёт ли ChatGPT классический поиск, Google делает гораздо более интересный ход. Он постепенно превращает поиск в AI-ассистента. Сегодня у компании уже два AI-продукта: AI Overviews — готовый ответ прямо над поисковой выдачей. AI Mode — полноценный диалоговый поиск, где можно уточнять вопрос, загружать изображения и вести длинный разговор. Масштабы аудитории соответствуют Гуглу: AI Overviews используют более 2,5 млрд пользователей в месяц. У AI Mode — уже более 1 млрд пользователей в месяц. Понятно, что это использование очень разное и для большинства пользователей заключается в беглом просмотре блока вверху результатов поиска. Но даже проценты из этого могут дать новый большой источник клиентов для любого бизнеса. Для нас, продактов, это новая реальность. С одной стороны — новые риски. Если раньше мы (или наши партнеры из рекламных агентств) пытались понять алгоритмы SEO, то теперь нужно понимать логику LLM, которая ещё менее прозрачна. С другой — появляются новые возможности. Раньше пользователь приходил в Google с набором ключевых слов: “Купить honda click в кредит” Теперь он приходит с настоящей задачей: “Мне нужен первый мотоцикл для ежедневных поездок на работу. Бюджет до 120 тысяч песо, желательно с недорогим обслуживанием и возможностью оформить кредит.” Это уже не поиск страниц или сайтов. Это поиск решения проблемы. Google тоже понимает, что меняет правила игры. Недавно они анонсировали новые инструменты для владельцев сайтов. Правда, при проверке в живом аккаунте сайта, который хорошо проиндексирован Гуглом, оказалось что никаких инструментов пока нет. Пост в блоге — только планы и анонс стратегии. Когда-нибудь в Search Console появятся отдельные отчёты по показам в AI Overviews и AI Mode. Владельцы сайтов смогут увидеть, насколько часто их контент используется генеративным поиском. Кроме того, Google уже тестирует отдельный переключатель, который позволяет отказаться от использования сайта в AI-ответах, не исчезая из обычной поисковой выдачи. Правильный выбор стратегии. Зачем бороться с трендами, если можно адаптироваться и возглавить? Жду, когда появится аналитика. По личным ощущениям — результаты в блоке AI Overviews отлично отвечают на половину поисков и даже нет желания скролить ниже — туда где синие ссылки, за первые места в которых когда-то была война и большие ставки 😉 #aifuture #google #search #producteye