Раньше, чтобы довести продукт до пользователя, нужна была цепочка людей: продакт решает что строить, аналитик описывает, backend и frontend пишут, тестировщик проверяет, девопс выкатывает. Продукт-инженер — это человек, который проходит эту цепочку сам, используя ИИ как рабочую силу. Не потому что он гений во всех областях, а потому что объём работы, ради которого держали цепочку, теперь снимает агент.
Это не манифест, а конкретная роль с конкретным циклом работы. Разберём, из чего она состоит.
Цикл продукт-инженера: шесть шагов и возврат к первому; агент снимает объём на третьем и четвёртом, направление и метрику держит человек.
Цикл работы: от проблемы до метрики
Работа продукт-инженера — это повторяющийся цикл из шести шагов:
- Понять проблему. Не «сделать фичу X», а разобраться, что болит у пользователя и зачем это чинить (проблема, а не решение).
- Выбрать наименьший срез. Не строить всё — выбрать минимальный кусок, который уже несёт ценность и который можно проверить (наименьший ценный срез).
- Поставить задачу агенту. Превратить срез в чёткий контракт: что строим, как проверяем, что не трогаем (срез → контракт, работа с агентами).
- Принять результат. Прочитать диф, прогнать тесты, проверить против контракта — не принять на веру (приёмка результата AI).
- Довести до пользователя. Выкатить, убедиться, что работает в бою (релиз и метрики).
- Померить бизнес-результат. Не «фича выпущена», а «проблема решилась»: смотрим метрику, решаем, что дальше (бизнес-метрика).
И снова к шагу 1. Прогон цикла меряется днями и неделями, а не месяцами: срез такого размера выпускают за одну-две недели, а первые числа после выката смотрят не через месяц, а в ближайшие дни. Агент снимает объём, человек держит направление и качество.
Чем это отличается от разработчика
Разработчик получает задачу и возвращает код. Что строить, зачем, дошло ли до пользователя, помогло ли — вопросы за пределами его контура. Продукт-инженер владеет всем контуром: он сам решает, что строить (в рамках цели), сам доводит до пользователя, сам отвечает за бизнес-результат.
При этом инженерный фундамент никуда не девается — он становится важнее. Печатает код агент, но чтобы поставить агенту контракт и принять его работу, нужно понимать, что под капотом: как устроены данные, стыки, сеть, отказы. Продукт-инженер — это инженер, который прошёл технический фундамент (backend/frontend), а не менеджер с подпиской на Claude. Без фундамента нельзя отличить работающий код от правдоподобного.
Чем это отличается от продакт-менеджера
Продакт решает, что строить, — и передаёт дальше. На каждом стыке передачи теряется контекст: продакт имел в виду одно, разработчик понял другое, к пользователю доехало третье.
Продукт-инженер решает что — и доводит сам. Стыков нет, контекст не теряется, скорость определяется циклом одного человека, а не согласованием пяти. Обратная сторона: и продуктовые ошибки, и технические — тоже его. Владение бизнес-результатом означает владение и провалом.
Что для этого нужно уметь
Роль складывается из трёх слоёв навыков — по ним и построена эта программа:
- Понимать ИИ и управлять агентами. Как модели работают, где они врут, как вести агента через задачу — от понимания кодовой базы до отладки. Это ваш новый основной инструмент, и владеть им нужно так же уверенно, как раньше — редактором кода.
- Думать продуктом. Докапываться до проблемы, говорить с пользователями, мерить бизнес-результат. Это то, чего у типичного инженера нет, и что превращает «кодера с агентом» в человека, который делает продукт.
- Держать качество на объёме. Когда агент генерирует много и быстро, нужен способ не утонуть: контракты, исполняемые правила, дисциплина приёмки.
Коротко
- Продукт-инженер проходит цепочку «продакт, аналитик, разработчики, тестировщик, девопс» сам: объём снимает агент, а направление и качество держит человек.
- Цикл из шести шагов: понять проблему, выбрать наименьший срез, поставить контракт агенту, принять результат, довести до пользователя, померить бизнес-результат; прогон меряется днями и неделями.
- От разработчика его отличает владение всем контуром: что строить, дошло ли до пользователя и помогло ли, а не только код по задаче.
- От продакт-менеджера отличает отсутствие стыков: решает что и доводит сам, поэтому и продуктовые, и технические ошибки его.
- Инженерный фундамент становится важнее, а не лишним: без него нельзя поставить контракт и отличить работающий код от правдоподобного.
- Три слоя навыков: понимать ИИ и вести агента, думать продуктом, держать качество на объёме через контракты, исполняемые правила и приёмку.
Что почитать дальше
- Проблема, а не решение — с чего начинается любая задача: докопаться до работы за просьбой.
- Как работают модели ИИ — инструмент, на котором стоит весь цикл, если он пока незнаком.
- Наименьший ценный срез — как выбрать кусок, который выпускают за одну-две недели.
- Программа раздела — весь путь продукт-инженера по шагам.