Как оценить продакта Мне очень часто задают вопрос: «Егор, ну твой канал это же лукавство. Понятно, что есть бесполезные продакты, но есть же и полезные, которые нужны. Только как понять, какой перед тобой продакт?». Поэтому я решил составить тест на полезность продакта, основываясь на своем многолетнем опыте собеседования и работы с продактами. Он довольно простой: отвечаете на вопросы и суммируете баллы. Все вопросы выстраданы на личном опыте. Если вы продакт, сможете реалистично понять свой уровень. Если вы не продуктовый менеджер, можете задать вопросы из этого теста своему продакту и оценить его. Можете использовать тест на собеседованиях. Знание SQL Не знаю: 0 баллов Знаю базовые запросы: 1 балла Умею на продвинутом уровне: 2 балла Опыт проектного менеджмента Меньше 1 года: 0 баллов 1-3 года: 1 балл От 3 лет: 2 балла Количество неудачных проектов за плечами 1-2: 0 баллов 3-5: 1 балл Больше 5: 2 балла У вас есть опыт в закупке трафика (MyTarget, AdWords, рекламные сетки) Нет: 0 баллов Да: 1 балл Был опыт запуска своего проекта Нет: 0 баллов Да, неуспешного: 1 балла Да, успешного: 2 балла Вы обучались на инженерную специальность Нет: 0 баллов Да: 1 балла Вы наизусть знаете юнит экономику своего текущего проекта Нет: 0 баллов Да: 1 балл У вас был опыт самостоятельной настройки системы аналитики (Google Analytics, Amplitude, etc) Нет: 0 баллов Да: 1 балл У вас есть опыт в продажах какого-то продукта Нет: 0 баллов Да, до 1 года: 1 балл Да, больше 1 года: 2 балла Опыт работы продактом До 3 лет: 0 баллов 3-5 лет: 1 балл Больше 5 лет: 2 балла Сколько мест работы у вас было за последние 3 года Больше 3: 0 баллов 2-3 места работы: 1 балл 1 место работы: 2 балла Считаем результаты 0-18 баллов: К сожалению, вы не нужны 19-25 баллов: Вы хороший середнячок, через несколько лет есть все шансы стать отличным продактом 26 и более баллов: Мое почтение, вы тот самый человек, который способен принести пользу бизнесу

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

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

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

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

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

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

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

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

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

50 самых полезных ресурсов для продактов ProductMap - Большая карта знаний и навыков PM: от discovery и аналитики до AI и leadership. Product Compass - Один из лучших структурированных наборов PM-frameworks и competency maps. ProductDo Skills Map - Визуальная карта навыков продакта по уровням и направлениям. Ravi Mehta PM Toolkit - Сильный competency framework для оценки и развития PM. PMwheel - Удобная модель self-assessment и развития продуктовых навыков. GitLab PM Competencies - Реальная корпоративная система уровней и ожиданий от PM. Intercom PM Ladder - Хороший пример карьерной лестницы от PM до senior-level ролей. Reforge - Глубокие материалы по growth, retention, monetization и strategy. Mind the Product - Огромная библиотека статей, кейсов и выступлений по Product Management. SVPG - Marty Cagan: empowered teams, discovery, strategy и product operating model. Lenny’s Newsletter - Практические разборы growth, marketplaces, AI, leadership и product strategy. Product Talk - Teresa Torres: Continuous Discovery, OST и работа с assumptions. Strategyzer - Business Model Canvas, Value Proposition Canvas и тестирование бизнес-гипотез. GoPractice - Одна из сильнейших баз по продуктовой аналитике, retention и unit economics. GoPractice Simulator - Практический симулятор продуктовой работы с метриками и решениями. Product School - Большая библиотека guides, templates и PM-материалов. The Product Folks - Кейсы, frameworks, teardown’ы и материалы для развития product sense. Hustle Badger - Хорошая база по strategy, JTBD, PRD, discovery и product org. PM Skills Marketplace - 100+ готовых AI-native skills и workflows для Product Management. prodmgmt.world - AI-native PM OS: skills, frameworks, workflows и агенты. Productboard Resources - Customer insights, prioritization, roadmap и product operations. ProdPad - Lean roadmaps, outcomes, discovery и product strategy. airfocus - Prioritization, discovery, strategy и Product Ops. Aha! Product Guide - Очень большой системный справочник по Product Management. Jira Product Discovery - Практики работы с ideas, insights, prioritization и discovery → delivery. Pragmatic Institute - Market-driven product, positioning, pricing и GTM. Product-Led Alliance - PLG, activation, adoption, onboarding и retention. Growth Unhinged - Очень сильный контент по SaaS growth, pricing и monetization. First Round Review - Подробные кейсы стартапов по продукту, growth и management. YC Library - PMF, MVP, пользователи, growth и запуск стартапов. Sequoia Articles - Стратегия, рынки, PMF и построение компаний. a16z - AI, SaaS, marketplaces, fintech и новые продуктовые модели. CXL - Experimentation, CRO, analytics и behavioral science. Demand Curve - Практические growth playbooks по acquisition и retention. Growth.Design - UX-разборы известных продуктов через behavioral psychology. Built for Mars - Очень подробные UX teardown’ы реальных продуктов. Nielsen Norman Group - Фундаментальная база по UX, usability и research. Dovetail - Интервью, research synthesis и работа с customer insights. Maze Guides - Usability testing, prototypes и continuous research. Hotjar - Behavior analytics, funnels, user feedback и customer journeys. Mobbin - Огромная библиотека интерфейсов сильных digital-продуктов. Page Flows - Реальные onboarding, checkout, subscription и другие user flows. UserOnboard - Классические разборы onboarding известных продуктов. Amplitude Academy - Бесплатное обучение funnels, retention, cohorts и analytics. Amplitude Blog - North Star, activation, retention и experimentation. Mixpanel Blog - Практическая продуктовая аналитика: funnels, cohorts и retention. ChartMogul - Одна из лучших баз по SaaS-экономике: MRR, NRR, CAC, LTV, churn. Shape Up - Сильная альтернатива backlog-driven разработке: shaping, appetite и betting. ChatPRD - AI-помощник для PRD, discovery, requirements и PM-документов. Atlassian Team Playbook - Практики для alignment, decision-making, goals, retrospectives и командной работы.

Почему AI агенты не делают продакта эффективнее Если вы всерьез пытаетесь делегировать *значимую* (значимую – это такую, без которой не обойтись, а не какую-то фигню, которую вы до этого не делали, и без этого никто не страдал) часть своей продуктовой работы агенту, то вас будут ограничивать две вещи: - интеграция агента с рабочими системами (то есть, наличие MCP и прав доступа) - информационный контекст. Про интеграции мы с вами уже немного поговорили – это ад, особенно для корпоративных систем, где безопасники несут вахту. Но это ад предсказуемый, который мы в горизонте пары лет скорее всего победим. Давайте сегодня поговорим про то, почему у агента не хватает контекста, чтобы решать ваши рабочие задачи. Для того, чтобы сделать почти любое осмысленное действие по проекту, агенту нужен будет полный и актуальный статус. Что уже случилось до текущего момента, и какие дальнейшие шаги ожидаются. Но актуального статуса проектов нигде не существует в готовом виде! - Где-то на диске лежит PRD, но он потерял актуальность в тот момент, когда над проектом пошла активная работа - В Jira есть задачи даже со ссылками на коммиты, но это лишь часть истории - Есть расшифровки встреч (но не всех), оттуда попробуй извлеки точно о чем стороны договорились - Есть чатики в корпоративном мессендежре: личные сообщения, канал команды, чатик проекта (тут я передаю пламенный привет любителям создавать новый чатик с рандомным набором участников на каждый чих. В аду для вас уготован отдельный котел, который будет называться "Алексей Иванов, Иван Пертров, Елена Головач... и др.") - И если до этого пункта у вас еще теплилась надежда, что все это можно как-то структурировать и организовать, то в этот момент мимо вашего стола проходит разработчик и говорит "Кстати, по задаче, про которую ты спрашивал – она заблокинована, мне нужно прокинуть название use case из upstream сервиса", и окончательно убивает надежду. Этот самый полный контекст проекта поразительным образом существует у вас в голове, потому что ваш мозг, получая каждый новый сигнал, обновляет текущий статус. Но как только я сажусь делегировать задачу AI ассистенту, я осознаю, как много информации либо вообще не отражено в цифровом мире, либо погребены в такой помойке human слопа, что и за сто тысяч токенов не извлечешь. И это, на мой взгляд, наибольший барьер внедрения AI в рабочие процессы продакта на данный момент. Это то, почему продакт, приручивший Claude, пока не может значительно выигрывать у своего коллеги-луддита с блокнотиком и карандашом. Расскажите в комментах ощущаете ли вы тоже эту проблему и как с ней боретесь? На мой взгляд решение может выглядеть как second brain система. В следующем посте я порассуждаю о том, как она могла бы выглядеть и что уже удалось построить.

Что с рынком труда в ИТ в 2026: глобально и по регионам Посидела в свежих отчётах и собрала картину по регионам: по продактам, и по ИТ в целом. Спойлер: картина, скорее, позитивная. Глобально. - Рынок продактов на подъёме: 26 900+ открытых PM-ролей, в 2.3 раза больше, чем в 2023. - Главный драйвер AI: 61% вакансий требуют AI-опыта, премия за него 15-30%. - По ИТ в целом та же картина. Единственное, что растёт без оговорок, это всё вокруг AI: у крупных компаний таких вакансий на 50-100% больше, чем год назад. Быстрее всех набирают финтех и security, есть компании, почти удвоившие штат за два года. США. - Найм растёт: вакансии разработчиков за год в плюсе, топ-компании нанимают на 20% больше, чем год назад. - Но рынок жёстко расслоился. AI-продакты получают ~$245k против ~$123k у традиционных PM. В два раза! - География концентрируется: 23% всех открытых PM-ролей в Bay Area. Европа. - Самый противоречивый регион. По разработчикам вакансии выросли только в Британии, Германия и Франция в минусе. Нанимают в основном компании с американскими штабами. - У продактов вакансий больше (+33% г/г), но фактический найм упал на 14%. То есть постят много, нанимают долго и придирчиво. - Своим при этом повышают зарплаты активнее любой другой функции (+5,2%): дешевле удержать, чем искать. - Ориентиры мидла: UK £67k, Германия €71,5k, Нидерланды €70,3k, Франция €63,7k, Испания €54k. Россия. - Рост ниже инфляции. По данным Хабр Карьеры (45 000+ реальных окладов, июль 2026) медиана по ИТ 191к ₽, +4% за полугодие при инфляции 4,5-5,5%. - Продактам не досталось совсем: зарплаты в менеджменте показали ноль роста за год, премия ушла смежным ролям (техподдержка +10%, маркетинг +9%). - Ориентиры: менеджеры в ИТ получают 260к ₽ в Москве, 200к в Питере, 152к в регионах. Индия и Канада самые горячие. Индия +42% г/г по продактам, причём рост тянут не стартапы, а мид-сайз и корпорации. Канада +67% г/г. Удалёнка. Глобально remote-ролей +43% г/г, но США выбиваются: только 7% AI-продактовых ролей там полностью удалённые. В Европе гибрид 2-3 дня в офисе стал дефолтом. Вывод: везде плюс/минус одно с разными акцентами. Рынок награждает специализацию, AI-навыки и senior-опыт. А где не награждает, как в России, там стагнация для всех. Генералистам тяжелее всех, в любом регионе и в любой роли. В следующем посте расскажу, что вижу сама на практике, как обстоят дела у менти и как конвертятся мои отклики. #PG_education

СРО жалеет о существовании профессии продакт-менеджера У Лении вышел подкаст, где СРО Том Веррилли (ex-Twitch, ex-Twitter) о том, как ИИ обнажает масштабы «продуктового театра» Тезисы:

- управление продуктом — это навык, который приобретается на практике, а не просто должность, и иногда командам лучше, когда инженеры и дизайнеры принимают решения самостоятельно - системное мышление становится всё более востребованным - главная польза ИИ для продакт-менеджеров сейчас заключается в Data Science, а не в прототипировании - лучшие менеджеры по продукту сосредотачиваются на технических деталях, понимании клиентов и принятии решений - Роль смещается от «политики» и «совещаний по согласованию» к отдельным специалистам, которые выполняют реальную работу и углубляются в детали продукта - Для роста следует думать о том, как система работает в масштабе, представить все возможные проблемы, а затем исправить их до того, как они произойдут - При найме сотрудников ищите людей, которые могут защитить свои идеи, используя данные, а не тех, кто просто умеет говорить и заводить друзей - Любимая ошибка Верилли за карьеру — доверять средним показателям. Фичу с 3 процентами использования легко списать как бесполезную. Но для этих трёх процентов она может быть единственным сценарием использования продукта. Отключил фичу — обрушил чей-то бизнес.

Вообще не осталось продакт-менеджеров, которые бы не упоролись напрочь в нейросети. Мне кажется это какие-то неправильные менеджеры, кто этого еще не сделал. Поэтому я и веду свой второй канал @gleb_pro_ia, и делаю это примерно в 100 раз активнее, чем этот. Чего-то высасывать из пальца при этом тоже не хочется. И я все думал. а про что ж писать тут? Решение висело под носом. Тут уже написано в заголовке про бизнес, значит буду продолжать писать про бизнес. Пусть и с нейросетевым уклоном, так как без этого сейчас ну вообще без вариантов. А на втором канале продолжу исповедовать гонзо-журналистику про то, каких агентов я потрогал сегодня, и как они меня возблагодарили в ответ.

Июльский дайджест продактов звучит жарой и светом её Солнца – От лошадей к стартапам – Цена фичи – Contextual Product Management – Про «чтобы что» – Закон Фолкленда – Закон Брукса – Правило 7% – 3 Истины Систем – Главное из AEO – Зачем продукту видение – Be NICE – Diff-in-Diff: A/B-тест невозможен – Process Communication Model – Как перестать быть незаменимым – The truth about being a manager – Что проверять в AI-продуктах – Немного про контрольные карты – Scream-тест продукта – Суперпозиция продукта – Токен ↔ Человек – Метод CRISP для PRD – Валидация — мираж – Культура загнивает незаметно – Как проектировать UX AI – Чатоцентричный интерфейс – Играем в «Оракл» с продуктом – ИИ внушает ложную уверенность – Book: Product Design Psychology – Гайд: Метрики UX – The Layers of AI experience – Симулятор сотрудника FAANG – Каталог когнитивных искажений – ИИ о человеческих страданиях – 3 ways people respond to a problem – What AI can tell us about human suffering – The Laws of this World (Game Theory) – По вере вашей дано будет вам 🌞 Yoshiko Sai ～ Taiji no Yume 🔭 Chiemi Manabe - Untotooku

Чек-лист, что должен проверять продакт в AI-продуктах и чатах в частности 1. Правило 5–10 кейсов. Составь базвый золотой датасет из 5–10 эталонных юзкейсов (например, для AI-саппорта: возврат денег, смена адреса, жалоба на хамовитого курьера) и автоматизируй их проверку. 2. Один скорер = одно измерение. Главная ошибка PM - оценивать ответ модели одной общей метрикой «хорошо/плохо». Для кейса с возвратом денег разбей оценку на три отдельных скорера: • Точность (Accuracy): нашел ли бот правильную транзакцию? • Тон (Tone): вежлив ли бот, выразил ли эмпатию? • Безопасность (Policy): не пообещал ли бот возврат денег в обход регламента? 3. Human Review нельзя убирать. Автоматический код легко проверит, сделал ли бот запрос к базам данных. Но оценить, не звучит ли ответ как бездушный робот, пока может только человек. 4. Разрыв между топом и медианой. Команды с авто-эвалами видят, что новое обновление модели сделало бота супер-вежливым, но снизило точность поиска заказов на 10% и откатывают деплой. Команды без эвалов выкатывают регресс в прод и ловят волну негатива от клиентов. 5. 3 фазы внедрения на примере AI-саппорта: • Инкубация: собираем золотой датасет частых вопросов клиентов. • Шлифовка: weekly-демо, жесткие критерии (*«бот должен прикрепить ссылку на форму возврата, но не закрывать тикет сам»*) и просмотр цепочки рассуждений бота (Debug Mode). • Масштабирование: авто-тесты перед каждым деплоем и Slack-канал, куда автоматически падают все «дизлайки» от пользователей с логами беседы. 6. Чек-лист: как внедрить Evals за 5 шагов: • Собери реальные логи чатов, где бот ошибся. • Сформируй из них точечный датасет на 10–50 примеров. • Сравни две версии промпта side-by-side на одном и том же датасете. • Настрой автоматический ночной прогон тестов (Nightly Evals). • Настрой алерты на дизлайки пользователей прямо из продакшена. 7. Метрики качества AI-бота: • Accuracy: % корректно решенных вопросов без эскалации на оператора. • Tone & Brand Alignment: соответствие гайдлайнам компании. • Schema Compliance: отдаёт ли бот корректный JSON для API вызовов. • Latency & Cost: задержка ответа (в сек) и стоимость токенов на диалог. Источник: https://www.braintrust.dev/blog/evals-for-pms](https://www.braintrust.dev/blog/evals-for-pms #PG_education

Как я сходила на собеседование на AI-билдера Мне было интересно понять, что ожидают от AI-билдера на практике, поэтому откликнулась на такую роль в одной компании. В моем понимании это такой практически Entrepreneur in Residence. Спойлер: по факту это не совсем так и, видимо, отличается от компании к компании. Сначала созвон с рекрутером. Обычно я спрашиваю, какие ожидания у того, кто будет меня собеседовать, чтобы понимать, с какой стороны подсвечивать опыт: со стороны стартапа или со стороны корпората. Ответ был - просто будь собой 😄. Ну, ок, на мое усмотрение. Думаю, раз позиция билдера, то надо и рассказывать про билдинг продуктов: что делала, как, почему принимала решения. Но не тут-то было! После собеса с нанимающим приходит реджект с формулировкой про недостаточным опытом работы с множеством стейкхолдеров. Из этого предполгаю, что на самом деле это продакт, на которого навесили еще функции разработки и тестирования. Самое смешное - это то, что все свою корпоративную крьеру я только и делала, что работа со стейкхолдерами, при этом иногда в мультиязычной среде. Обычно я в красках рассказываю об этом при общении с энтерпрайзом, но в моем мире билдер меньше занимается политикой и больше билдерством. Надеюсь, что со временем роль устаканится и все-таки сформируется во что-то отличное, чем продакт за те же деньги, но с большим количеством задач. Ну, а пока так 🙂 #PG_размышления

2 года вне найма! 👨‍💻 Что я напишу в резюме, если завтра начну искать работу Ощущение, время летит все быстрее и быстрее. Вроде еще вчера работал в Т-Банке, а уже прошло почти 2 года с момента увольнения и перехода в свободное плавание. Но давайте представим, что мне резко понадобилось вернуться в найм на позицию Lead/CPO. Что писать в резюме за эти 2 года? 🎯 Цель: упаковать текущий опыт в CareerStation под роль CPO. В CareerStation я отвечаю за продажи, маркетинг и также глубоко погружен в продукт, поэтому мне не составит труда вытащить релевантный опыт под нужную позицию. 🔹Достижения: • Запустил продукт с нуля и вывел его на выручку X млн руб. за Y месяцев, разработав продуктовую стратегию, проведя исследование рынка и последовательно проверяя продуктовые гипотезы. • Увеличил количество платящих клиентов до X человек и обеспечил конверсию в оплату Y%, построив маркетинговую воронку из контент-маркетинга, вебинаров, Telegram-рассылок и партнерских каналов. • Повысил NPS на X%, внедрив регулярные пользовательские интервью, анализ обратной связи и процесс непрерывных продуктовых экспериментов. • Запустил новый премиальный тариф и увеличил AOV на X%, проведя глубинные интервью с клиентами, выявив новые сценарии использования продукта и переупаковав ценностное предложение. 🔹Обязанности: • Ответственность за стратегию развития продукта и roadmap, рост ключевых метрик (Revenue, NPS, CR в оплату, AOV, EBITDA, Churn Rate, CAC). • Управление полным циклом маркетинга: позиционирование, упаковка, привлечение пользователей, воронки и рост продаж. • Discovery: проведение количественных и качественных исследований, custdev, формирование гипотез и их приоритизация. Аналитика и принятие решений на основе данных. • People managament: управление командой из 6 человек, найм, обучение и развитие, KPI и обеспечение достижения целей. Быстро накидал несколько пунктов, но если углубиться и провести ретро, то можно еще намного больше раскопать. Я уверен, что многие недооценивают предпринимательский опыт. Если ты не просто открыл ИП, а отвечал за продукт, маркетинг, продажи, финансы и команду, то за пару лет можно получить такой объем опыта, который в корпорации набирается значительно дольше. И искренне не понимаю нанимающих, которые боятся брать продактов с бэкграундом создания собственного бизнеса 🤷 А вы что думаете?

Хочу, чтобы продакт был как предприниматель У очень многих фаундеров есть голубая мечта: найти продакта, который будет нести ответственность за свой участок и его метрики, думать как предприниматель и развивать бизнес. Реально было бы классно, чтобы можно было заплатить такому человеку и он все сделал тебе так, как надо. Проблема в том, что если чувак разбирается в продукте, думает как предприниматель и умеет растить бабки, то зачем ему ты? Он сам пойдет сделает свой пусть даже мини-продукт и заработает на нем в разы больше, чем в найме в твоей прекрасной компании. А тебе достанутся все остальные: те, кто не может брать ответственность, не думает как предприниматель и ничего про бабки не знает. Поэтому мой канал называется именно так, как называется.

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

/Роль магистратур уже не та, что раньше/ в 2018 я выпустилась из бакалавриата и поступила в магистратуру по выигранной олимпиаде. Свою честную цель я уже тогда спокойно озвучивала, а сейчас уж и подавно - мне нужно было "социальное прикрытие", чтобы поэксперементировать и разобраться со своей карьерой и с собой. Все вокруг знали, что я учусь в магистратуре и не задавали лишних вопросов, а я тем временем - много путешествовала - уволилась из консалтинга - самостоятельно проресерчила про карьеру в IT, потому что казалось, что там может быть интересно - получила оффер продуктового аналитика - не вышла работать аналитиком - получила два продуктовых оффера - вышла по одному из них джуниор-продактом - набила грандиозное количество шишек на реальных интерфейсах и пользователях - параллельно сделала еще пару проектов в проджектово/продуктовой роли, позволивших лучше понимать, как вообще работать работу и собрать кейсы так, что летом после магистратуры я вышла на миддловую позицию с хорошей зарплатой и могла снимать классную квартиру в москве, всячески развлекаться и придумывать свою дальнейшую стратегию. Но мы в 2026, а не в 2018, и игра поменялась. Рынок стал недобрым к джунам - вероятность вот так вот пойти и найти себе 3 джуновских оффера за месяц и вальяжно выбирать между ними - очень невысока. Рынок хочет миддлов и выше, а откуда взяться миддлам? Можно перейти из смежных профессий, а можно сделать пачку первых кейсов во время учебы - тем более, что продвинутые магистратуры сейчас, в основном, коллаборационные - хороший универ + хорошая компания [ака работодатель]. И вот так вот магистратуры, которые то были "лишними двумя годами на случай, если бакалавриат назовут неполным высшим", то "социальным прикрытием" оказались карьерным лифтом в отрасли, временно (?) недружелюбные к новичкам. Синк ебаут Мнение исключительно авторское и с информационным искажением на продактов, разумеется!

Работа в банке или в ставках: что хуже? 🎰 Представим двух продактов: Петя работает в банке и развивает кредитный продукт, Вася – в букмекерской компании и отвечает за продукт ставок. 😎 Задача Пети – сделать так, чтобы больше людей взяли кредит, чаще пользовались кредитными деньгами и приносили банку больше процентов. В том числе люди, которым, возможно, вообще не стоило брать этот кредит. 😎 Задача Васи – увеличить количество ставок, частоту игры и LTV пользователя. В том числе человека, который уже проиграл много денег и, возможно, имеет проблемы с азартными играми. Кажется, что ставки очевидно хуже 🧐 Букмекер зарабатывает на проигрыше клиента. Чем больше человек играет, тем больше компания в среднем зарабатывает. А часть пользователей действительно может потерять контроль и проиграть последние деньги. С этой стороны вопрос к сотруднику вполне понятный: ты осознанно улучшаешь продукт, который может усиливать зависимое нездоровое поведение. Но с банком все так однозначно? 🤨 Кредит сам по себе полезный продукт. Можно купить квартиру, машину или решить временную финансовую проблему, когда у тебя нет всей суммы на руках. Но сотрудник кредитного продукта может работать над ростом выдач, увеличением кредитного лимита и повторными займами. И за красивой метрикой “рост LTV” вполне может стоять человек, который перекрывает один долг другим и годами платит банку проценты, возможно уже никогда не выберется из этого замкнутого круга. Получается интересная ситуация: продакт в ставках увеличивает частоту игры, а продакт в банке – частоту использования кредитных денег. Один возвращает пользователя фрибетом, второй предлагает заранее одобренный кредит или повышает лимит. При этом работа в банке считается престижной, а опыт в ставках многие даже не хотят указывать в резюме, потому что для некоторых работодателей это red flag. Что из этого хуже решайте сами. 🤨 - хуже банки 🥴 - хуже ставки 🤝 - одинаково

Погружение в новый домен До работы в Salmon я практически ничего не знал про рынок мотоциклов. Так уж сложилось, что моим основным фокусом всегда были автомобили. А ведь продакт должен хорошо понимать, что продает его продукт и что хотят его пользователи. Сначала я просто старался на улице, увидев издалека мотоцикл — в Маниле это не проблема, они на каждом шагу, определить его марку и модель. И проверить свой вариант подойдя поближе. Но это как-то примитивно в наше время. На выходных завайбкодил себе тренажер «Угадай мотоцикл по фото». Квиз, в котором за 15 секунд нужно выбрать правильный ответ из 4 вариантов. И дело пошло! Сейчас уже сразу отличаю Honda от Yamaha или Kawasaki, но над знанием моделей ещё нужно поработать 😁 На днях поделился ссылкой с командой разработки. Ожидаемо на первом месте рейтинга наш QA 😉 Если захотите поиграть, а заодно погрузиться в филиппинский рынок мото — велкам! ▶️ https://motoquiz.vercel.app/ Суммарный рейтинг учитывает не только количество правильных ответов, но и скорость выбора. А ещё можно взять подсказку за минус 50 очков и убрать блюр с фотографии. Тому, кто из моих подписчиков наберет больше 1900 очков, обещаю что-нибудь подарить 😉 Сделано, конечно, в тесном контакте с Claude Code. Это мой любимый разработчик на сегодняшний день! #claude #motors

Карьерные советы менеджеру продуктов, которые пора перестать воспринимать буквально Чем быстрее развивается индустрия, тем чаще может казаться, что рекомендации старших коллег и чеклисты в разных курсах и методичках становятся бесполезными. Часто проблема в том, что их продолжают повторять как универсальные правила, хотя рынок, компании и сама роль менеджера продуктов уже изменились. Знание фреймворков, работа с данными, исследования, переходы между компаниями и личный бренд по-прежнему могут помогать в достижении профессиональных целей. Но только если учитывать контекст, ограничения и цену конкретного решения. Без этого полезная рекомендация легко превращается в карьерную ловушку. Собрали 8 советов, которые пора перестать воспринимать буквально. Что в них устарело и что все еще остается актуальным — в карточках. @productmindset

Сегодня хороню Средненького продакта В последнее время всё чаще думаю, что меньше всего на свете хочу быть средненьким. Эта ирония работала какое-то время и была созвучна моей прееходной идентичности, но больше нет. Я заебись продакт, но, наверное, худший в мире исполнитель. Если сложить и поделить эти два факта, то будет средненький. Но ирония в том, что мне больше нет смысла складывать и делить. Я могу использовать, качать и продавать только сильную часть. Для всего остального есть... Ну, пусть будет карта МИР пока. В общем, не хочу чтобы моя лодка так называлась. Это не значит, что дальше плывём на серьёзных щах, не бывать такому. Но флаг меняем. Дальше. -- Я больше не ассоциирую себя с продактом, да и той профессии, в которой я был сеньором еще полтора года назад, уже нет. -- Каналов с неймингом на такой манер стало слишком много. Пусть резвятся, я не с ними. -- Ну это страшновато, да. А вдруг чего? Да и пофиг. Канал меня представляет, но больше не является ни мной, ни моим основным способом заработать на жизнь (и нет, работу я не нашел, скоро будет третий отчёт). Средненький продакт прожил славную жизнь. Яркую, эмоциональную, с множеством событий.Интересный был парень, и я совершенно точно его буду помнить. Но сегодня я бросил попытки его спасти и похоронил окончательно. И стало легче дышать: впервые за жизнь я осознанно строю не карьеру, а себя. И здесь уже нет места профессиональной приставке.