Product Management & AI
Microsoft вчера анонсировала поддержку MCP в Windows и пару интересных ИИ-инструментов: 1. Операционки Windows теперь работают с MCP и обеспечивают доступ ИИ-агентов к файловой системе и другим службам(!). 2. Windows AI Foundry Local SDK — набор инструментов…
Вслед за Microsoft, Гугл вчера провёл конференцию Google I/O. Вот что самое интересное:
– Перевод речи в реальном времени в Google Meet.
– Stitch от Google Labs полез на поляну Figma и предлагает создание дизайнов пользовательских интерфейсов.
– Помимо Фигмы, Гугл полез в копилоты для разработчиков, запустив агента Jules, проинтегрированного с GitHub.
– Veo 3 генерит фотореалистичные видеоролики + звуковые эффекты, позволяя сохранять состояния персонажей.
– Deep Think представляет из себя новый улучшенный режим рассуждений на основе параллельного мышления (исследует сразу несколько гипотез перед ответом, прямо как наш брат (сестра)).
– Пользователи Google Shopping из США могут виртуально примерить одежду в Labs, просто загрузив свою фотографию.
– Imagen 4 теперь создаёт более насыщенные изображения с более тонкими цветами, сложными деталями и типографикой.
– Режим ИИ в поиске внедряется ещё глубже и ответы теперь будут представляться непосредственно в результатах выдачи Google. Press "F" эпохе SEO.
В 2023 году генеральный директор Microsoft Сатья Наделла сказал, что хочет «заставить Google танцевать». Что-ж, танцуют неплохо для корпорации.
– Перевод речи в реальном времени в Google Meet.
– Stitch от Google Labs полез на поляну Figma и предлагает создание дизайнов пользовательских интерфейсов.
– Помимо Фигмы, Гугл полез в копилоты для разработчиков, запустив агента Jules, проинтегрированного с GitHub.
– Veo 3 генерит фотореалистичные видеоролики + звуковые эффекты, позволяя сохранять состояния персонажей.
– Deep Think представляет из себя новый улучшенный режим рассуждений на основе параллельного мышления (исследует сразу несколько гипотез перед ответом, прямо как наш брат (сестра)).
– Пользователи Google Shopping из США могут виртуально примерить одежду в Labs, просто загрузив свою фотографию.
– Imagen 4 теперь создаёт более насыщенные изображения с более тонкими цветами, сложными деталями и типографикой.
– Режим ИИ в поиске внедряется ещё глубже и ответы теперь будут представляться непосредственно в результатах выдачи Google. Press "F" эпохе SEO.
В 2023 году генеральный директор Microsoft Сатья Наделла сказал, что хочет «заставить Google танцевать». Что-ж, танцуют неплохо для корпорации.
This media is not supported in your browser
VIEW IN TELEGRAM
Жёсткая правда: то, что запрашивают ваши пользователи, редко является тем, что им действительно нужно (с)
Продакт-менеджеры терпят неудачу, потому что они воспринимают отзывы пользователей как прямые требования, а не как сигналы, указывающие на более глубокие проблемы.
И большинство продактов следуют этому НЕПРАВИЛЬНОМУ процессу:
1) давайте соберём отзывы;
2) сгруппируем похожие запросы;
3) расставим приоритеты по частоте;
4) внедрим самые популярные запросы.
Этот подход кажется ориентированным на данные, но на самом деле создает раздутые, запутанные продукты, которые решают поверхностные проблемы.
В тот момент, когда вы начинаете реализовывать запросы функций буквально, вы перестаёте быть менеджером по продукту и становитесь приёмщиком заказов.
Решение – метод извлечения сигнала.
Вместо того, чтобы воспринимать обратную связь буквально, извлеките базовый сигнал, используя 3-частную структуру:
1. Контекст.
2. Триггеры.
3. Желаемые результаты.
Контекст
Никогда не оценивайте обратную связь изолированно. Всегда спрашивайте:
«Над чем вы работали, когда вам это было нужно?»
«Где это вписывается в ваш процесс?»
«Как часто возникает эта ситуация?»
Это раскрывает фактический рабочий процесс, а не просто запрос новой функции.
Триггеры
Для каждого фрагмента обратной связи определите:
«Какое конкретное событие заставило вас задуматься об этом решении?»
«Чего вы пытались достичь, когда столкнулись с этой проблемой?»
«Какие обходные пути вы использовали?»
Желаемые результаты
Волшебный вопрос, который меняет всё:
«Если бы у вас была эта функция, что бы изменилось в вашей работе/жизни?»
Это показывает, как на самом деле выглядит успех для пользователя, который почти никогда не выражается в функциии, которую он просил.
Но большинство продактов буксуют на фразе:
«Но мои заинтересованные стороны хотят, чтобы мы были ориентированы на клиентов!»
Ответ, который изменит всё:
«Мы решаем основную потребность, стоящую за этими запросами. Вот три решения, которые решают эту проблему более эффективно».
Если они и дальше игнорируют качественную обратную связь:
«Мы выявили закономерность в 12 разговорах с клиентами. Этот сигнал сопоставляется с падением на 9% в воронке конверсии на шаге 3. Вот гипотеза, которую мы должны проверить».
Обратите внимание, как связывается боль пользователя с метриками.
TLDR:
– 5-7 глубоких бесед с клиентами достаточно;
– клиент выступает советчиком;
– поиск паттерна поведения;
– триангуляция отзывов с данными об использовании;
– сегментация отзывов по ценности для клиента;
– поиск решения для результата, а не запроса.
И помните, что в тот момент, когда пользователи начинают говорить вам, что именно для них нужно создать, вы теряете нить событий.
Работа продакта не в том, чтобы быть приёмщиком заказов. Ваша задача — быть детективом, находящим настоящие проблемы, скрывающиеся за поверхностными запросами.
Продакт-менеджеры терпят неудачу, потому что они воспринимают отзывы пользователей как прямые требования, а не как сигналы, указывающие на более глубокие проблемы.
Ваша задача не создавать то, что просят пользователи, а решать проблемы, которые у них действительно есть.
И большинство продактов следуют этому НЕПРАВИЛЬНОМУ процессу:
1) давайте соберём отзывы;
2) сгруппируем похожие запросы;
3) расставим приоритеты по частоте;
4) внедрим самые популярные запросы.
Этот подход кажется ориентированным на данные, но на самом деле создает раздутые, запутанные продукты, которые решают поверхностные проблемы.
Потому что, когда пользователи говорят «добавьте панель управления для X», они на самом деле они просто говорят «Мне сложно понять X».
В тот момент, когда вы начинаете реализовывать запросы функций буквально, вы перестаёте быть менеджером по продукту и становитесь приёмщиком заказов.
Решение – метод извлечения сигнала.
Вместо того, чтобы воспринимать обратную связь буквально, извлеките базовый сигнал, используя 3-частную структуру:
1. Контекст.
2. Триггеры.
3. Желаемые результаты.
Контекст
Никогда не оценивайте обратную связь изолированно. Всегда спрашивайте:
«Над чем вы работали, когда вам это было нужно?»
«Где это вписывается в ваш процесс?»
«Как часто возникает эта ситуация?»
Это раскрывает фактический рабочий процесс, а не просто запрос новой функции.
Триггеры
Для каждого фрагмента обратной связи определите:
«Какое конкретное событие заставило вас задуматься об этом решении?»
«Чего вы пытались достичь, когда столкнулись с этой проблемой?»
«Какие обходные пути вы использовали?»
Желаемые результаты
Волшебный вопрос, который меняет всё:
«Если бы у вас была эта функция, что бы изменилось в вашей работе/жизни?»
Это показывает, как на самом деле выглядит успех для пользователя, который почти никогда не выражается в функциии, которую он просил.
Но большинство продактов буксуют на фразе:
«Но мои заинтересованные стороны хотят, чтобы мы были ориентированы на клиентов!»
Ответ, который изменит всё:
«Мы решаем основную потребность, стоящую за этими запросами. Вот три решения, которые решают эту проблему более эффективно».
Если они и дальше игнорируют качественную обратную связь:
«Мы выявили закономерность в 12 разговорах с клиентами. Этот сигнал сопоставляется с падением на 9% в воронке конверсии на шаге 3. Вот гипотеза, которую мы должны проверить».
Обратите внимание, как связывается боль пользователя с метриками.
TLDR:
– 5-7 глубоких бесед с клиентами достаточно;
– клиент выступает советчиком;
– поиск паттерна поведения;
– триангуляция отзывов с данными об использовании;
– сегментация отзывов по ценности для клиента;
– поиск решения для результата, а не запроса.
Решайте проблемы, а не функции.
И помните, что в тот момент, когда пользователи начинают говорить вам, что именно для них нужно создать, вы теряете нить событий.
Работа продакта не в том, чтобы быть приёмщиком заказов. Ваша задача — быть детективом, находящим настоящие проблемы, скрывающиеся за поверхностными запросами.
This media is not supported in your browser
VIEW IN TELEGRAM
product manager preparing to write a PRD no one will read
11 хард-скиллов продакт-менеджера God Mode:
– Понимание того, из чего складываются метрики бизнеса и как на них влияют метрики продукта/фич. Умение переключаться между разными уровнями абстракций.
– Понимание системной связи между фичами в продукте (или её отсутствия) и потоков данных, движущихся через систему.
– Наблюдение, отслеживание и контроль жизни фич во времени.
– Умение проводить собеседование с любымспециалистом человеком.
– Умение работать с командами с разными навыками и опытом. Эмоциональная регуляция команды.
– Скорость обучения. Стратегическое терпение.
– Умение получать релевантные данные с рынка не только из первых рук.
– Поведенческая экономика. Ecosystem thinking.
– Конфигурации аналитических систем.
– Интуиция относительно того, что важно.
– Влияние без полномочий (заслуживать доверие через данные и убедительные доводы). И интуиция по людям.
– Понимание того, из чего складываются метрики бизнеса и как на них влияют метрики продукта/фич. Умение переключаться между разными уровнями абстракций.
– Понимание системной связи между фичами в продукте (или её отсутствия) и потоков данных, движущихся через систему.
– Наблюдение, отслеживание и контроль жизни фич во времени.
– Умение проводить собеседование с любым
– Умение работать с командами с разными навыками и опытом. Эмоциональная регуляция команды.
– Скорость обучения. Стратегическое терпение.
– Умение получать релевантные данные с рынка не только из первых рук.
– Поведенческая экономика. Ecosystem thinking.
– Конфигурации аналитических систем.
– Интуиция относительно того, что важно.
– Влияние без полномочий (заслуживать доверие через данные и убедительные доводы). И интуиция по людям.
В целом, дело даже НЕ в «хард-скиллах», а в том, насколько чётко ты понимаешь, вкаком хаосечём ты умеешь хорошо ориентироваться.
Please open Telegram to view this post
VIEW IN TELEGRAM
Product Management & AI
Неудачи и факапы — это данные Относись к ним соответственно и научи себя и команду быстро восстанавливаться после любых факапов, мгновенно переходя от ощущения эмоций к анализу причин. Как только вы закончите анализ, так же мгновенно пробуйте новое. В противном…
This media is not supported in your browser
VIEW IN TELEGRAM
11 советов как продакт-менеджеру заранее предотвращать срывы сроков разработки (и что делать, если они срываются)
0. Всегда умножай оценки сроков х2-3. А при коммуникации со стейкхолдерами давай диапазоны вместо точных дат.
1. Не критикуй разрабов за пессимистичные прогнозы разработки – пусть лучше они честно скажут, что это займёт месяц, чем под давлением пообещают 2 недели и завалят всё на 2 месяца.
3. Декомпозируй задачи до уровня обнаружения в ней любых возможных блоков через 2-3 дня её разработки.
Если задачу нельзя разбить до такого уровня, значит задача недостаточно тобой детализированна.
4. Помни про Critical path - последовательность задач, в которой задержка любой задачи сдвигает всю дату релиза.
Выделяй сеньоров на критический путь + всегда имей прозапас запасного участника такого уровня для критической части.
5. Включай в сессии по оценке сроков разарботки не только сеньоров, но и мидлов. Именно мидлы пишут код и именно их оценки самые реалистичные.
6. Требуй тех. задание от лид-инженера перед началом разработки.
Оно заставляет команду разработки продумать архитектуру, выявить зависимости и определить точки интеграции ДО написания кода.
7. Стендапы нужны для выявления блокеров и отклонений. Нет блокеров и отклонений – не мучайтесь с командой ежедневными созвонами, они ведут к выгоранию, которое ведёт к потере чувства времени и сроков.
Вместо них можно ведите автоматизированный стендап в Slack с указанием % готовности задач и уведомлениями о превышении запланированных сроков и объяснением причин и новой оценкой времени со стороны тимлида.
Что делать, если сроки срываются?
8. Red Room – экстренный режим работы с ежедневными встречами всех ключевых участников для быстрого принятия решений и устранения блокеров.
Если Red Room длится более одной недели, значит проблема сроков разработки носит стратегический характер и требует структурных кадровых/культурных решений, а не разовых фиксов/припарок.
Урезай фичу до версии, которая всё ещё решает основную пользовательскую проблему и приносит ценность юзерам/бизнесу
Урезанная версия идёт по 3 сценариям с чёткими критериями: время vs scope vs качество.
И если вы не можете убрать 30% скопа без потери основной ценности, значит изначальное решение было over-engineered.
Всегда документируй такие решения для избежания вопросов со стороны заинтересованных лиц (и конфликтов в будущем).
10. Перераспределение ресурсов с менее критичных задач и привлечение дополнительных разрабов работает только при наличии:
а) чёткой и описанной архитектуры;
б) возможностей для параллелизации задач;
в) разрабов с опытом в конкретной области/стэке;
г) наличии 1-2 недель на их онбординг.
11. Регулярные post-mortem после каждого релиза позволяют команде учиться на своих ошибках и повышать точность планирования. Если одни и те же проблемы повторяются в нескольких post-mortem, это снова про систематическую ошибку и кардинальные решения по её исправлению.
Каждая фаза разработки должна приносить ценность для пользователя и бизнеса, а не быть очередным спринтом-забегом на время для команды разработки.
0. Всегда умножай оценки сроков х2-3. А при коммуникации со стейкхолдерами давай диапазоны вместо точных дат.
1. Не критикуй разрабов за пессимистичные прогнозы разработки – пусть лучше они честно скажут, что это займёт месяц, чем под давлением пообещают 2 недели и завалят всё на 2 месяца.
Поощряй и стимулируй в команде точность и предсказуемость поставки, а не скорость и оптимистичные оценки
3. Декомпозируй задачи до уровня обнаружения в ней любых возможных блоков через 2-3 дня её разработки.
Если задачу нельзя разбить до такого уровня, значит задача недостаточно тобой детализированна.
4. Помни про Critical path - последовательность задач, в которой задержка любой задачи сдвигает всю дату релиза.
Выделяй сеньоров на критический путь + всегда имей прозапас запасного участника такого уровня для критической части.
5. Включай в сессии по оценке сроков разарботки не только сеньоров, но и мидлов. Именно мидлы пишут код и именно их оценки самые реалистичные.
6. Требуй тех. задание от лид-инженера перед началом разработки.
Оно заставляет команду разработки продумать архитектуру, выявить зависимости и определить точки интеграции ДО написания кода.
Если лид не может написать ТЗ за 3 часа, значит задача УЖЕ недостаточно понятна для реализации
7. Стендапы нужны для выявления блокеров и отклонений. Нет блокеров и отклонений – не мучайтесь с командой ежедневными созвонами, они ведут к выгоранию, которое ведёт к потере чувства времени и сроков.
Вместо них можно ведите автоматизированный стендап в Slack с указанием % готовности задач и уведомлениями о превышении запланированных сроков и объяснением причин и новой оценкой времени со стороны тимлида.
Что делать, если сроки срываются?
8. Red Room – экстренный режим работы с ежедневными встречами всех ключевых участников для быстрого принятия решений и устранения блокеров.
Если Red Room длится более одной недели, значит проблема сроков разработки носит стратегический характер и требует структурных кадровых/культурных решений, а не разовых фиксов/припарок.
9. Урезание функционала это про чёткое понимание текущих приоритетов и их влияния на бизнес-цели, а не сокращение/навёрстывание сроков
Урезай фичу до версии, которая всё ещё решает основную пользовательскую проблему и приносит ценность юзерам/бизнесу
Урезанная версия идёт по 3 сценариям с чёткими критериями: время vs scope vs качество.
И если вы не можете убрать 30% скопа без потери основной ценности, значит изначальное решение было over-engineered.
Всегда документируй такие решения для избежания вопросов со стороны заинтересованных лиц (и конфликтов в будущем).
10. Перераспределение ресурсов с менее критичных задач и привлечение дополнительных разрабов работает только при наличии:
а) чёткой и описанной архитектуры;
б) возможностей для параллелизации задач;
в) разрабов с опытом в конкретной области/стэке;
г) наличии 1-2 недель на их онбординг.
Если добавление разрабов не ускоряет доставку кода через 2 недели, правильным решением будет их отозвать и не мучать
11. Регулярные post-mortem после каждого релиза позволяют команде учиться на своих ошибках и повышать точность планирования. Если одни и те же проблемы повторяются в нескольких post-mortem, это снова про систематическую ошибку и кардинальные решения по её исправлению.
Каждая фаза разработки должна приносить ценность для пользователя и бизнеса, а не быть очередным спринтом-забегом на время для команды разработки.
This media is not supported in your browser
VIEW IN TELEGRAM
Почему разрабы мы все факапим сроки? Посвящается всем разрабам и продактам
Причина №1 – у нас искажено системное мышление, из-за чего мы видимкод продукт мир как цепочку причинно-следственных связей и параметров:
– Требование → Инструкция → Решение
– Input → Output.
– Ошибка → Исправление.
Но продукты — это Системы, в которых есть Пользователи, Бизнес и Хаос.
И одержимость «параметрами» (функциями, спецификациями, архитектурой и культурой кода) считается самой слабой точкой влияния в любой Системе.
Самая сильная?
Ментальные модели и цели Системы.
Потому что продукт это не просто набор технически работающих фич. Это сложная Система, в которой:
– Каждая новая функция связана и влияет на существующие.
– Поведение пользователей создаёт цепочки общих циклов действий.
– И даже небольшие изменения могут иметь неожиданные последствия, создавая новые проблемы (Хаос).
И распространенная ошибка – поиск «первопричин проблем».
В Системах редко бывают первопричины.
Вместо этого есть структуры, которые создают Шаблоны поведения Систем и пользователей.
Более того, сами Системы обманывают нас, представляя себя как серию событий, на которые мы реагируем:
– Запросы фич от юзеров.
– Текущие ошибки в коде.
– Конкуренты/рыночек и всё такое.
Поэтому мы ошибочно фокусируем внимание на том, ЧТО и КАК строить, а не на понимании, ПОЧЕМУ Система ведёт себя так, а не иначе.
Это всего лишь со-бы-ти-я.
Настоящая сила продакта и разраба в том, чтобы видеть Шаблоны.
Наше мышление — не слабость. Это основа, потому что мы понимаем:
– Циклы обратной связи.
– Управление состояниями.
– Сложные зависимости.
– Системные ограничения.
Всё, что нам нужно – это применять их к Человеческим Системам, чаще задавая себе вопросы:
– Каковы скрытые Шаблоны?
– В чём задержки Системы?
– Какие ментальные модели определяют все решения?
Поэтому, прежде чем каким-либо образомулучшить нарушить работу Системы, лучше посмотреть, как она себя ведёт.
Не начинайте с решений.
Не спешите с выводами.
Просто наблюдайте.
🤷♂️
Причина №1 – у нас искажено системное мышление, из-за чего мы видим
– Требование → Инструкция → Решение
– Input → Output.
– Ошибка → Исправление.
Но продукты — это Системы, в которых есть Пользователи, Бизнес и Хаос.
И одержимость «параметрами» (функциями, спецификациями, архитектурой и культурой кода) считается самой слабой точкой влияния в любой Системе.
Самая сильная?
Ментальные модели и цели Системы.
Потому что продукт это не просто набор технически работающих фич. Это сложная Система, в которой:
– Каждая новая функция связана и влияет на существующие.
– Поведение пользователей создаёт цепочки общих циклов действий.
– И даже небольшие изменения могут иметь неожиданные последствия, создавая новые проблемы (Хаос).
И распространенная ошибка – поиск «первопричин проблем».
В Системах редко бывают первопричины.
Вместо этого есть структуры, которые создают Шаблоны поведения Систем и пользователей.
Более того, сами Системы обманывают нас, представляя себя как серию событий, на которые мы реагируем:
– Запросы фич от юзеров.
– Текущие ошибки в коде.
– Конкуренты/рыночек и всё такое.
Поэтому мы ошибочно фокусируем внимание на том, ЧТО и КАК строить, а не на понимании, ПОЧЕМУ Система ведёт себя так, а не иначе.
Это всего лишь со-бы-ти-я.
Настоящая сила продакта и разраба в том, чтобы видеть Шаблоны.
И наименее очевидная часть Системы, её функция и Цель, часто является наиболее важным фактором, определяющим само поведение Системы.
Наше мышление — не слабость. Это основа, потому что мы понимаем:
– Циклы обратной связи.
– Управление состояниями.
– Сложные зависимости.
– Системные ограничения.
Всё, что нам нужно – это применять их к Человеческим Системам, чаще задавая себе вопросы:
– Каковы скрытые Шаблоны?
– В чём задержки Системы?
– Какие ментальные модели определяют все решения?
Поэтому, прежде чем каким-либо образом
Не начинайте с решений.
Не спешите с выводами.
Просто наблюдайте.
🤷♂️
Понедельник – день (не)существенных задач
Понедельники be like: стата вся обновлена, багрепорты/фидбек свежее, инфа читается иначе, вокруг все в курсе актуальности событий.
Но начинаются забеги по созвонам, таскам, личкам.
В них часто смотришь на опережение (не)существующих задач.
Задач, которые сам сделал/стали/перестали таковыми быть из-за изменений рынка, методологий, настроений (всё об одном и том же, это тоже часто вспоминаешь в понедельник).
Думай по понедельникам про 👆
Понедельники be like: стата вся обновлена, багрепорты/фидбек свежее, инфа читается иначе, вокруг все в курсе актуальности событий.
Но начинаются забеги по созвонам, таскам, личкам.
В них часто смотришь на опережение (не)существующих задач.
Задач, которые сам сделал/стали/перестали таковыми быть из-за изменений рынка, методологий, настроений (всё об одном и том же, это тоже часто вспоминаешь в понедельник).
Что То одно существенное?
Ради чего Всё динамично в понедельник?
Думай по понедельникам про 👆
This media is not supported in your browser
VIEW IN TELEGRAM
Майский дайджест для продактов и их команд уже готов к просмотру (c эйчбио) 🍿
– Продуктовый дзен
– Продуктовый серфинг
– Игры разработчиков
– RAID – реестр рисков
– Карьера в форме пирамиды
– Вопросы ждут от кандидатов
– Как не убить культуру ошибок
– Другая постановка задачи
– Как собирать обратную связь
– Когда масштаб убивает суть
– Дифференцируй, а не конкурируй
– 3 стадии с продуктовым исследованиями
– 39 шаблонов для UX-исследований
– Research Debt
– Чёрный SEO — это GEO
– Когда VIP не VIP
– История ухудшения продукта
– Слабая активация — слабая аура
– Важность shit tolerance
– Как знакомиться первым
– "Так, а задача?"
– Отмазки для продакта
– Кто правит миром
– Лень, невнимательнось и деньги
– Как хвастаться своей работой
– Искусство переговоров c результатом
– Одна метрика выросла, вторая упала
– Фаундер на саппорте
– Что отделяет сеньоров от стаффов
– Работаем с лоу-перформерами
– Процесс тестирования гипотез
– Про User Story mapping
– Не понимаешь? Создай шаблон
– Шаблон амазоновских мемо
– Адаптивность — про способность чувствовать
– Фактор роста: найти, усилить, не потерять
– Дисфункциональность команды
– Остаться в живых
– Новая работа — минное поле
– Задачи, которые воруют энергию
– Гайд: как манипулировать данными
– Пути внедрения LLM в продукт
– Атрофия навыков из-за AI
– ИИ не знает, когда не знает
– Зачем менеджеру смотреть в бездну
– Поговорки продуктолога
– Исследование продактов в России
Обзор международного рынка продактов 2025: 40% опрошенных считают своих менеджеров бесполезными; выгорание на критическом уровне; самые счастливые люди – фаундеры стартапов (ахахахахахахаха. YES, BUT. – прим.).
💫 Hiraeth & ᐰksarnerk - See The Stars
– Продуктовый дзен
– Продуктовый серфинг
– Игры разработчиков
– RAID – реестр рисков
– Карьера в форме пирамиды
– Вопросы ждут от кандидатов
– Как не убить культуру ошибок
– Другая постановка задачи
– Как собирать обратную связь
– Когда масштаб убивает суть
– Дифференцируй, а не конкурируй
– 3 стадии с продуктовым исследованиями
– 39 шаблонов для UX-исследований
– Research Debt
– Чёрный SEO — это GEO
– Когда VIP не VIP
– История ухудшения продукта
– Слабая активация — слабая аура
– Важность shit tolerance
– Как знакомиться первым
– "Так, а задача?"
– Отмазки для продакта
– Кто правит миром
– Лень, невнимательнось и деньги
– Как хвастаться своей работой
– Искусство переговоров c результатом
– Одна метрика выросла, вторая упала
– Фаундер на саппорте
– Что отделяет сеньоров от стаффов
– Работаем с лоу-перформерами
– Процесс тестирования гипотез
– Про User Story mapping
– Не понимаешь? Создай шаблон
– Шаблон амазоновских мемо
– Адаптивность — про способность чувствовать
– Фактор роста: найти, усилить, не потерять
– Дисфункциональность команды
– Остаться в живых
– Новая работа — минное поле
– Задачи, которые воруют энергию
– Гайд: как манипулировать данными
– Пути внедрения LLM в продукт
– Атрофия навыков из-за AI
– ИИ не знает, когда не знает
– Зачем менеджеру смотреть в бездну
– Поговорки продуктолога
– Исследование продактов в России
Обзор международного рынка продактов 2025: 40% опрошенных считают своих менеджеров бесполезными; выгорание на критическом уровне; самые счастливые люди – фаундеры стартапов (ахахахахахахаха. YES, BUT. – прим.).
💫 Hiraeth & ᐰksarnerk - See The Stars
Product Management & AI
Майский дайджест для продактов и их команд уже готов к просмотру (c эйчбио) 🍿 – Продуктовый дзен – Продуктовый серфинг – Игры разработчиков – RAID – реестр рисков – Карьера в форме пирамиды – Вопросы ждут от кандидатов – Как не убить культуру ошибок – Другая…
Стадии счастья фаундера стартапа:
0. Мы что-то создаём, что может быть полезно людям.
1. И всё же, что мы создаём?
3. MVP всего вокруг.
5. Последняя N из NNNNN – друг.
6. Время. Шум. Баланс. Гармония.
6. Ода ежемесячной подписке.
7. В голове один "Cost per Event".
8. MRR GO BRR. Шум. Баланс.
9. Гармония.
0. Воу, мы что-то создаём!
0. Мы что-то создаём, что может быть полезно людям.
1. И всё же, что мы создаём?
3. MVP всего вокруг.
5. Последняя N из NNNNN – друг.
6. Время. Шум. Баланс. Гармония.
6. Ода ежемесячной подписке.
7. В голове один "Cost per Event".
8. MRR GO BRR. Шум. Баланс.
9. Гармония.
0. Воу, мы что-то создаём!
This media is not supported in your browser
VIEW IN TELEGRAM
Хорошая продуктовая стратегия
Плохая продуктовая стратегия
– Хорошая стратегия продукта всегда даёт свежий взгляд на рынок и продукт. Плохая стратегия продукта пытается соответствовать уже существующему мнению о том, что следует делать с продуктом.
– Хорошая продуктовая стратегия определяет целевые и нецелевые сегменты клиентов. Плохая игнорирует сегментацию, либо пытается охватить много сегментов.
– Хорошая продуктовая стратегия даёт ясность в отношении потребностей клиента. Плохая представляет собой список функций, которые пытаются "решить" потребности множества сегментов клиентов.
– Хорошая стратегия продукта связывает решения и действия с планами и рисками. Плохая стратегия не видит и не сопоставляет эти факторы.
– Хорошая продуктовая стратегия представляет честную оценку рынка, конкуренции и положения продукта. Плохая преуменьшает конкуренцию, либо, вообще, игнорирует эти факторы.
– Хорошая продуктовая стратегия помогает понять как играть на поле с действующими конкурентами. Плохая по-умолчанию принимает их правила игры.
– Хорошая стратегия продукта полагается на его долгосрочные преимущества. Плохая опирается на текущие и краткосрочные, переоценивая их реальное влияние на продукт.
– Хорошая стратегия продукта возникает из глубоких размышлений, но сформулирована так, что любой её может понять и повторить. Она вдохновляет, потому что ярка, амбициозна, достижима. Плохая стратегия пытается казаться таковой.
Плохая продуктовая стратегия
– Хорошая стратегия продукта всегда даёт свежий взгляд на рынок и продукт. Плохая стратегия продукта пытается соответствовать уже существующему мнению о том, что следует делать с продуктом.
– Хорошая продуктовая стратегия определяет целевые и нецелевые сегменты клиентов. Плохая игнорирует сегментацию, либо пытается охватить много сегментов.
– Хорошая продуктовая стратегия даёт ясность в отношении потребностей клиента. Плохая представляет собой список функций, которые пытаются "решить" потребности множества сегментов клиентов.
– Хорошая стратегия продукта связывает решения и действия с планами и рисками. Плохая стратегия не видит и не сопоставляет эти факторы.
– Хорошая продуктовая стратегия представляет честную оценку рынка, конкуренции и положения продукта. Плохая преуменьшает конкуренцию, либо, вообще, игнорирует эти факторы.
– Хорошая продуктовая стратегия помогает понять как играть на поле с действующими конкурентами. Плохая по-умолчанию принимает их правила игры.
– Хорошая стратегия продукта полагается на его долгосрочные преимущества. Плохая опирается на текущие и краткосрочные, переоценивая их реальное влияние на продукт.
Хорошая продуктовая стратегия помогает различать: а) варианты; б) компромиссы и оптимизировать их в) долгосрочные преимущества. Плохая сводит всё к краткосрочным компромиссам
– Хорошая стратегия продукта возникает из глубоких размышлений, но сформулирована так, что любой её может понять и повторить. Она вдохновляет, потому что ярка, амбициозна, достижима. Плохая стратегия пытается казаться таковой.
This media is not supported in your browser
VIEW IN TELEGRAM
Парадоксы при discovery в продуктах
Опытные продакты начинают с НЕТ — что вашим пользователям не нужно то, что вы создаёте. А затем выстраивают убеждение на основе идей и находят ДА к тому, что пользователи действительно хотят.
Парадокс в том, что:
– Название нашей должности предполагает, что мы должны знать, чего хотят пользователи.
– Пользователи ожидают, что у нас это будет.
– Наша дорожная карта подразумевает, что мы это поняли.
По факту же:
– Мы разговариваете с пользователями, но задаём наводящие вопросы, которые подтверждают наши же идеи.
– Мы отбираем ту обратную связь, которая совпадает и поддерживает нашу дорожную карту.
– Мы относимся к исследованию пользователей как к проверке, а не как к исследованию.
Настоящее discovery начинается с другого мышления.
Вместо «Нам нужно проверить идею этой функции», думайте «Нам нужно понять эту проблемную область и ситуацию».
Вместо «Хотят ли пользователи фичу?» спросите «Чего на самом деле пытаются достичь пользователи?»
Перед любым разговором с пользователем перечислите свои предположения:
– У кого есть эта проблема?
– Когда они с ней сталкиваются?
– Как они решают её сегодня?
– Что сделало бы решение ценным для них?
– Что заставило бы их отказаться от текущего подхода?
Задавайте вопросы:
Прислушивайтесь к:
– Частоте (как часто это происходит?).
– Силе (насколько болезненным является опыт?).
– Альтернативам (что ещё они пробовали?).
– Контексту (когда это имеет наибольшее значение?).
Составьте карту шаблонов:
– Какие проблемы возникают у нескольких сегментов пользователей?
– Какие контексты делают проблемы более/менее болезненными?
– Какие решения пользователи постоянно хвалят или критикуют?
– По каким результатам они измеряют успех?
Ищите неожиданные идеи в:
– Проблемах, о существовании которых вы не знали.
– Решениях и обходных путях, которые клиенты создали сами.
– Контекстах, в которых рушатся ваши предположения.
Далее, отранжируйте предположения по тому:
– Насколько они важны для целей продукта.
– Насколько вы в них НЕ уверены.
сосредоточив исследование на предположениях с высокой степенью критичности и неопределённости. Эти идеи часто более ценны, чем подтверждение того, что вы итак уже знали и ожидали.
Discovery — навык. Цель discovery — ясность. Неопределённость — это тоже данные.
Опытные продакты начинают с НЕТ — что вашим пользователям не нужно то, что вы создаёте. А затем выстраивают убеждение на основе идей и находят ДА к тому, что пользователи действительно хотят.
Парадокс в том, что:
– Название нашей должности предполагает, что мы должны знать, чего хотят пользователи.
– Пользователи ожидают, что у нас это будет.
– Наша дорожная карта подразумевает, что мы это поняли.
По факту же:
– Мы разговариваете с пользователями, но задаём наводящие вопросы, которые подтверждают наши же идеи.
– Мы отбираем ту обратную связь, которая совпадает и поддерживает нашу дорожную карту.
– Мы относимся к исследованию пользователей как к проверке, а не как к исследованию.
Настоящее discovery начинается с другого мышления.
Вместо «Нам нужно проверить идею этой функции», думайте «Нам нужно понять эту проблемную область и ситуацию».
Вместо «Хотят ли пользователи фичу?» спросите «Чего на самом деле пытаются достичь пользователи?»
Перед любым разговором с пользователем перечислите свои предположения:
– У кого есть эта проблема?
– Когда они с ней сталкиваются?
– Как они решают её сегодня?
– Что сделало бы решение ценным для них?
– Что заставило бы их отказаться от текущего подхода?
Задавайте вопросы:
Расскажите о последнем случае, когда вы столкнулись с [проблемной областью]?
Расскажите мне, как вы сейчас справляетесь с [ситуацией]?
Что больше всего расстраивает в вашем текущем подходе?
Прислушивайтесь к:
– Частоте (как часто это происходит?).
– Силе (насколько болезненным является опыт?).
– Альтернативам (что ещё они пробовали?).
– Контексту (когда это имеет наибольшее значение?).
Составьте карту шаблонов:
– Какие проблемы возникают у нескольких сегментов пользователей?
– Какие контексты делают проблемы более/менее болезненными?
– Какие решения пользователи постоянно хвалят или критикуют?
– По каким результатам они измеряют успех?
Ищите неожиданные идеи в:
– Проблемах, о существовании которых вы не знали.
– Решениях и обходных путях, которые клиенты создали сами.
– Контекстах, в которых рушатся ваши предположения.
Далее, отранжируйте предположения по тому:
– Насколько они важны для целей продукта.
– Насколько вы в них НЕ уверены.
сосредоточив исследование на предположениях с высокой степенью критичности и неопределённости. Эти идеи часто более ценны, чем подтверждение того, что вы итак уже знали и ожидали.
Discovery — навык. Цель discovery — ясность. Неопределённость — это тоже данные.
Product Management & AI
Во всей шумихе с автоматизацией ИИ уделяют мало внимания сервисам старой эпохи а-ля Zapier и IFTTT, которые позволяют подключать практически любые популярные приложения и сервисы и связывать их с такими же сервисами и приложениями триггерами и экшенами. И…
Wade Foster, C-f & CEO Zapier: Мы устанавливаем новый стандарт: 100% новых сотрудников должны свободно владеть ИИ.
Как мы измеряем свободное владение ИИ в Zapier?
Вот несколько примеров для каждой роли. Обратите внимание, что это не требования или поля для проверки. Просто краткие примеры типов навыков, которые мы оцениваем.
Мы сопоставляем по 4 уровням: неприемлемый, способный, адаптивный и преобразующий.
Оценка происходит при отборе, тестах навыков, асинхронных упражнений и живых интервью. Сигналы объединяются на разных этапах.
Неприемлемый: устойчивый к инструментам ИИ и скептически относящийся к их ценности.
Способный: использующий самые популярные инструменты ИИ. Вероятно, менее 3 месяцев опыта использования ИИ.
Адаптивный: сотрудники, интегрирующие ИИ в личные рабочие процессы. Они настраивают подсказки, объединяют модели в цепочки и автоматизируют задачи для эффективности.
Трансформирующий: золотая середина. Используют ИИ для переосмысления стратегии и предложения пользователям решений, которые были невозможны 2 года назад.
Некоторые из вас спрашивали реальные вопросы, которые мы задаём в интервью:
Маркетинг:
– Как ИИ меняет то, как вы планируете или проводите рекламные кампании?
– Как вы используете ИИ для персонализации сообщений, генерации контента или анализа эффективности?
Сотрудники:
– Можете ли вы поделиться примером того, как вы используете ИИ в своей повседневной работе?
– Можете ли вы поделиться примером процесса или программы, которую вы создали с помощью ИИ? (инструменты, результаты и т. д.).
Продукт:
– Как ИИ влияет на SaaS?
– Приведите пример случая, когда вы использовали ИИ в функции продукта. Что улучшилось?
Еще несколько моментов, на которые стоит обратить внимание:
– Это не единственные приемлемые ответы. Навыки работы с ИИ различаются и в значительной степени зависят от роли.
– Ничто из этого не является Евангелием. Чтобы улучшить: пробуйте, собирайте данные, улучшайте на основе данных. Планка будет продолжать расти.
– Инженерия ≠ Маркетинг ≠ Поддержка. Контекст имеет значение. Требования различаются.
Понедельники спокойствий
Помимо выбора, решений, обсуждений, встреч, созвонов, писем – понедельники для личных и спокойных размышлений.
Чем больше мнений, тем сильнее думаешь о них.
Все встречи и созвоны – снова диалоги мнений и решений.
Больше решений → хочется их все принять и донести → больше встреч-созвонов-диалогов-мнений...
Ch-i-i-i-ll.
Спокойствия недели размышлений.
Помимо выбора, решений, обсуждений, встреч, созвонов, писем – понедельники для личных и спокойных размышлений.
Чем больше мнений, тем сильнее думаешь о них.
Все встречи и созвоны – снова диалоги мнений и решений.
Больше решений → хочется их все принять и донести → больше встреч-созвонов-диалогов-мнений...
Ch-i-i-i-ll.
Спокойствия недели размышлений.
Apple выкатила исследование, что Claude, DeepSeek-R1 и o3-mini, на самом деле... вообще не рассуждают. Они просто очень хорошо запоминают шаблоны.
Вместо того, чтобы использовать старые математические тесты, Apple протестировали эти модели на задачах, с которыми они никогда раньше не сталкивались – головоломки.
В Apple обнаружили, что эти модели вообще не рассуждают, а вместо этого выполняют сложное сопоставление шаблонов, которое отлично работает, пока сами шаблоны не становятся слишком сложными.
По мере того, как они становились сложнее, эти «мыслящие» модели начинали думать меньше, использовать меньше токенов и быстрее сдаваться в ответе, несмотря на неограниченный бюджет и вычислительные мощности.
📜 The Illusion of Thinking: Understanding the Strengths and Limitations of Reasoning Models via the Lens of Problem Complexity
Вместо того, чтобы использовать старые математические тесты, Apple протестировали эти модели на задачах, с которыми они никогда раньше не сталкивались – головоломки.
Результат: все модели «рассуждений» упираются в стену сложности, где полностью разрушаются до точности 0%
В Apple обнаружили, что эти модели вообще не рассуждают, а вместо этого выполняют сложное сопоставление шаблонов, которое отлично работает, пока сами шаблоны не становятся слишком сложными.
По мере того, как они становились сложнее, эти «мыслящие» модели начинали думать меньше, использовать меньше токенов и быстрее сдаваться в ответе, несмотря на неограниченный бюджет и вычислительные мощности.
📜 The Illusion of Thinking: Understanding the Strengths and Limitations of Reasoning Models via the Lens of Problem Complexity