Second brain продакта – как может выглядеть, и как он мог бы функционировать, чтобы нас уже наконец-то можно было заменить AI агентами. Напомню постановку проблемы: одна из основных причин, почему продакты не могут становиться кратно эффективнее за счет работы c AI ассистентами – это то, что для выполнения большей части задач нам нужен полный и актуальный контекст по проектам, над которыми мы работаем. А этого контекста сейчас не сущетсвует в цифровом мире. Давайте представим себе как могла бы выглядеть система, которая эту проблему решает. Хранение информации (second brain) - Для начала нам нужно место хранения информации по проектам, с которым агенту будет удобно работать, и куда он сможет бережно складывать все, что он узнал к текущему моменту, а также ссылки на внешние источники, на случай если ему понадобится более полный контекст. Большинство людей используют для этого Obsidian, потому что markdown файлы – это наиболее нативный для агентов формат текста. - Нам нужны инструкции про то, как работать с основными внешними системами хранения информации, которые мы используем: Jira, Confluence, Google docs, аналитика. Скорее всего это будут skills для нашего Claude, которые могут ссылаться на те же .md файлы при необходимости Система обработки входящей информации Агент должен систематически и автономно читать все важные источники входящей информации, заносить их в наш Second Brain и обновлять текущий статус. (1) Встречи - Допустим у вас прошла встреча и у этой встречи даже есть транскрипт - Агент должен взять этот транскрипт, положить в нашу систему, и разметить все сущности к которым это встреча имеет отношение: людей, проекты, компоненты системы - Затем агент должен понять в какие из этих сущностей нужно внести изменения, чтобы актуализировать статус. Например, отразить новые выводы и договоренности по проектам, которые обсуждались, поставив ссылку на транскрипт встречи, где нужно (2) Мессенджеры и почта - Получается, что аналогичным образом агент должен читать все входящие сообщения из мессенджеров и почты - Про каждое сообщение (или диалог) он должен ответить себе на вопрос, нужно ли внести какие-то дополнения в файл проекта, потому что в сообщении есть новая инфомация - Или добавить новый пункт в план одной из следующих встреч - Или поставить задачу, которую должен сделать подопечный белковый продакт - А чаще всего несколько из вышеперечисленных пунктов одновременно Если представить себе, что написали агентов и процедуры для встреч и мессендеров, то нетрудно будет добавить еще одну точку входа в систему обработки входящих, куда мы будем руками вносить то, что в нее не попало, потому что случилось в устной коммуникации или где-то еще вне систем, которые мы мониторим автоматически. И тогда можно будет рассчитывать на то, что у нас будет существовать тот самый полный и актуальный контекст, который позволит агенту решать действительно широкий спектр задач из нашей рутины, и брать на себя какую-то осмысленную часть работы. Что вы считаете? Утопия? Или через два года уже у всех будет так? Или вы по-другому видите дизайн системы AI-продакт? Делитесь в комментариях.

Иногда лучший инструмент для роста продукта - это ограничения понятных сценариев Представьте себе сценарий: вы организовали встречу, создали для коллег доску с материалами, кидаете им ссылку и приглашаете к совместной работе. Коллега кликает, переходит и начинает работу. Максимально удобная концепция для пользователя, но бесполезная для роста самого продукта. Но как найти те самые сценарии, которые можно ограничить и получить пользу? В этом году в досках, мне предстояло найти новые точки роста продукта, как в пользовательских метриках, так и в деньгах. Сегодня поговорим об ограничениях, которые помогают продавать и растить продукт. Какие ограничения мы ввели в продукте за последние годы? • Ограничение на шеринг ссылок на редактирование в бесплатной команде (шерить можно, но только тиммейтам или на платном тарифе) • Ограничение на количество бесплатных команд (только 1 штука) • Ограничение на количество бесплатных досок (только 3 штуки) Особенно интересно как на продукт повлияло внедрение ограничение на ссылку: 1. Пользователи в момент стали приглашать больше коллег в команды (приглашение работает через почту или специальную ссылку) 2. Количество новых пользователей, которые зарегистрировались в сервисе выросло в 2 раза 3. Мы трекаем период активности новых пользователей, так вот - те, пользователи, которые прошли через сценарий приглашения - чаще активны 4. MAU сервиса за счет изменений вырос на 10% (хотя должен был упасть в рамках летнего периода) 5. MRR продукта вырос на 15% Как именно мы выделили этот сценарий? 1. мы смотрели на сценарии использования досок сверху вниз по дереву сценариев, 2. внедряли те или иные изменения и смотрели на метрики, 3. очень важным было наличие подобных ограничений у конкурентов, 4. но внедрить их одномоментно - нельзя, потому что не ясно будет поведение пользователей. При внедрении ограничения в сценарий Вы должны учитывать гипотезу изменения, например, ограничение потенциально влияет не только на регистрации, а на другие метрики: • conversion to sign-up; • activation rate; • количество приглашений на пользователя; • team creation rate; • долю пользователей, создавших первую доску; • retention; • количество рабочих пространств; • conversion в платный тариф. Смотрите не только на конкретную метрику, но и стройте гипотезу сценария: доска→совместная работа→приглашение коллег→команда→новые доски→новые приглашения Если есть инструменты, которые помогут выделить когорты (например, Mixpanel), то постройте анализ там, чтобы видеть изменения по когортам пользователей. Продолжение следует... в следующей части про активацию пользователей в продукте Черный продакт в MAX

Продуктовый кейс на собеседовании: на что смотрит интервьюер Менеджеров продуктов часто просят решить кейс, чтобы показать свои знания и навыки. Казалось бы, есть CV, метрики и реальные результаты. Зачем тогда кейс, оторванный от реальности? Продуктовый кейс — это не экзамен с верным ответом, а небольшая симуляция вашей будущей работы. Компании важно не просто увидеть решение, но разглядеть за ним вашу систему принятия решений. Далее разберемся, что обычно под этим подразумевают и как это продемонстрировать. Первое — умеете ли вы правильно поставить задачу. Когда кандидат слышит: «В продукте упала конверсия. Ваши действия?», первой реакцией может быть — найти технический баг и вернуть все в нормальное состояние. Но конверсия могла упасть по разным причинам: изменение трафика, баг в аналитике, проблемы на отдельной платформе, изменение цены или статистическая флуктуация. Когда кандидат сразу предлагает решение, он показывает один подход к работе: сначала действовать, потом разбираться. Когда он размышляет глубже, сначала он конкретизирует проблему. Тогда меняется формулировка и дальнейших вопросов, и поставленной задачи. Например, не просто «нам нужно увеличить ретеншн», а: «нужно увеличить ретеншн 30-го дня новых пользователей на рынке X, так как экономика привлечения не сходится». Второе — умеете ли вы декомпозировать проблему. Интервьюеру важно увидеть не количество гипотез, а способность построить модель происходящего. Если падает выручка, можно сразу обсуждать тарифы и промокоды. А можно сначала разложить, из чего складывается выручка, как формируется клиентская база, что происходит с трафиком, конверсией, частотой покупок и средним чеком. Такая декомпозиция показывает, что вы умеете уменьшать пространство неопределенности, а не просто генерировать идеи внутри него. Третье — понимаете ли вы, какой информации вам не хватает. Один кандидат молча делает предположения или, наоборот, задает десятки вопросов подряд. Другой сначала формулирует гипотезу: «Я бы проверил, связано ли падение с изменением трафика или с ухудшением самой воронки. Для этого нужны данные по источникам и конверсии между этапами. Какие они были за последний период?». То есть вопрос появляется из модели проблемы. Вы не собираете все доступные данные, а понимаете, какая информация поможет принять следующее решение. Четвертое — умеете ли вы выбирать. Кандидаты часто хорошо проходят первые 80% кейса: строят дерево метрик, выделяют сегменты, предлагают гипотезы. А потом говорят: «Можно попробовать A, B, C, D и E». Но как понять, что будет сделано в первую очередь? В одном случае кандидат ответит, что выбрал вариант А, ведь под него уже готова система. В другом случае кандидат тоже скажет, что выбрал вариант А, но пояснит, что выбор сделан с учетом скорости реализации и рисков, а также перечислит критерии принятия решения. Для интервьюера это будут два совершенно разных ответа. Здесь проявляется умение работать с ограниченными ресурсами: выбирать с учетом потенциального эффекта, рисков, стоимости и скорости проверки. Пятое — способны ли вы изменить собственную гипотезу. Как и в жизни, в кейсе могут внезапно появиться новые вводные. Например, в середине кейса вам говорят: «оказалось, что конверсия упала только на iOS». Это не столько подсказка, сколько проверка: готовы ли вы перестроить рассуждение или продолжите защищать первоначальную идею. Способность учитывать новую информацию — один из сигналов того, как кандидат будет действовать в реальной работе. В итоге хороший продуктовый кейс проверяет довольно простую вещь: способны ли вы самостоятельно пройти путь

симптом → цель → структура проблемы → гипотезы → данные → выбор → решение → проверка результата

а не сократить его до:

симптом → идея

@productmindset

Рост роли «AI Product Builder» Традиционные PM-роли сокращаются (до 30% в целом и до 70% в SaaS), вместо них растёт гибридная роль Product Builder — человек, который сочетает product thinking, техническую грамотность, дизайн и быстро прототипирует/шиппит с помощью AI. Количество таких специалистов резко выросло. Организации перестраивают весь product lifecycle вокруг AI. В статье Forbes (от 30 июля 2026): «The Rise of the AI Product Builder: The Future of Product Management» репортят что традиционные product managers будут исчезать к 2030 году. По данным 2026 CPO Impact Report от Products That Count: - ставки PM сократились на 30% в целом и на 70% в SaaS. - При этом появилась и быстро растёт новая роль — Product Builder. Драйверы Старое ограничение (стоимость и скорость исполнения) исчезло. Новое узкое место — человеческое суждение: что строить, когда строить и как создавать реальную ценность. ИИ может генерировать требования, прототипы, код, тесты и документацию. Но он не может решить: - решает ли инициатива значимую проблему клиента - соответствует ли она стратегии бизнеса - является ли лучшим использованием ресурсов === Большинство компаний просто ускоряют старые процессы с помощью ИИ → получают лишь инкрементальный эффект. Топы перестраивают весь product lifecycle под возможности ИИ. PM был в основном координатором Product Builder фокусируется на создании outcomes, используя ИИ Большинство организаций всё ещё построены вокруг функций (product / design / engineering с разными руководителями, метриками и процессами). Эти границы становятся всё менее оправданными. Главный вопрос: что происходит, когда важнее становятся capabilities (способности), а не functions (функции)? Что Builder PM не означает Это не «один человек делает три работы (product + UX + engineering) за одну зарплату». Это не промоушен, а часто просто cost-cutting под красивой обёрткой. Хорошие инженеры любят инженерию и не хотят становиться PM. Дизайнеры не всегда готовы писать бизнес-кейсы. Ролевая компрессия имеет пределы. Настоящий Builder PM — это product-менеджер, который умеет использовать ИИ, чтобы стать в разы эффективнее, не отказываясь от того, что делает его ценным. Это не единорог, а 10x PM. Речь о leverage (рычаге), а не о расширении обязанностей. Правильный reframing Вопрос не «как мне теперь заменить инженеров с помощью AI-кодинга?». Вопрос: как использовать ИИ, чтобы стать 3x / 5x / 10x product-менеджером? ИИ удешевил не только building, но и learning. Побеждает тот, кто быстрее учится (рынок, потребности..) Discovery нельзя пропускать Парадокс: в agent-heavy workflow нужно больше живого синхронизирования с инженерами и дизайнерами, а не меньше. Хорошие Builder PM: - регулярно проводят customer interviews (не только на старте) - строят постоянные каналы обратной связи - сознательно защищают время на discovery даже при росте скорости Главный рычаг — feedback loops Большинство команд просто «используют AI-инструменты». Лучшие строят системы, которые сами улучшаются. Пример: fintech-команда добавила в конец каждого ИИ-ответа вопрос «Это было правильно?». Ответ пользователя сразу шёл в обучение модели. ИИ становился умнее прямо в потоке работы пользователей. == 💡Задача лидера — не просто решать, куда вставить ИИ в продукт, а спроектировать всю систему product management, где ИИ создаёт рычаг, где риски, и где feedback loops делают систему умнее со временем. Именно так получается 10x.

Почему один человек не может закрыть все ваши запросы на развитие Когда менеджер продуктов чувствует, что перестал расти, он часто начинает искать «того самого» человека, который поможет ему двигаться дальше и сделать следующий шаг. Того, кто будет давать советы, помогать принимать решения, замечать ошибки, поддерживать в сложных ситуациях, подсказывать карьерные шаги и вообще ускорять развитие. По сути, мы ищем человека, который одновременно станет для нас руководителем, наставником, ментором, коучем и сильным профессиональным окружением. Но проблема в том, что, во-первых, часто такого человека нет рядом. А во-вторых, эти роли крайне редко могут сочетаться в одном человеке. И даже если такой человек существует, он почти никогда не сможет одинаково хорошо играть все эти роли, так как они в чем-то радикально отличаются: руководитель оценивает, а коуч не оценивает. Руководитель отвечает за результат бизнеса, а коуч — за процесс мышления человека. Получается, чтобы решить эту проблему, для начала важно разобраться, кого конкретно вам нужно искать сейчас. Руководитель помогает стать сильнее в текущей роли Он лучше других понимает ожидания бизнеса, знает, каких результатов от вас ждут, где вы пока не дотягиваете до следующего уровня и какие задачи помогут вырасти именно в этой компании. При этом даже очень сильный руководитель редко сможет научить тому, чего сама организация никогда не делала. Наставник помогает быстрее освоиться в новой профессиональной среде Он передает накопленный опыт, объясняет, как устроена профессия, делится проверенными практиками и помогает избежать типичных ошибок новичка. Наставник особенно ценен в начале нового этапа: при смене роли, переходе в новую компанию или освоении незнакомой области. Ментор помогает пройти незнакомые ситуации быстрее Если наставник учит новым правилам игры, то ментор помогает в ситуации, когда правила уже известны, а готовых решений — нет. Он уже сталкивался с похожими задачами и может показать, какие опции обычно срабатывают, а какие приводят к проблемам через несколько месяцев. Задача ментора — не дать правильный ответ, а сократить количество дорогих ошибок за счет собственного опыта. Коуч помогает преодолеть собственные ограничения Когда знаний уже достаточно, а решения все равно не принимаются, причина часто не в недостатке опыта: иногда она в привычных моделях мышления. Коуч помогает увидеть, что именно мешает двигаться вперед: избегание конфликтов, страх ошибок, стремление все контролировать или другие внутренние ограничения. Также он работает с неопределенностью и помогает выстроить план дальнейшего движения, опираясь на особенности человека. Сильное окружение помогает перенимать способ мышления сильных специалистов Мы растем не только тогда, когда нас учат напрямую. Каждый день мы наблюдаем, как опытные коллеги принимают решения, спорят, формулируют вопросы, признают ошибки и работают с неопределенностью. Именно поэтому сильная команда нередко дает больше профессионального роста, чем очередной курс или книга. Заметим, что почти все эти способы развития объединяет одна вещь: они требуют не новой информации, а взаимодействия с другими людьми. Знания — лишь один из механизмов развития (поэтому следующая книга далеко не всегда помогает решить проблему роста). Не меньшее значение имеют качественная обратная связь, чужой опыт, работа с собственными ограничениями и ежедневное взаимодействие с людьми, которые думают иначе и сильнее вас. Возможно, вам сейчас нужен не еще один курс. И даже не «идеальный ментор». Возможно, ваше развитие начинается с диагностики собственного дефицита. Тогда стоит задать себе вопрос: «чего мне сейчас не хватает для следующего шага?» И уже потом становится понятно, кто именно способен помочь закрыть этот дефицит: руководитель, наставник, ментор, коуч или сильное окружение. @productmindset

Стоит ли стремиться в Anthropic/ OpenAI? Все чаще я слышу от знакомых продактов: вот бы попасть в Anthropic / OpenAI! Работа в frontier AI labs для многих стала голубой мечтой - как когда-то все хотели в FAANG, а потом в Airbnb/ Notion/ Dropbox / нужное подставить. Но реально ли это “работа мечты”, или просто очередное “модное” место? Хочу поразмышлять с вами вместе. И начнем, конечно, с главного вопроса - а зачем вообще туда идти? Я вижу три основные причины: 1) Опыт. Конечно, если ваша специализация - AI PM, никаких вопросов нет: мало где в мире можно получить подобный опыт работы с инновационными технологиями в топовых командах. Другой вопрос, что продактов с такой специализацией не так уж много: у 95% совершенно другой карьерный фокус, да и интересы, если уж на то пошло. Если мы говорим про, например, growth PM или security PM, тут • и позиций в Anthropic / OpenAI будет сильно меньше, • и еще вопрос, если продуктовый опыт именно в этих компаниях даст более сильный толчок для развития, чем в других. С другой стороны, есть еще опыт, не привязанный к роли: как в компании построен процесс, культура, оргдизайн (в свое время я именно по этой причине пошла работать в Intercom). Это точно будет ценно, пусть и менее осязаемо. 2) Престиж. Подобная строчка в резюме, вне зависимости от позиции, точно привлечет внимание рекрутеров, а, при предпринимательских амбициях, - и инвесторов. Личный бренд тоже однозначно получит буст: будет легче получать приглашения на конференции, а также продавать инфопродукты. Вопрос в том, какие конверсии будут дальше по воронке :) Я собеседовала не одного продакта из Гугла или Меты, которые не справлялись с самыми базовыми вопросами. Я знаю не одного начинающего фаундера с громкими титулами, которому не удавалось поднять инвестиции или, что важнее, построить работающий бизнес. Бренды, которые у всех на слуху, открывают двери, но вот что происходит дальше, ни один бренд не решает. 3) Зарплата. А вот тут интересно: если посмотреть на общую компенсацию продакта из Anthropic/OpenAI, то получается цифра около $800k-$1M. Это выше, чем, например, компенсация в топовые компании на роли того же уровня: например, в Google или Airbnb можно ожидать около $500к. Но загвоздка в ликвидности. Базовая зарплата в frontier AI labs около $250-350к - что как раз соответствует рынку. Основная часть компенсации - equity, и это поднимает сразу несколько вопросов: - по сравнению с FAANG, это приватные компании: то есть, надо ждать либо IPO, либо secondary sale, чтобы реализовать продажу - это цена по оценке на текущий момент: верим ли мы, что она продолжит карабкаться вверх, или же что в какой-то момент окажется слишком раздутой и упадет? - по отзывам ребят, которые недавно устроились работать в OpenAI / Anthropic, такое количество стоков никому уже не дают. С ростом компаний (а в них уже 4+ тысячи сотрудников) можно ожидать, что эта часть компенсации сильно снизится. Так стоит ли пытаться попасть в Anthropic/ OpenAI? Давайте возьмем гипотетического продакта с 8 годами опыта и классными достижениями в резюме, но без AI экспертизы. На текущий момент ему будет очень сложно конкурировать за желаемую позицию: по оценкам, менее 1% кандидатов доходят до оффера от топовых AI компаний. Значит, надо будет усиленно вкладываться в образование и минимум следующие 3-4 года нарабатывать подходящий опыт. Но за это время: - могут появиться другие, более хайповые игроки - компенсация явно будет уже не такой вкусной - и итого вполне может быть сравнима с опцией «продолжить инвестировать в свой текущий опыт» и либо расти по уровню в big tech, либо зайти рано в новый модный стартап, который вырастет в единорога. В общем, я бы здесь отталкивалась от вашего интереса и «сложного процента»: какой опыт в моей карьере усиливает мое общее портфолио и USP? Но, если у вас уже релевантный опыт, и вы выбираете между Anthropic и условным Netflix/Uber, конечно, сейчас имеет смысл идти в Anthropic 😅 А вы что думаете?

Суперпозиция — это (не)Знание того, что мы ⇄ рынок ⇄ мир ⇄ Вселенная ещё не выбрали – Это (не)Знание (внутренний и внешний спор) идёт в двух направлениях: "мы не знаем, будет ли это востребовано, потому что мы недостаточно исследовали" (незнание в нас) vs "мы не знаем, потому что рынок сам ещё не решил (потому что всё вокруг возникнет только из взаимодействия наблюдателя и наблюдаемого" (незнание в мире)).

Главная ошибка – выбирать "давайте проведём больше рисёрча" там, где рынок-мир-пространство ещё не знают помнят о проблеме

– Любая фича до своего релиза — это ничто, бесконечное пространство (не)возможных вариантов-кейсов-ситуаций и механик, которое схлопывается в реальность(и) только в момент, когда юзер её начал наблюдать. Наблюдение происходит тогда, когда Нечто постучалось в реальность памяти, и это Нечто резонирует со структурой памяти. Память – это паттерны-фракталы-артефакт(ы) В продукте фича "случается" для пользователя, только если модель продукта резонирует с его существующей ментальной памятью. В ином случае, продукт будет говорить на языке, для которого у памяти пользователя ещё нет структуры распознавания, а всё неизвестное, что происходит в вашем продукте и что не удержал пользователь, бессознательно сохраняется в сознании-памяти пользователя, потому что функция сохранения и есть определение памяти. И всё что пользователь не понял в вашем продукте, он с некоторой вероятностью сможет вспомнить и понять в продукте ваших конкурентов. Наблюдатель и наблюдаемое про вложенность, а не различные объекты

Структура продукта = структура команды = структура мира-рынка и ЦА, которая его наблюдает и строит

Продакт, пытающийся "объективно" (хаха) оценить архитектуру продукта, сам же стоит внутри того же контура, который оценивает (он оценивает сам себя, являясь частью единой Системы), но никак не наблюдателем и наблюдением снаружи. Правильное наблюдение расширяет и сужает пространство решений одновременно. Правильный внутренне-внешний рисёрч работает так же, не просто сужая 100% гипотез до 20%, а расширяя(!) оставшиеся 20% до потенциала 100%. Наблюдение это предсказание и вы можете предсказывать на основе того, что помните

7 вопросов для руководителя продукта Рост в роли начинается не с новых задач, а с изменения способа мышления. Пока менеджер продуктов смотрит прежде всего на свою фичу, метрику или команду, руководитель продукта оценивает всю систему: куда движется бизнес, где находится главное ограничение и как распределить ресурсы так, чтобы получить максимальный результат. Иногда изменить действия сразу сложно. Но можно начать с вопросов, которые вы задаете себе перед принятием решений. 1️⃣ Какую задачу бизнеса мы на самом деле решаем? Руководитель продукта не останавливается на пользовательской боли или идее новой функции. Он связывает каждую инициативу с результатами бизнеса: ростом выручки, удержанием, маржинальностью, качеством сервиса или снижением рисков. Полезная функция еще не обязательно является важной для компании. 2️⃣ Почему именно эта задача сейчас важнее остальных? Почти любая идея может выглядеть полезной, но ресурсы команды ограничены. Поэтому важно оценивать не только потенциальный эффект инициативы, но и то, от чего придется отказаться ради нее. Руководитель думает не только о том, стоит ли делать задачу, но и о том, является ли она лучшей инвестицией времени команды прямо сейчас. 3️⃣ Это локальное улучшение или изменение системы? Рост одной метрики может привести к ухудшению других частей продукта. Например, увеличение количества заказов может повысить нагрузку на поддержку, ухудшить качество услуги или снизить маржинальность. Руководитель оценивает влияние решения на весь пользовательский путь, экономику продукта, операции и другие команды, а не только на конкретный показатель. 4️⃣ Где находится настоящее ограничение роста? Команда может долго улучшать интерфейс, хотя продукт ограничен недостатком трафика, высокой ценой, низким качеством сервиса или нехваткой операционных ресурсов. Задача руководителя — найти не самое заметное несовершенство, а узкое место, которое действительно не дает бизнесу расти. И разобраться, в чем именно ограничение. Например, мы говорили об этом в одном из наших постов. 5️⃣ Что должно быть правдой, чтобы наша стратегия сработала? Любая стратегия строится на допущениях. Например, что пользователи будут чаще возвращаться, новый канал привлечения окажется рентабельным, а операционная модель сможет масштабироваться. Этот вопрос помогает отделить обоснованную стратегию от набора ожиданий и надежд и заранее увидеть самые рискованные предположения. 6️⃣ Правильно ли распределены ресурсы между текущим ростом и будущими ставками? Если вложить все в текущие метрики, бизнес может исчерпать потенциал основного продукта и остаться без новых направлений; если чрезмерно увлечься экспериментами, начнут страдать качество, экономика и стабильность текущего бизнеса. Поэтому стоит спрашивать не только «что даст результат сейчас?», но и «какие ограничения уже тормозят нас?» и «за счет чего компания будет расти через год?». Верный вывод появляется, когда руководитель видит не отдельные инициативы, а весь портфель и последствия перекоса в любую из сторон. 7️⃣ Может ли команда принимать хорошие решения без моего постоянного участия? Руководитель продукта не должен становиться обязательным участником каждого обсуждения. Его задача — создать среду, в которой команда понимает цели, ограничения и критерии выбора. Сильная система управления проявляется в том, что качественные решения принимаются даже тогда, когда руководителя нет на встрече. Знание фреймворков, количество запущенных фич и точность роадмапа часто кажутся главными признаками профессионального роста. Но уровень руководителя проявляется прежде всего в качестве решений: умении видеть систему, выбирать главное, распределять ресурсы и создавать самостоятельные команды. @productsense

Цикл поиска продукта на основе 100 интервью Пример реализации ф-ции /loop для продактов. 6 этапов, каждый из которых питает следующий: Шаг 1: Извлечение → распределите по одному агенту, работающему по упрощенной модели, на каждое интервью ; каждый предоставит структурированные возможности, описания персонажей и дословные цитаты. Ограниченная, повторяющаяся работа: хайку или сонет, а не опус. Шаг 2: Канонизация → один агент группирует исходные возможности в канонический набор. Экстракторы придумывают новую метку для каждого интервью, поэтому одна и та же потребность возникает под десятком названий; объединение синонимов — это вопрос субъективной оценки, поэтому это модель, а не код. Шаг 3: Оценка возможностей → код ранжирует каждую каноническую возможность по частоте × важности × (5 - удовлетворенность). Модель не выполняет математические вычисления. Шаг 4: Генерация и сортировка → для наиболее эффективных вариантов агент генерирует несколько идей решений ; затем отдельный эксперт оценивает каждую из них по показателю ROI (влияние против затрат на разработку) и оставляет 3 лучших для дальнейшей разработки. Показатель ROI меняет порядок в списке, поэтому недорогая, но эффективная задача может занять место для разработки, освободив его от задачи с более высоким баллом. Шаг 5: Разработка → Для 3 лучших идей по ROI агент использует навыки фронтенд-дизайна, чтобы написать уникальный, кликабельный HTML-прототип, который я могу открыть. Шаг 6: Проверка и повторный запуск → проверка выявляет любой прототип, который не удалось отобразить, или любую извлечение данных, показавшее низкую степень достоверности, и рабочий процесс повторно запускает только этот этап. Это и есть настоящий цикл: результат одного этапа определяет, будет ли повторно запущен предыдущий этап. === 113 агентов потратили 1,95 млн токенов за 12,5 минут. 3 из 3 прототипов были созданы и проверены. JavaScript-код, отвечающий за маршрутизацию, оценку, контроль и зацикливание, не потратил ни одного токена модели.

Кейсы, кейсы, кейсы Обещал написать подробно про AutoTrader в своем втором канале. Написал, но забыл рассказать здесь об этом. Сейчас исправим. В этом кейсе много интересных уроков для продактов, несмотря на время, которое прошло с момента запуска этого динозавра из мира авто маркетплейсов. Во-первых это история про фокус. Команда всегда ориентировалась на потребности своих партнеров дилеров, что помогло создать лучшую базу для покупки автомобиля в США. И это привлекло огромную аудиторию покупателей. Во-вторых, они хорошо понимали, что без сильного бренда невозможно завоевать доверие аудитории и активно инвестировали в маркетинг. А присоединение к COX Automotive помогло использовать накопленный опыт и встроить свои рекламные инструменты в платформу, которая является выбором по умолчанию среди большинства крупных дистрибьютеров авто и финансовых организаций. Делали здесь: https://t.me/product_case_every_day/122 Ещё можно почитать: 📌 Анти-кейс Temu, который эксплуатирует все дыры психологии покупателей, чтобы продавать товары на 92 млрд долларов в год 📌 Кейс молодого стартапа Govar, который нашел новый канал монетизации через легальную продажу пользовательских данных и смог выйти из долины смерти 📌 Разбор успеха Fireflies, который опередил своё время в транскрипции встреч, но усилил свои позиции с приходом LLM технологий #cases #marketplaces #b2b #learnings

Как описывать опыт, если у вас “обычные” задачи без громких кейсов 👌 Давайте представим, что я обычный Middle Product Manager, который работает в небольшой и никому неизвестной IT-компании. Я не работал с огромной аудиторией и не запускал продукты, которые завоевывали рынок. Я просто выполнял свои задачи, и сейчас я выхожу на поиски новой работы. Но что же мне писать про свой опыт в резюме? 🧐 Ищите изменения, а не достижения Главная ошибка – пытаться найти в своем опыте громкие достижения: рост выручки на 300%, запуск на миллион пользователей или выход на новый рынок. Вместо этого подумайте, что изменилось после вашей работы. Что стало быстрее, дешевле или удобнее? Что появилось в продукте? Какую проблему бизнеса или конечного пользователя вы решили? 🔎 Раскапывайте обычные задачи Допустим, вы проводили исследования пользователей. Само по себе это ничего не говорит о вашем опыте и результативности. Но зачем вы их проводили? Что выяснили? Какое решение приняли и что изменили в продукте? Например: пользователи не доходили до первого целевого действия → вы провели исследования и нашли проблему в онбординге → пересобрали сценарий → увеличили конверсию в активацию на 12%. 😥 А если нет метрик? Сначала убедитесь, что их действительно нет. Часто в процессе копания с клиентом выясняется, что после запуска сократилось время обработки заявки, стало меньше обращений в поддержку или выросло количество пользователей определенного сценария или команда разработки стала быстрее закрывать таски. Если цифр правда нет, показывайте масштаб и сложность задачи: сроки реализации, количество пользователей, размер команды, сложность интеграций, перестроенные процессы или ограничения, с которыми вы работали. Не обязательно каждый пункт резюме заканчивать на +20% GMV. 📌 Как правильно описать свои достижения? А это я детально описал еще в 2024 году в статье для ТЖ “Что такое профессиональные дости­жения и как указать их в резюме?” С тех пор ничего не изменилось в подходе описания достижений.

Ключевой вывод: Скорее всего, кейсы у вас уже есть, просто вы привыкли считать их обычной работой! Копните поглубже в свой опыт и задайте себе вопрос “Зачем я это делал и к чему это привело?” и уже от этого отталкивайтесь в описании своего опыта.

В комментариях можете поделиться своими достижениями – вместе поправим формулировку, если нужно 🫶

Кастомный фичеринг Катите какую-то новую штуку в продукте, подумайте как о ней узнает пользователь. Но не все фичи нужно сопровождать попапами, всплывахами и рассылками. Одна из таких в Яндекс Навигаторе попалась мне на днях. Ребята подсвечивают куда смотрят камеры. Синее поле - если ты в допустимом скоростном режиме и красное, если превышаешь. Узнал об этой функции нативно, стоял на светофоре, смотрю какое-то поле показывают. Думаю о как круто, вау эффект и лояльность продукту. То есть, мне, как водителю, не нужно дополнительно объяснять, что это и зачем. Очевидная функциональность без доп.промо, кайф. Выбор делать фичеринг или нет решается через простые ux тесты на небольших выборках. Дал целевым респондентам задачку с новой функцией, посмотрел справляются или нет, принял решение. Хорошо же❤️ #юиксюайное

Запись подкаста "Директор бренда", где говорили про 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

Клиент не сказал ни одного «да». И это была лучшая встреча за месяц На прошлой неделе собрал звонок: я и двое фаундеров, участники клуба MFS, Саша и Стас. Саша делает базу данных для AI-стартапов — она удешевляет хранение данных и ускоряет поиск. Стас — основатель HR-tech с enterprise-клиентами. Идея простая — прокастдевить Стаса как потенциального клиента Саши. Посмотреть, где болит, и понять, ложится ли туда продукт. Пошло не по плану. Уже к третьей минуте Саша начал рассказывать, какой у него классный продукт, сколько он сэкономит на инфраструктуре и как легко на него переехать. Стас — отвечать возражениями. Сижу и понимаю: это уже не кастдев, это переговоры, на которые Стас вообще-то не приходил. Пришлось вмешаться: ребят, стоп, мы тут ничего не продаём. Саша — «а я и не продаю». Стас — «нет, ты продаёшь». Но в итоге именно из этой перепалки вышло самое ценное. Стас поделился, что у него за последний год прилетели контракты по 350к евро с процедурой закупки по девять месяцев. В сделках такого масштаба IT-блок клиента согласовывает весь стек вендоров — если видит незнакомый продукт, просто говорит «нет», и сделка, за которую боролись почти год, просто слетает. Например, один крупный клиент без ISO 27001 поставил сделку на холд. Поэтому Стасу на текущем этапе развития плевать на экономию токенов и любую оптимизацию, которую предлагал Саша, — единственное, что для него важно, чтобы ничего не угрожало сделкам. Дальше Стас прямо сформулировал, как у него внутри устроено принятие решения: CTO смотрит на технологию, Head of Sales — на возможные угрозы для плана продаж, и ему вообще всё равно, сколько продукт экономит компании. Если хоть один скажет «нет» — сделки не будет. Два покупателя, и говорить с ними нужно на разных языках. В концу разговора Саша сказал, что цель встречи выполнена — узнал ровно то, за чем приходил. Хотя за весь звонок Стас не сказал ни одного «да». Зато накидал десяток возражений, которые для раннего стартапа могут быть ценнее чем продажа. Андрей Резинкин | Money For Startup

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

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

По мере того как роли в сферах разработки продуктов, дизайна, 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 основных типа лидеров продукта – Новая структура любого отдела в компании – Командные роли по Белбину