С разработчиками разобрались — их заменить на АИ не выйдет еще долго Но давайте поговорим про «__Менеджеров по продукту__» – потому что, мне кажется, эта позиция уже меняется на рынке Идеальный менеджер по продукту, до эпохи АИ, был человеком который поможет команде строить ИТ продукт — на основе данных и/или продуктового чутья, которое я называю «__отношение между компьютером и человеком__» Хороший продакт менеджер до эпохи АИ знал много формул, запросы в базы данных, метрики, фреймворки, которые помогали команде не ошибиться в разработке софта с точки зрения бизнеса, а главное — улучшить продукт, если он уже существует (опять же, улучшить, с точки зрения бизнеса, что не всегда значит, что что-то стало удобнее для нас, пользователей) Хороший пример «Менеджера по продукту», как по мне, всегда был Дуров: Он первым заметил проблему старого WhatsApp в медлительности его работы, Павел всегда уделял много внимания к мелочам (и, к сожалению стикеру «🍆») и сколько бы фич они не навесили на телеграм, его команда очень бережет основные сценарии использования — за которые Телеграм и любят. Дуров хороший эксперт продуктового чутья между человеком и компьютером Хороший продакт менеджер до эпохи АИ, имел секретное сакральное знание как делать «хорошо» и получали менеджеры такие знания на 90% на практике — видя влияние новых кнопок на продукт, учась у старших и проходя разные __симуляторы__ обучения продукту А теперь все меняется — знания как сделать приложение или сайт «удобными, хорошими» доступны кому угодно — ты скармливаешь в o3 продуктовые проблемы и с вероятностью в ~90% получаешь качественное решение – каждый разработчик, теперь сам может узнать (если захочет): 📔 Как улучшить метрики и какие это могут быть метрики; 📔 Как убедить команду и руководство, как лучше выстроить стратегию коммуникации; 📔 Где может сломаться, что может не понравится пользователям; 📔 Как выстроить маркетинг вокруг фичи; Мульти-модальные LLM даже макеты дизайна могут оценивать в плане удобства. На наших глазах происходит «__демократизация__» знаний менеджера по продукту — я лично знаю много талантливых разработчиков, которые делают с LLM-вместо-продакта софт, по которому вообще не скажешь что это один человек все пилит И реальный вопрос, который у меня возникает: «__А продакт менеджеров заменит АИ?__» Учитывая, что: 💿 Сакральные знания разработки ПО теперь доступны в простом виде всем и разработчики активно ими пользуются; 💿 Анализ данных продукта с АИ — очень простая задача, он и запросы напишет, и сам отчеты/графики построит которые просто нужно перепроверить; 💿 Исследование рынка теперь мало кого впечатлит, учитывая Deep Research и аналоги; Мне кажется, что сама роль «__Менеджера по продукту__» сильно поменяется в сторону «__АИ Менеджера по продукту__»: от продактов будут ждать нативного владения всеми АИ-инструментами на уровне бизнес-процессов и понимания какие рабочие процессы уже сегодня можно делегировать АИ. На понимании, конечно, не закончится — АИ-продактам придется менять бизнес процессы компании, повышая эффективность От АИ-продактов, скорее всего, будут ждать стратегического развития бизнеса — не только найти данные Х (желательно в автоматическом режиме) но и проверить их, и выстроить стратегию вокруг того, как находка принесет пользу бизнесу. Простой пример: АИ-продакт должен знать, что возможно предложить пользователям из АИ-фич в своем продукте и сделать это не в лоб, а проведя весь путь изучения темы: от поиска проблемы, формирования фичи, до подсчета себестоимости, так как АИ-фичи стоят дорого Естественно, все еще нужны будут люди, кто принимает решение за то, что АИ там нагенерировал и выбирает из предложенных вариантов — поэтому одна из задач АИ-продактов будет отличить «плохой» и «хороший» совет от АИ-инструмента __Часть 2__