Долгое время мы работали как команда проектных менеджеров. За каждым был закреплен определенный пул работ над конкретными модулями нашей платформы: мы собирали требования, согласовывали приоритеты, планировали задачи вместе с разработчиками и следили за их выполнением. У каждого была понятная зона ответственности.
С активным развитием и внедрением искусственного интеллекта этот подход начал меняться. Мы оцифровывали рабочие процессы и видели, что часть привычных задач по координации можно передавать цифровым инструментам. Одновременно требовалось больше участия в самом решении: разобраться в проблеме, понять, кому и зачем нужен результат, выбрать способ реализации и оценить, что он дал клиенту. Работа выходила за рамки координации задач внутри закрепленного модуля. Да и сама наша платформа менялась, становилось тесно в привычных рамках.
Поэтому нам пришлось пересмотреть и обязанности, и саму роль специалиста. Несколько месяцев мы искали название, которое отражало бы эту изменившуюся ответственность. Так мы пришли к продуктовому инженеру — человеку, который ведёт решение от постановки проблемы до результата у клиента.
Такой специалист может:
- предложить идею в ответ на внутренний или клиентский запрос,
- сам выполнить часть работы либо собрать нужную команду,
- провести решение через разработку и проверить, что оно дало на практике.
Передача задачи другим специалистам не снимает с него ответственности за общий итог.
Почему прежней схемы стало недостаточно
В классической схеме проектный менеджер помогает разным специалистам работать согласованно. Он уточняет поручения, сроки, зоны ответственности и следит, чтобы задачи не застревали между подразделениями. Это необходимо, но само по себе не отвечает на другой вопрос: что будет с решением после того, как каждый выполнит свою часть?
Сегодня в нашей команде круглосуточно работают более 400 ИИ-агентов. Они пишут и используют несколько тысяч инструкций и скриптов и фактически взяли на себя всю операционную работу. За людьми остались коммуникации, принятие решений, валидация и применение полученного результата. Это изменило и требования к нашей роли: координации участников и контроля сроков уже недостаточно. Нужно разобраться, зачем мы вообще это делаем, кому нужно решение, почему выбираем именно такой подход и по каким признакам поймём, что он сработал. Поэтому фокус работы сместился с организации отдельных задач на ответственность за весь путь от проблемы до результата.
В новой роли мы постарались соединить продуктовое мышление с пониманием разработки и взять ответственность за путь решения целиком. Один специалист не заменяет всю команду — он понимает, кого и на каком этапе нужно подключить.
Почему именно «инженер»
Мне важно это слово. Инженер для меня — это человек, способный применить знания к конкретной проблеме и создать работающий способ её решения. Ему нужно разобраться в условиях, выбрать подход, проверить его и при необходимости изменить.
Но он должен ориентироваться в этих областях настолько, чтобы ставить содержательные вопросы, понимать ограничения и привлекать коллег с более глубокой экспертизой. Ему нужны и продуктовые, и технические метрики: без первых трудно оценить пользу для клиента, без вторых — понять, насколько жизнеспособно само решение.
Масштаб ответственности зависит от задачи. Иногда нужно довести до результата отдельную функцию, иногда — крупную поставку или новое направление. В каждом случае специалист проходит с идеей сквозной цикл, вместо того чтобы передать её дальше и потерять из виду.
Как в эту работу вписывается ИИ
ИИ делает некоторые действия быстрее, но не даёт человеку готовую экспертизу. Чтобы передать инструменту часть своей работы, сначала нужно самому понимать, как она устроена, чего мы хотим добиться и какой результат можно считать приемлемым. Иначе специалист не сможет ни поставить задачу, ни заметить ошибку.
Спрос на это умение растёт: «Авито Работа» и chad зафиксировали в первом полугодии 2026 года на 37% больше вакансий с требованием ИИ-навыков, чем за тот же период годом ранее. Но востребованность навыка сама по себе не решает вопрос, как встроить инструмент в работу над продуктом.
Осваивать такой подход непросто. Нужно развивать собственные навыки, не уходить целиком в одну узкую область и одновременно учиться использовать ИИ для воспроизведения того, что уже умеешь делать. Для продуктового инженера это особенно существенно: он работает на стыке нескольких направлений и должен соотносить технические возможности с потребностью бизнеса и клиента.
Новая должность требует изменений с обеих сторон
Мы не взяли готовую должностную инструкцию с рынка. Посмотрели, какие задачи и компетенции уже накопились в команде, и на этой основе описали новую роль. С 1 августа она появилась в нашей структуре. Это помогло обозначить направление развития для сотрудников, хотя более широкая ответственность у некоторых вызвала и тревогу. Такую перемену нельзя провести одним переименованием.
Компании тоже приходится меняться. Если мы хотим получить человека, который самостоятельно замечает проблему, предлагает решение и отвечает за весь цикл, ему нужны возможность влиять на этот цикл, поддержка коллег и соответствующая мотивация. В идеале продуктовый инженер похож на предпринимателя внутри компании: он относится к результату как к своему делу, хотя работает вместе с командой и внутри организации.
Мы уже начали искать специалистов на эту роль и по итогам поиска лучше поймем, сколько людей с подходящим сочетанием навыков есть на рынке. Пока я бы не утверждал, что название профессии стало общепринятым. Но потребность, из которой она выросла, для меня ясна: когда отдельные операции можно ускорить и частично передать ИИ, особенно важен человек, который способен связать идею, реализацию и результат.
