Loop Engineering for Product Managers

Цикл — это процесс, который ваша система ИИ проходит неоднократно: вы меняете что-то, что формирует поведение агента; вы управляете агентом; вы оцениваете результат; вы сохраняете изменения, если качество улучшается, и отменяете их, если качество падает. Затем вы фиксируете обучение, чтобы следующая версия начиналась раньше предыдущей.

На самом деле, всё начинается с артефактов, которые формируют работу над продуктом: навык PRD-ревью, сумматор звонков клиентам, критерий оценки, контрольный список запуска, процесс исследования, инструкция CLAUDE.md, шаблон промпта или система расстановки приоритетов. Всё это долговечно и это можно использовать повторно.

Промпты сами по себе не решают проблему

ИИ-агенты изменили рабочий процесс продакт-менеджера. Вам больше не нужно просто писать спецификацию, передавать её инженерам, ждать, проверять и повторять всё заново. Теперь вы вообще можете сами формировать первую версию продукта :))

Но поработав так некоторое время, вы сталкиваетесь с другой проблемой –ваше рабочее пространство с ИИ начинает «дрейфовать» и терять исходную настройку

`CLAUDE.md` разрастается, требования к проверке PRD становятся всё строже, в процесс исследования проникают инструкции из прошлых проектов, а чек-лист запуска раздувается настолько, что агент начинает игнорировать его половину. Критерии оценки меняются, а вы забываете, когда и почему это произошло.

Спустя месяц работа агента ухудшается и он пишет менее качественные PRD, выдаёт шаблонные сводки по исследованиям и упускает нюансы продукта, которые раньше замечал.

Скорее всего, сама модель не стала хуже. Просто ваши рабочие артефакты «уплыли» от первоначального курса, а за этим никто не следил.

Именно эту проблему — проблему «цикла» — инженерия решает для продакт-менеджеров.

И главное в этом не о том, чтобы улучшить один конкретный промпт, а о том, чтобы артефакты, определяющие работу над продуктом, совершенствовались, а не деградировали со временем.

Из чего на самом деле состоит цикл

Полезный цикл включает пять элементов: триггер, действие, доказательство, память и условие остановки.

• Триггер определяет момент запуска цикла.
• Действие указывает, что именно должен сделать агент.
• Доказательство подтверждает, что результат стал лучше.
• Память фиксирует полученный опыт.
• Условие остановки определяет, когда цикл должен завершиться.

Последний элемент особенно важен для рекурсивных циклов.

Многие системы на базе ИИ терпят неудачу не из-за плохой модели, а из-за отсутствия четкого выхода из цикла

Так, ИИ-агент продолжает генерировать контент, расширять границы задачи и придумывать себе новую работу. Или же выдает уверенное резюме, не имея для этого достаточных оснований.

Хороший цикл для продакт-менеджера должен допускать возможность сказать: «ничего существенного не изменилось», «входных данных недостаточно», «процесс заблокирован», «не достигнут требуемый уровень качества» или «здесь необходимо решение человека».

Если вы хотите увидеть подобные циклы в реальной практике, обратитесь к библиотеке циклов (Loop Library) Мэтью Бермана: в ней собраны примеры из сфер инженерии, исследований и операционной деятельности. Хотя эти циклы разработаны для инженеров, их пять составляющих применимы и в работе менеджеров продуктов.

Как это выглядит на практике

Возьмем для примера анализ обращений клиентов.

Простой вариант — попросить ИИ-агента: «Сделай краткий обзор этих звонков». Это полезно разово, но не улучшает качество обработки звонков в будущем.

Более совершенный вариант — инструмент для анализа звонков, который «понимает», что важно вашей команде: «боли» клиентов, текущие обходные решения, срочность, возражения, недостатки продукта, точные цитаты и необходимые последующие действия.

Вариант с циклом обратной связи (loop) работает еженедельно. Система анализирует звонки, сопоставляет новые данные с ранее выявленными темами, отмечает повторяющиеся моменты, новинки и ситуации, где не хватает подтверждающих данных. Вы проверяете результат. Если в обзоре упущены нюансы, вы корректируете сам инструмент (артефакт). Следующая итерация проходит лучше.

То же самое касается проверки PRD (документа с требованиями к продукту).

Простой вариант — вопрос: «Можешь проверить этот PRD?» Более совершенный вариант — инструмент для проверки PRD, настроенный с учетом стандартов качества вашей команды. Вариант с циклом обратной связи проверяет, действительно ли этот инструмент дает более качественную обратную связь.

Выявляет ли он расплывчатые формулировки? Требует ли реальных доказательств? Указывает ли на отсутствие метрик? Избегает ли бесполезных придирок? Сохраняет ли он замысел продукта?

Промптинг помогает выполнить задачу один раз. «Loop engineering» (проектирование циклов) совершенствует инструмент, который определяет, как эта задача будет выполняться каждый раз.

Ваш первый цикл: еженедельный анализ продуктовых сигналов

Я бы не стал начинать с цикла, призванного определять стратегию продукта.

Это слишком масштабная и субъективная задача, в которой легко допустить ошибку. Лучше начать с операционной деятельности (product ops). Именно здесь сосредоточена повторяющаяся работа, здесь находятся фактические данные и здесь критически важна системность.

Хорошим первым циклом может стать еженедельный процесс сбора и анализа продуктовых сигналов.

Каждую пятницу в рамках этого цикла обрабатываются записи звонков клиентов, обращения в службу поддержки, заметки отдела продаж, результаты экспериментов, аналитические сводки, информация о выпущенных изменениях и открытые вопросы, требующие эскалации. Итогом становится единая аналитическая записка с продуктовыми сигналами.

Эта записка не должна быть просто общим обзором. В ней необходимо отделять повторяющиеся сигналы от случайного «шума».

В документе следует приводить точные формулировки клиентов, отражать изменения по сравнению с предыдущей неделей, указывать на области с недостаточным объёмом данных, а также отмечать, какие предположения, заложенные в дорожную карту, подтвердились, опроверглись или остались неизменными.

Вы изучаете этот документ. Если в нем упущено что-то важное — вносите правки. Если составитель придал слишком большое значение слабым доказательствам — уточняете критерии оценки. Если возник новый вопрос по продукту — включаете его в фокус внимания на следующую неделю.

Через несколько недель этот процесс начинает приносить реальную пользу.

А через несколько месяцев он становится обязательным материалом для ознакомления перед любым обсуждением дорожной карты.

Интуитивное чутьё по-прежнему важно, но теперь оно требует подтверждения фактами

Продуктовые менеджеры всегда полагались на интуицию.

Хороший менеджер продукта, читая спецификацию (PRD), сразу чувствует, если постановка проблемы размыта. Он понимает, когда цитату клиента пытаются притянуть за уши, и видит, когда план запуска игнорирует реальные зависимости.

Эта способность судить по существу остается важной. Построение подобных рабочих циклов не отменяет её — напротив, оно ставит профессиональное суждение во главу угла.

Теперь главная задача сводится к тому, что описано в последней строке поста: определить, что именно считается «правильным», и понять, когда этот критерий соблюден. Вопрос лишь в том, как сделать это, не полагаясь на догадки.

Но когда вы облекаете свои профессиональные суждения в форму инструментов многократного использования (артефактов), ваш «вкус» и интуиция требуют подтверждения.

• Если вы меняете инструмент для проверки PRD, как узнать, стал ли он лучше?
• Если обновляете алгоритм обобщения результатов исследований, как понять, что он улавливает больше полезной информации, а не просто больше шума?
• Если ужесточаете чек-лист перед запуском, как убедиться, что это увеличивает готовность, а не просто добавляет лишней бюрократии?

Именно здесь оценка эффективности (evals) становится частью работы продакт-менеджера.

Оценка, проводимая PM-ом, не обязательно должна быть масштабным бенчмарком. Можно начать с уже известных примеров.

Возьмите три качественных PRD и три слабых. Проверьте их с помощью своего инструмента анализа PRD. Выявил ли он реальные пробелы? Удалось ли избежать придирок по мелочам? Сохранился ли замысел продукта?

Возьмите записи пяти разговоров с клиентами, содержание которых вам уже хорошо знакомо. Запустите свой инструмент обобщения исследований. Уловил ли он реальные «боли» клиентов? Точно ли передал цитаты? Сумел ли отличить важные сигналы от случайного шума?

Возьмите два прошлых запуска: один успешный и гладкий, другой — проблемный. Прогоните их через свой процесс проверки готовности к запуску. Выявил бы он ту самую проблему, которая в итоге привела к сбою?

Это и есть проектирование рабочих процессов (loop engineering). Вы спрашиваете не «Выглядел ли агент умным?», а «Стал ли этот инструмент лучше соответствовать проверенным продуктовым решениям?»

Системе нужна «память»

Как только вы начинаете оценивать артефакты, вам нужно место, где будут сохраняться полученные знания, иначе работа пойдет насмарку.

И здесь на помощь приходит GitHub. Не потому, что продакт-менеджерам нужно становиться инженерами, а потому, что им необходима история версий для артефактов, которые все больше определяют их работу.

В нём хранится сам артефакт, в нём фиксируются изменения, в нём сохраняются результаты оценки, журнал принятых решений и возможность отката к предыдущей версии:

• Если артефакт стал лучше — вам нужен коммит.
• Если хуже — нужно видеть разницу (diff).
• Если изменились критерии оценки — нужно понимать причину.
• Если в ходе проверки перед запуском была выявлена ​​серьёзная проблема, препятствующая релизу, важно сохранить этот опыт для следующего запуска.

Репозиторий становится своего рода «памятью продукта».

Базовая структура любого цикла

Не нужно всё усложнять.

Выберите одну повторяющуюся задачу по продукту. Запишите: когда она запускается, какие входные данные использует, какой артефакт служит для нее ориентиром, что должен делать агент, как выглядит качественный результат, где сохраняются полученные знания и когда цикл должен завершиться.

Этого достаточно для начала.

Главное — сделать цикл достаточно компактным, чтобы можно было реально оценить, растёт ли его эффективность. И в любом серьёзном цикле, управляемом ИИ, должно быть чётко обозначено, за что по-прежнему отвечает человек.

• Цикл может обобщать отзывы клиентов, но не должен самостоятельно определять стратегию.
• Цикл может анализировать PRD, но не должен становиться продуктовым лидером.
• Цикл может сигнализировать о рисках при запуске, но не должен принимать решения, требующие компромиссов, без учета контекста.

Где возникают сбои

Обычно проблемы с циклами возникают по простым причинам:

• Нечёткий триггер.
• Хаотичные входные данные.
• Слишком объемный артефакт.
• Субъективная оценка результата.
• Отсутствие места для накопления знаний.
• Слабое условие завершения.

Или же вы слишком рано наделяете цикл чрезмерными полномочиями.

Последнее — это ловушка. Не начинайте с цикла, способного менять стратегию, писать клиентам, обновлять дорожную карту или брать на себя обязательства по продукту без предварительной проверки.

Начинайте с циклов, которые помогают принять решение, остающееся за вами. Позвольте им завоевать доверие, а затем постепенно расширяйте их автономность.

Пожалуй, это самый здоровый подход к работе с агентами в сфере управления продуктом.

Как меняется профессия

Раньше работа продакт-менеджера сводилась к переводу: боли клиентов в требования; бизнес-цели в дорожную карту; технические ограничения в компромиссные решения.

Эта работа никуда не делась. Но поверх нее появился новый уровень.

Теперь вы проектируете системы, которые позволяют воспроизводить продуктовые суждения. Вы создаете артефакты, управляете их версиями, оцениваете их и замечаете, когда они начинают отклоняться от нормы. Агент выполняет задачу, а вы отвечаете за то, чтобы процесс её выполнения становился все более качественным.

Лучшими продакт-менеджерами станут не те, у кого самая большая библиотека промптов, а те, кто понимает, какие этапы продуктовой работы стоит превратить в устойчивые циклы, какие артефакты должны ими управлять, а какие решения должны оставаться прерогативой человека.

Таково будущее профессии продакт-менеджера.