Я — Артём, владелец продукта в Совкомбанке. Развиваю бренд-медиа банка, включая Совкомблоги и Халва Медиа. В нашей продуктовой команде, как и во многих других в финтехе, мы столкнулись с тем, что PM-ы тратят до 60% времени на рутину: документацию, согласования, уточнения, аналитику. А времени на работу с клиентом — катастрофически не хватает.

Проблема стала системной: рост портфеля продуктов опережал рост команды. Я решил собрать решение — ИИ-ассистента, который стал для нас полноценным продуктовым напарником. По сути, это один большой, но тщательно структурированный промпт, превращающий LLM в инструмент для реальной работы.

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

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

• Понимать контекст: продукт, аудиторию, бизнес-цель.
• Иметь набор готовых «модулей» — задач, которые можно вызывать по запросу.
• Адаптироваться под роль пользователя: PM, топ-менеджер или новичок.
• Учитывать банковские ограничения: комплаенс, AML, ФЗ-152, фрод.
• Выдавать не текст ради текста, а структурированные артефакты — таблицы, чек-листы, шаблоны.

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

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

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

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

Ассистент не отвечает «с потолка». Перед генерацией он требует контекст: что за продукт, кто клиент, какая цель, какие ограничения.

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

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

Я выделил 16 частых продуктовых задач. Каждый модуль — это «промпт внутри промпта»: с входными данными, форматом ответа, чек-листами и типовыми ошибками.

Примеры модулей:

• Определение ценности — формулирует 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. Принцип «одного окна» и связанные задачи

После ответа ассистент не закрывается. Он предлагает 2–3 следующих шага и уточняет: результат подходит или нужно дорабатывать?

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

• построить дерево метрик;
• приоритизировать гипотезы (RICE/ICE);
• упаковать всё в PRD.

Это создаёт ощущение непрерывного процесса, а не разрозненных запросов.

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

Просто дать команде промпт — бесполезно. Нужно внедрять постепенно. Мы прошли три этапа.

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

Я взял топ-10 болезненных задач, проверил, как ассистент с ними справляется, и доработал промпт. Главное открытие: проблема не в модели, а в дисциплине.

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

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

Провёл воркшопы. Главный посыл: ассистент — не замена, а «вторая пара глаз». Он помогает структурировать, не забыть важное, ускорить путь к решению.

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

Через месяц замерили эффект:

• Подготовка документов (PRD, GTM, риск-анализ) — минус 50% времени.
• Скорость вывода гипотез в разработку — выросла вдвое. То, что занимало до трёх дней, теперь укладывается в 4–5 часов.
• Ошибок в юнит-экономике — на 80% меньше. Формулы и логика стали едиными.
• Комплаенс-риски — стали реже. FMEA-модуль стал обязательным чек-листом.

ИИ не заменяет продактов. Он становится встроенным аналитиком, методологом и редактором. А мы получаем больше времени на главное: диалог с клиентом, проверку гипотез, принятие решений.

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

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

Мы рассматриваем это как пилотный проект и продолжаем его развивать.

Что дальше?

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

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

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

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

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

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

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

1. Как я проектировал ИИ-ассистента
2. Какие продуктовые фреймворки заложил в основу
3. Почему это реально помогло команде
4. Над чем работаем: какие новые инструменты освободят еще больше времени

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

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

1. Понимает контекст (какой продукт, аудитория, бизнес-цель).
2. Имеет набор «модулей» (задач), которые можно вызывать по запросу.
3. Подстраивается под роль пользователя (PM, C-level, новичок).
4. Помнит, что мы в банке и соблюдает все требования.
5. Выдает не «текст ради текста», а заготовки, таблицы, структуру, которую можно реально взять и донести до команды.

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

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

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

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

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

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

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

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

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

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

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

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

• Определение ценности — формулирует 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%, потому что формулы и логика расчета стали единообразными.
• Комплаенс-риски начали пропускать реже: FMEA-модуль превратился в обязательный чек-лист перед задачами, связанными с платежами и персональными данными.

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

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

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

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

Что дальше?

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

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

А как у вас?

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

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