Как мы разработали ИИ-ассистента и сократили рутину продуктовой команды на 50%

Привет! Меня зовут Артём, я занимаю должность владельца продукта. Развиваю направление бренд-медиа Совкомбанка, которое включает в себя Совкомблог ^[1] и Халва Медиа ^[2].

Если вы работаете в финтехе, то знаете: продуктовые менеджеры тонут в рутине. Документация, согласования, бесконечные уточнения «а что имел в виду бизнес?», приоритизация бэклога, аналитика, стратегии… А на нормальную работу с клиентом — ту самую, ради которой мы вообще пришли в продукт – остается совсем чуть-чуть.

У нас эта проблема стала критичной, когда портфель цифровых продуктов Совкомбанка вырос быстрее, чем штат продуктовой команды. В какой-то момент мы осознали, что каждый PM тратит на рутину до 60% времени. И дело не в том, что мы плохо организовались — проблема была системной: чем больше продуктов, тем больше текстов, табличек, чек-листов и пояснительных записок.

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

О чем расскажу:

1. Как я проектировал ИИ-ассистента ^[3]

2. Какие продуктовые фреймворки заложил в основу ^[4]

3. Почему это реально помогло команде ^[5]

4. Над чем работаем: какие новые инструменты освободят еще больше времени ^[6]

Архитектура промпта: собираем продуктового ассистента как конструктор

Я подходил к промпту как к архитектуре мини-продукта. Мне нужна была система, которая:

1. Понимает контекст (какой продукт, аудитория, бизнес-цель).

2. Имеет набор «модулей» (задач), которые можно вызывать по запросу.

3. Подстраивается под роль пользователя (PM, C-level, новичок).

4. Помнит, что мы в банке и соблюдает все требования.

5. Выдает не «текст ради текста», а заготовки, таблицы, структуру, которую можно реально взять и донести до команды.

В итоге родилась структура, которая стала основой ассистента. Ниже я расскажу, какие элементы промпта сделали его реально полезным.

1. Роль и контекст (System Prompt)

Первое — я задал жесткую роль:

«Ты — ИИ-ассистент для продуктовых менеджеров и бизнес-лидеров в банке. Ты помогаешь в полном цикле продуктовки: от определения ценности до оптимизации и GTM, с фокусом на финтех (мобильный банк, кредиты, инвестиции)».

Зачем это? В банке ассистент не может рассуждать как консультант из вакуума. Любая «классная идея» без учета AML/152‑ФЗ/рисков/фрода — это будущий инцидент, который мы будем исправлять несколько часов.

2. Инициализация: сначала контекст, потом работа

Второй ключевой момент — ассистент не должен отвечать «с потолка». Поэтому я встроил принудительную инициализацию. 

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

Мы назвали это «Шаг 1: Инициализация». Без него — никак. Да, иногда бесит, что надо ответить на пять вопросов, но это тот случай, когда чуть больше дисциплины дает в разы меньше галлюцинаций.

3. Библиотека задач (16 модулей)

На следующем этапе я выписал, какие задачи по продукту мы делаем чаще всего: от идеи до запуска и оптимизации. Получилось 16 модулей. Каждый — «промпт внутри промпта»: входные данные, формат ответа, чек-листы, типовые ошибки ^[7].

Вот несколько примеров, что закрывают эти модули:

• Определение ценности — формулирует JTBD и ценность для бизнеса, учитывая комплаенс.

• Юнит-экономика — считает LTV, CAC, ROI. Модуль понимает банковскую специфику (churn, стоимость фондирования).

• Дерево метрик — строит иерархию от North Star до вспомогательных метрик, сегментирует их на продуктовые, коммерческие и операционные.

• Анализ рисков — использует FMEA, добавляет AML, ФЗ-152, фрод-модели. Для банка это один из самых востребованных модулей.

• GTM-стратегия — генерирует не общие слова, а конкретный месседжинг, каналы и сегментацию (например, через RFM).

Каждый модуль выдает результат в структурированном виде: таблицы, списки, фреймворки. Никакой «воды».

4. Адаптация под роль (PM / C-level / новичок)

Одна из самых «магических» фич, хотя технически она простая: ассистент подстраивает ответ под роль.

• Если пишет PM — больше тактики: что сделать завтра, как описать в Jira, какие события положить в Amplitude, какие артефакты подготовить.

• Если пишет C-level — меньше деталей, больше ROI, P&L-логики, просчета рисков, учета зависимости от стратегии банка.

• Если пишет новичок — больше терминов: система не делает вид, что «и так все понятно».

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

5. Принцип «одного окна» и связанные задачи

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

Например, мы сделали юнит-экономику — он предложит:

• собрать дерево метрик;

• приоритизировать гипотезы (RICE/ICE);

• упаковать это в PRD.

Это дает ощущение нормального продуктового процесса, а не разрозненных запросов «сделай то / сделай это».

Как мы внедряли ассистента и почему это сработало

Нет смысла приходить к команде и говорить: «Вот вам промпт, удачи» — им не будут пользоваться (или будут, но неэффективно). Поэтому новый инструмент я внедрял постепенно — в три этапа.

Этап 1: «Инженерная настройка»

Я собрал топ-10 самых частых и болезненных задач, которые команда решала вручную, прогнал их через ассистента (предварительно объяснив контекст) и проверил качество ответов. Затем дорабатывал формулировки, чтобы ассистент лучше понимал нашу специфику.

Довольно быстро стало понятно, что основная проблема не в качестве модели, а в дисциплине: если позволить ассистенту додумывать цифры — он начнет это делать.

Поэтому я зафиксировал правило: никаких выдуманных данных. Нет цифр? Значит, попроси или скажи, где их проверить (внутренний дашборд/витрина). Для банковской аналитики это критично.

Этап 2: «Продуктовое обучение»

Я провел несколько воркшопов и показал команде, как работает ассистент.

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

Если правильно сформулировать задачу, ассистент станет «второй парой глаз»: будет проверять гипотезы, напоминать о рисках, ускорять подготовку материалов.

Этап 3: «Измерение результата»

Через месяц я замерил ключевые метрики эффективности команды. Самое заметное:

• Подготовка документов (PRD, GTM-план, риск-анализ) — минус 50% времени. Раньше писали с нуля, теперь ускорились: загрузили контекст → получили структуру → адаптировали под реальность.

• Скорость вывода гипотез в разработку выросла примерно в два раза. То, что раньше занимало до трех дней (JTBD → экономика → RICE), стало укладываться в четыре-пять часов.

• Ошибок в юнит-экономике стало меньше примерно на 80%, потому что формулы и логика ^[8] расчета стали единообразными.

• Комплаенс-риски начали пропускать реже: FMEA-модуль превратился в обязательный чек-лист перед задачами, связанными с платежами и персональными данными.

Задача ИИ — не заменить продактов, а стать встроенным аналитиком/методологом/редактором, который всегда под рукой. Нам это дарит больше времени на самое ценное: поговорить с клиентом, разобраться в мотивации ^[9], проверить гипотезу, договориться со стейкхолдерами, принять решение.

Выводы

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

Еще очень важен контекст. У LLM он ограничен. Если диалог длинный, ассистент начинает «забывать» первые команды. Приходится постоянно подталкивать, напоминать, уточнять.

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

Что дальше?

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

Если сейчас мы сэкономили 50% времени на рутине, то с агентом хотим выиграть еще столько же. А освободившиеся часы пустить на полезные задачи: исследовать, находить инсайты и приносить бизнесу деньги. Потому что в конце концов ассистент — это инструмент, а ценность создает человек, который понимает, зачем все это вообще нужно.

А как у вас?

Расскажите, как вы автоматизируете рутину в продуктовых командах? Используете ли LLM для задач? Собираете ли своих ассистентов или пока присматриваетесь?

Расскажите в комментариях — давайте обсудим, какие подходы работают, а где ИИ пока не вытягивает.