Промпты для продакт-менеджера. 25 готовых примеров для генерации

Продакт-менеджер сегодня – это человек, которому нужно одновременно думать за аналитика, маркетолога, разработчика и стратега. Промпты для продакт-менеджера позволяют делегировать нейросети рутинные и сложные задачи: от формулировки гипотез до анализа конкурентов и подготовки роадмапа. В этой статье – 25 готовых примеров, которые можно взять и использовать прямо сейчас.

Здесь собраны запросы для реальных рабочих ситуаций, а не абстрактные шаблоны “напиши мне что-нибудь про продукт”. Каждый промпт решает конкретную задачу, объясняет механику и предупреждает об ошибках.

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

• нужно быстро сформулировать ценностное предложение для новой функции
• предстоит защита приоритетов перед командой или руководством
• требуется провести анализ конкурентов без недели ручной работы
• пользовательские интервью нужно обработать и структурировать
• гипотезы для A/B-тестов нужно сформулировать четко и быстро
• роадмап завис на стадии “все важно, ничего не решено”

Каждый из 25 промптов ниже прошел проверку на конкретность: есть задача, есть механика, есть результат. Никакой воды – только то, что работает.

25 промптов для продакт-менеджера: готовые запросы для нейросети

1. Формулировка ценностного предложения продукта

Проблема:
Ценностное предложение формулируется размыто: “удобный сервис для бизнеса”. Такая фраза не отвечает на вопрос, почему именно этот продукт, и не работает ни в презентации, ни в маркетинге.

Решение:
Промпт заставляет нейросеть построить четкое ценностное предложение через связку “клиент – проблема – выгода – отличие”.

Текст промпта:

*****

Ты – [укажите роль, например, “опытный продакт-менеджер с опытом запуска B2B-продуктов”] с экспертизой в формулировке ценностных предложений.

Твоя задача – создать четкое ценностное предложение для продукта на основе данных, которые я предоставлю.

Контекст: [опишите продукт и его основную функцию, например, “платформа для автоматизации кадрового документооборота в малом бизнесе”]. Целевая аудитория: [опишите сегмент, например, “HR-специалисты компаний от 20 до 200 сотрудников”]. Главная боль клиента: [укажите проблему, например, “тратят до 3 часов в день на ручное оформление документов”].

Сформируй ценностное предложение в трех форматах:

1. Одно предложение (до 15 слов) – для заголовка лендинга.
2. Абзац (3–4 предложения) – для презентации инвесторам или команде.
3. Буллет-лист из 3 выгод – для карточки продукта или коммерческого предложения.

Ограничения: избегай общих слов (“удобный”, “эффективный”, “современный”), используй конкретные глаголы и измеримые результаты там, где это возможно. Тон – деловой, без маркетинговых штампов.

*****

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

2. Приоритизация задач по методу RICE

Проблема:
Бэклог разрастается, все задачи кажутся важными, а команда ждет четкого ответа: что делаем в следующем спринте.

Решение:
Промпт помогает применить фреймворк RICE к конкретному списку задач и получить аргументированный рейтинг приоритетов.

Текст промпта:

*****

Ты – [укажите роль, например, “опытный продакт-менеджер, специализирующийся на приоритизации продуктового бэклога”].

Твоя задача – оценить список задач по методу RICE (охват, влияние, уверенность, трудозатраты) и расставить их по приоритету.

Контекст: продукт – [опишите продукт, например, “мобильное приложение для учета личных финансов”]. Горизонт планирования – [укажите период, например, “квартал”]. Список задач: [перечислите задачи, например, “1. Добавить экспорт в Excel. 2. Переработать экран онбординга. 3. Интегрировать push-уведомления. 4. Добавить темную тему”].

Для каждой задачи:
– Оцени параметры RICE по шкале, которую сам объяснишь.
– Вычисли итоговый балл.
– Дай короткое обоснование (1–2 предложения), почему задача получила именно такой приоритет.

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

*****

Почему это работает:
Требование объяснить допущения защищает от ситуации, когда нейросеть уверенно выдает цифры из воздуха – это один из главных рисков при работе с аналитическими запросами.

3. Анализ конкурентов по продуктовым характеристикам

Проблема:
Конкурентный анализ либо занимает несколько дней ручной работы, либо сводится к поверхностному “у них тоже есть мобильное приложение”.

Решение:
Промпт структурирует анализ по конкретным продуктовым осям и позволяет получить сравнительную картину за минуты.

Текст промпта:

*****

Ты – [укажите роль, например, “аналитик продуктовой стратегии с опытом в SaaS-сегменте”].

Твоя задача – провести структурированный анализ конкурентов по ключевым продуктовым характеристикам.

Контекст: наш продукт – [опишите продукт и его ключевую функцию, например, “сервис для управления задачами в распределенных командах”]. Конкуренты для анализа: [перечислите, например, “Яндекс.Трекер, Битрикс24, Kaiten”]. Целевой сегмент: [укажите, например, “команды от 10 до 50 человек в IT-компаниях”].

Проанализируй каждого конкурента по следующим осям:

1. Ключевые функции и их реализация.
2. Модель ценообразования.
3. Очевидные слабые места или жалобы пользователей (на основе открытых отзывов и известных тебе данных).
4. Позиционирование: на кого они целятся.

Оформи результат в виде сравнительной таблицы. После таблицы – короткий вывод (3–5 предложений): какие незакрытые потребности сегмента просматриваются на основе анализа. Ограничение: опирайся только на факты, которые тебе известны; если данных нет – явно укажи это.

*****

Почему это работает:
Ось “слабые места и жалобы пользователей” – это то, что большинство пропускает при конкурентном анализе, хотя именно здесь прячутся лучшие идеи для дифференциации.

4. Составление плана пользовательского интервью

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

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

Текст промпта:

*****

Ты – [укажите роль, например, “UX-исследователь с опытом проведения глубинных интервью в продуктовых командах”].

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

Контекст: продукт – [опишите продукт, например, “приложение для записи к врачу в частных клиниках”]. Исследовательская задача: [сформулируйте, что нужно понять, например, “почему пользователи бросают процесс записи на этапе выбора времени”]. Тип респондентов: [опишите, например, “пользователи, которые начали запись, но не завершили ее за последние 30 дней”].

Составь гайд по структуре:

1. Разогрев (2–3 вопроса для установления контакта).
2. Исследование контекста и поведения (5–7 вопросов о том, как человек действовал в реальной ситуации).
3. Углубление в проблему (3–4 вопроса, раскрывающих причины и эмоции).
4. Проверка гипотез (2–3 вопроса, если есть конкретные предположения – укажите их: [опишите гипотезы, если есть]).
5. Завершение (1–2 вопроса для финального инсайта).

Ограничения: избегай наводящих вопросов и вопросов с вариантами ответа “да/нет”. Каждый вопрос должен побуждать к рассказу о реальном опыте. Тон – нейтральный, без оценок.

*****

Почему это работает:
Разделение на этапы разогрева и углубления воспроизводит реальную методологию глубинного интервью, а запрет на вопросы “да/нет” устраняет главную ошибку начинающих исследователей.

5. Формулировка гипотез для A/B-теста

Проблема:
Гипотезы для тестирования формулируются как “давайте поменяем цвет кнопки и посмотрим” – без связи с поведенческой моделью и без критерия успеха.

Решение:
Промпт помогает сформулировать гипотезы по структуре “если – то – потому что” с измеримыми метриками успеха.

Текст промпта:

*****

Ты – [укажите роль, например, “продакт-менеджер с опытом проведения продуктовых экспериментов в мобильных приложениях”].

Твоя задача – сформулировать корректные гипотезы для A/B-тестирования на основе описанной проблемы.

Контекст: продукт – [опишите продукт, например, “онлайн-сервис для подачи налоговой отчетности для ИП”]. Наблюдаемая проблема: [опишите, например, “40% пользователей не завершают заполнение формы на третьем шаге”]. Известные данные: [укажите, что уже известно, например, “тепловые карты показывают, что пользователи часто скроллят назад на шаге 3, а время на этом шаге в 2 раза больше, чем на предыдущих”].

Для каждой гипотезы используй структуру:
– Если мы [изменение], то [ожидаемый результат], потому что [поведенческое обоснование].
– Метрика успеха: [что и как измеряем].
– Минимальный эффект, при котором тест считается успешным: [предложи значение].

Сформулируй 4–5 гипотез разного типа: изменение интерфейса, изменение текста, изменение структуры шага, изменение точки входа. Ограничение: каждая гипотеза должна быть проверяемой за разумный срок (не более 4 недель при типичном трафике).

*****

Почему это работает:
Требование поведенческого обоснования (“потому что”) отделяет осмысленные гипотезы от случайных изменений и делает результаты теста интерпретируемыми вне зависимости от исхода.

6. Написание описания пользовательской истории (User Story)

Проблема:
Пользовательские истории пишутся формально: “Как пользователь, я хочу кнопку” – без контекста, критериев приемки и связи с реальной потребностью.

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

Текст промпта:

*****

Ты – [укажите роль, например, “опытный продакт-менеджер, работающий в Agile-командах”].

Твоя задача – написать пользовательскую историю по стандарту “Как [роль], я хочу [действие], чтобы [цель]” с полным набором критериев приемки.

Контекст: продукт – [опишите продукт, например, “корпоративная система управления отпусками”]. Функция: [опишите, что нужно реализовать, например, “возможность согласовать заявку на отпуск через мобильное приложение”]. Пользователь: [опишите роль, например, “руководитель отдела, который получает уведомление о заявке и должен ее одобрить или отклонить”].

Оформи результат по структуре:

1. Пользовательская история (одно предложение по шаблону).
2. Контекст и предпосылки (2–3 предложения: почему эта история важна).
3. Критерии приемки (список: минимум 5 конкретных условий, при которых функция считается реализованной).
4. Граничные случаи (2–3 ситуации, которые нужно обработать отдельно).
5. Примечания для команды (что важно учесть при реализации).

Ограничение: критерии приемки должны быть проверяемыми – без слов “удобно”, “быстро”, “понятно” без конкретики.

*****

Почему это работает:
Раздел “граничные случаи” – это то, что обычно всплывает уже в процессе разработки и ломает сроки; вынесение их в историю заранее экономит несколько итераций правок.

7. Подготовка роадмапа на квартал

Проблема:
Роадмап либо слишком детальный (и устаревает через неделю), либо слишком общий (и не дает команде ориентиров). Найти баланс без внешней точки зрения сложно.

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

Текст промпта:

*****

Ты – [укажите роль, например, “старший продакт-менеджер с опытом планирования продуктовых роадмапов в стартапах”].

Твоя задача – помочь структурировать квартальный роадмап продукта на основе предоставленных данных.

Контекст: продукт – [опишите продукт, например, “B2B-платформа для управления складскими запасами”]. Стратегическая цель на квартал: [укажите, например, “снизить отток клиентов с 8% до 5% в месяц”]. Список инициатив в рассмотрении: [перечислите, например, “редизайн дашборда, интеграция с 1С, улучшение онбординга, добавление мобильного приложения, ускорение загрузки отчетов”]. Ограничения команды: [укажите, например, “2 разработчика фронта, 1 бэкенд, 1 дизайнер, без DevOps на аутсорсе”].

Предложи структуру роадмапа:

1. Ключевые темы (тематические блоки, а не отдельные задачи) с обоснованием их связи со стратегической целью.
2. Распределение по месяцам: что в фокусе каждого месяца.
3. Что намеренно исключено и почему.
4. Риски, которые могут сдвинуть план.

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

*****

Почему это работает:
Раздел “что намеренно исключено и почему” – это самая сильная часть любого роадмапа: он переводит разговор от “почему вы не делаете X” к “мы осознанно не делаем X, потому что…”.

8. Обработка результатов пользовательских интервью

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

Решение:
Промпт структурирует сырые данные интервью в продуктовые выводы с выделением паттернов и рекомендаций.

Текст промпта:

*****

Ты – [укажите роль, например, “продуктовый аналитик с опытом качественных исследований пользователей”].

Твоя задача – проанализировать сырые данные пользовательских интервью и выделить ключевые инсайты для продуктовых решений.

Контекст: продукт – [опишите продукт, например, “приложение для онлайн-обучения иностранным языкам”]. Количество интервью: [укажите, например, “8 интервью, 45–60 минут каждое”]. Исследовательский вопрос: [укажите, например, “почему пользователи перестают заниматься после первых двух недель”].

Ниже – сырые заметки из интервью: [вставьте текст заметок].

Проведи анализ по структуре:

1. Повторяющиеся паттерны (что упоминали 3 и более респондента – с указанием частоты).
2. Единичные, но сильные инсайты (что прозвучало редко, но важно).
3. Противоречия в ответах разных пользователей.
4. Гипотезы для проверки (3–5 штук, вытекающих из данных).
5. Рекомендуемые продуктовые шаги (3–4 конкретных действия).

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

*****

Почему это работает:
Требование отдельно выделить противоречия в ответах защищает от ловушки подтверждения: когда из 8 интервью замечают только те ответы, которые подтверждают уже сложившуюся точку зрения.

9. Составление метрик успеха для нового функционала

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

Решение:
Промпт помогает определить систему метрик для оценки новой функции до ее запуска, а не после.

Текст промпта:

*****

Ты – [укажите роль, например, “продакт-менеджер с опытом выстраивания продуктовой аналитики”].

Твоя задача – разработать систему метрик для оценки успешности нового функционала.

Контекст: продукт – [опишите продукт, например, “платформа для онлайн-записи к специалистам в сфере красоты”]. Новый функционал: [опишите, например, “система напоминаний о предстоящей записи через мессенджер”]. Бизнес-цель функционала: [укажите, например, “снизить процент неявок клиентов”].

Предложи систему метрик по уровням:

1. Метрика уровня бизнеса (как функция влияет на ключевые бизнес-показатели).
2. Метрика уровня продукта (как пользователи взаимодействуют с функцией).
3. Метрика качества (насколько функция работает технически и воспринимается пользователями).
4. Контрметрики (что не должно ухудшиться после запуска).

Для каждой метрики укажи:
– Формулу или способ измерения.
– Базовое значение (если известно, иначе – как его получить).
– Целевое значение через 30 и 90 дней.

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

*****

Почему это работает:
Контрметрики – это страховка от ситуации, когда новая функция улучшает один показатель и незаметно ломает другой; их отсутствие в системе измерений – одна из самых дорогостоящих ошибок в продуктовой работе.

10. Подготовка презентации для стейкхолдеров

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

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

Текст промпта:

*****

Ты – [укажите роль, например, “опытный продакт-менеджер, регулярно защищающий продуктовые решения перед советом директоров”].

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

Контекст: тема презентации – [опишите, например, “запрос на увеличение бюджета на разработку мобильного приложения на 2 миллиона рублей в следующем квартале”]. Аудитория: [опишите, например, “генеральный директор и финансовый директор, ориентированы на возврат инвестиций, скептически относятся к IT-инициативам”]. Что нужно получить на выходе: [укажите, например, “одобрение бюджета и назначение ответственного за проект”].

Разработай структуру презентации (8–12 слайдов):
– Для каждого слайда: название, ключевой тезис (1 предложение), что должно быть показано (данные, схема, цитата).
– Укажи, на каком слайде должен прозвучать главный запрос к аудитории.

Дополнительно: предложи 3–4 возражения, которые вероятно возникнут у этой аудитории, и тезисы для ответа на каждое.

Ограничение: структура должна вести к решению, а не просто информировать. Каждый слайд должен отвечать на вопрос “почему это важно для бизнеса”.

*****

Почему это работает:
Блок с возражениями аудитории превращает подготовку к презентации из монолога в диалог – и именно это отличает презентации, которые получают одобрение, от тех, которые уходят “на доработку”.

11. Написание технического задания для разработчиков

Проблема:
Техническое задание написано так, что разработчики задают 20 уточняющих вопросов, а потом все равно делают не то, что имелось в виду.

Решение:
Промпт генерирует структурированное техническое задание с описанием логики поведения, граничных случаев и критериев готовности.

Текст промпта:

*****

Ты – [укажите роль, например, “продакт-менеджер с опытом постановки задач для команды разработки в продуктовых компаниях”].

Твоя задача – написать техническое задание для реализации конкретной функции продукта.

Контекст: функция – [опишите, например, “система фильтрации товаров в каталоге интернет-магазина по нескольким параметрам одновременно”]. Платформа: [укажите, например, “веб-версия, адаптивная под мобильные устройства”]. Целевой пользователь: [опишите, например, “покупатель, ищущий конкретный товар по характеристикам”].

Структура технического задания:

1. Цель и контекст (почему эта функция нужна, какую проблему решает).
2. Описание поведения (шаг за шагом: что происходит при каждом действии пользователя).
3. Граничные случаи (минимум 5 ситуаций, которые должны быть обработаны).
4. Что остается за рамками (что специально НЕ входит в эту задачу).
5. Критерии готовности (список: когда задача считается выполненной).
6. Открытые вопросы (что нужно уточнить перед началом разработки).

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

*****

Почему это работает:
Раздел “что остается за рамками” – это один из самых ценных элементов технического задания: он явно закрывает пространство для интерпретаций и предотвращает “а я думал, что это тоже входит”.

12. Разработка стратегии выхода на новый сегмент

Проблема:
Решение “давайте попробуем новый сегмент” принимается без анализа того, что именно нужно изменить в продукте, позиционировании и процессах продаж.

Решение:
Промпт помогает структурировать стратегию выхода на новый сегмент с анализом gap между текущим состоянием и требованиями нового рынка.

Текст промпта:

*****

Ты – [укажите роль, например, “продакт-стратег с опытом вывода B2B-продуктов на смежные рыночные сегменты”].

Твоя задача – разработать стратегию выхода существующего продукта на новый целевой сегмент.

Контекст: текущий продукт – [опишите, например, “система автоматизации бухгалтерской отчетности, которую используют компании с оборотом до 100 миллионов рублей в год”]. Текущий сегмент: [опишите, например, “малый бизнес, 1–10 сотрудников”]. Целевой новый сегмент: [опишите, например, “средний бизнес, 50–200 сотрудников, производственные компании”].

Проведи анализ по структуре:

1. Ключевые отличия нового сегмента от текущего (потребности, процессы, критерии выбора).
2. Разрыв между текущим продуктом и требованиями нового сегмента (что не подходит сейчас).
3. Минимальные изменения продукта для первых продаж в новом сегменте.
4. Риски и барьеры входа.
5. Критерии, по которым через 6 месяцев можно оценить, стоит ли продолжать.

Ограничение: стратегия должна предполагать, что ресурсы ограничены – не планируй с нуля новый продукт, ищи путь наименьших изменений для проверки гипотезы.

*****

Почему это работает:
Ограничение “путь наименьших изменений” принципиально меняет логику ответа: вместо идеальной стратегии на бумаге появляется реалистичный план для проверки гипотезы с минимальными затратами.

13. Формулировка концепции MVP

Проблема:
MVP превращается в “минимальный продукт с максимальным количеством функций, потому что иначе неудобно” – и запуск откладывается на полгода.

Решение:
Промпт помогает сформулировать концепцию MVP с четкой границей минимальности и логикой, зачем именно эти функции.

Текст промпта:

*****

Ты – [укажите роль, например, “продакт-менеджер с опытом запуска стартапов и проверки продуктовых гипотез через MVP”].

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

Контекст: идея продукта – [опишите, например, “маркетплейс для поиска репетиторов по школьным предметам с возможностью онлайн-занятий”]. Ключевая гипотеза для проверки: [укажите, например, “родители готовы платить за услугу подбора репетитора с гарантией результата”]. Целевая аудитория первой версии: [опишите, например, “родители учеников 5–9 классов в Москве”]. Доступные ресурсы: [укажите, например, “1 разработчик, 1 дизайнер, бюджет 500 тысяч рублей, срок – 2 месяца”].

Разработай концепцию MVP:

1. Что входит в MVP и почему (каждая функция должна быть обоснована связью с гипотезой).
2. Что намеренно исключено и почему это не критично для проверки гипотезы.
3. Как будет измеряться успех MVP (конкретные метрики и пороговые значения).
4. Что будет означать провал MVP и что делать в этом случае.

Ограничение: MVP должен быть реализован в указанные сроки и бюджет. Если что-то не укладывается – предложи, что убрать, а не как увеличить ресурсы.

*****

Почему это работает:
Требование обосновать каждую функцию через связь с гипотезой – это жесткий фильтр, который убирает “хотелки” и оставляет только то, что реально нужно для проверки предположения.

14. Анализ оттока пользователей

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

Решение:
Промпт помогает структурировать анализ оттока через поведенческие данные и сформулировать проверяемые гипотезы причин.

Текст промпта:

*****

Ты – [укажите роль, например, “продуктовый аналитик с опытом работы с retention-метриками в подписочных сервисах”].

Твоя задача – провести структурированный анализ оттока пользователей на основе предоставленных данных.

Контекст: продукт – [опишите продукт, например, “сервис онлайн-бухгалтерии по подписке для ИП”]. Текущий показатель оттока: [укажите, например, “12% в месяц”]. Доступные данные: [опишите, что есть, например, “данные о действиях пользователей в продукте за 90 дней, результаты опроса при отписке (ответили 23%), данные по когортам”]. Данные для анализа: [вставьте данные или их описание].

Проведи анализ по структуре:

1. Когда уходят (на каком этапе жизненного цикла отток максимальный).
2. Кто уходит (если данные позволяют – сегменты с наибольшим оттоком).
3. Что делали перед уходом (поведенческие паттерны уходящих пользователей).
4. Что говорят при уходе (анализ ответов опроса).
5. Гипотезы причин (ранжированные по вероятности и потенциальному влиянию).
6. Рекомендуемые следующие шаги (что проверить и как).

Ограничение: четко разделяй факты (что показывают данные) и интерпретации (почему это происходит). Интерпретации маркируй явно.

*****

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

15. Подготовка к переговорам с партнером или поставщиком

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

Решение:
Промпт помогает подготовить переговорную позицию с анализом интересов сторон и сценариями развития диалога.

Текст промпта:

*****

Ты – [укажите роль, например, “опытный переговорщик в сфере B2B-партнерств и продуктовых интеграций”].

Твоя задача – помочь подготовиться к переговорам с партнером или поставщиком.

Контекст: цель переговоров – [опишите, например, “договориться об интеграции нашего сервиса в экосистему партнера с условием эксклюзивности на 12 месяцев”]. Наша позиция: [опишите, например, “нам нужен доступ к базе из 50 000 пользователей партнера, взамен предлагаем процент от выручки”]. Что известно о партнере: [опишите, например, “партнер – крупная логистическая компания, сейчас ищет способы монетизации своего приложения”]. Наши ограничения: [укажите, например, “максимальная доля выручки, которую готовы отдать – 15%, эксклюзивность не дольше 12 месяцев”].

Подготовь:

1. Анализ интересов партнера (что им реально важно в этих переговорах).
2. Наша идеальная позиция и минимально приемлемая позиция по каждому ключевому пункту.
3. Возможные уступки с нашей стороны и что просить взамен.
4. Вероятные возражения партнера и ответы на них.
5. Альтернатива, если договориться не удастся (наш план Б).

Ограничение: не предлагай уступки за рамками указанных ограничений. Тон – деловой, стратегический.

*****

Почему это работает:
Явное разделение “идеальная позиция / минимально приемлемая позиция” – это основа любых переговоров; без этого разграничения легко согласиться на условия, которые на деле невыгодны, просто потому что давление в моменте сильнее, чем заранее продуманная логика.

16. Создание системы онбординга для новых пользователей

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

Решение:
Промпт помогает спроектировать онбординг как путь к первому успеху пользователя, а не как экскурсию по кнопкам.

Текст промпта:

*****

Ты – [укажите роль, например, “продакт-менеджер с экспертизой в проектировании пользовательского онбординга”].

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

Контекст: продукт – [опишите продукт, например, “сервис для управления проектами в небольших строительных компаниях”]. Ключевая ценность продукта: [укажите, например, “прораб видит статус всех задач в реальном времени без созвонов”]. Типичный новый пользователь: [опишите, например, “прораб, 35–50 лет, привык к WhatsApp и Excel, скептически относится к новым инструментам”]. Текущая проблема: [опишите, например, “60% новых пользователей не возвращаются после первого дня”].

Разработай концепцию онбординга:

1. Определи “момент первого успеха” – конкретное действие, после которого пользователь понимает ценность продукта.
2. Спроектируй путь к первому успеху (шаги, не более 5–7).
3. Для каждого шага: что пользователь делает, что он видит, что он чувствует.
4. Какие барьеры могут возникнуть на каждом шаге и как их снизить.
5. Как измерить эффективность онбординга.

Ограничение: онбординг должен быть завершен за первые 10–15 минут работы с продуктом. Не проектируй “тур по интерфейсу” – только действия, ведущие к ценности.

*****

Почему это работает:
Концепция “момента первого успеха” переключает логику с “показать пользователю все” на “довести пользователя до одного конкретного результата” – и именно этот сдвиг объясняет разницу между онбордингом, который работает, и тем, который просто есть.

17. Анализ продуктовых метрик и выработка выводов

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

Решение:
Промпт помогает интерпретировать набор метрик и выработать конкретные продуктовые выводы и следующие шаги.

Текст промпта:

*****

Ты – [укажите роль, например, “старший продуктовый аналитик с опытом интерпретации данных в потребительских приложениях”].

Твоя задача – проанализировать набор продуктовых метрик и сформулировать конкретные выводы и рекомендации.

Контекст: продукт – [опишите продукт, например, “мобильное приложение для медитации и управления стрессом”]. Период анализа: [укажите, например, “последние 30 дней”]. Данные: [вставьте метрики, например, “DAU упал с 12 000 до 9 500; retention на 7-й день – 18%; средняя сессия – 4,2 минуты; конверсия в платную подписку – 2,3%; NPS – 34; топ-3 функции по использованию: дыхательные упражнения, медитации для сна, дневник настроения”].

Проведи анализ:

1. Что эти данные говорят о состоянии продукта (общая картина).
2. Тревожные сигналы (что требует немедленного внимания и почему).
3. Позитивные сигналы (что работает хорошо и что из этого можно усилить).
4. Связи между метриками (как одно влияет на другое).
5. Топ-3 приоритетных действия на следующие 30 дней с обоснованием.

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

*****

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

18. Написание сообщения о релизе для пользователей

Проблема:
Сообщения о релизах пишутся языком разработчиков: “исправлены баги”, “улучшена производительность” – пользователь не понимает, что изменилось и зачем ему это важно.

Решение:
Промпт помогает написать сообщение о релизе на языке пользователя: через выгоды, а не технические изменения.

Текст промпта:

*****

Ты – [укажите роль, например, “продакт-менеджер, отвечающий за коммуникацию с пользователями продукта”].

Твоя задача – написать сообщение о релизе для пользователей продукта, которое объясняет изменения через пользу, а не через технические детали.

Контекст: продукт – [опишите продукт, например, “приложение для учета рабочего времени фрилансеров”]. Аудитория: [опишите, например, “фрилансеры в сфере дизайна и разработки, возраст 25–40 лет, ценят простоту и экономию времени”]. Что изменилось в релизе: [опишите технически, например, “добавлен экспорт отчетов в PDF, исправлена ошибка синхронизации с Google Календарем, переработан экран статистики”]. Канал публикации: [укажите, например, “push-уведомление + письмо в рассылке”].

Напиши два варианта:

1. Короткий (для push-уведомления, до 100 символов): фокус на главном изменении.
2. Развернутый (для письма, 150–200 слов): все изменения через выгоды пользователя, с призывом к действию.

Ограничение: не используй технический жаргон. Каждое изменение описывай через ответ на вопрос “что это дает пользователю”. Тон – дружелюбный, без пафоса.

*****

Почему это работает:
Ограничение “каждое изменение через ответ на вопрос что это дает пользователю” – это принудительная смена угла зрения с внутреннего (что мы сделали) на внешний (что изменилось для пользователя), и именно этот переход делает коммуникацию о релизах работающей.

19. Разработка стратегии монетизации

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

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

Текст промпта:

*****

Ты – [укажите роль, например, “продуктовый стратег с опытом разработки моделей монетизации для цифровых продуктов”].

Твоя задача – разработать и обосновать стратегию монетизации для продукта.

Контекст: продукт – [опишите продукт, например, “веб-сервис для создания коммерческих предложений и смет для строительных подрядчиков”]. Текущая ситуация: [опишите, например, “продукт бесплатный, 3 000 активных пользователей в месяц, средняя сессия 25 минут, 70% пользователей возвращаются каждую неделю”]. Что пользователи ценят больше всего: [опишите, например, “скорость создания сметы и профессиональный вид документа”]. Целевой доход: [укажите, например, “1 миллион рублей в месяц через 12 месяцев”].

Проанализируй и предложи:

1. Топ-3 модели монетизации, подходящие для этого продукта и аудитории, с обоснованием.
2. Рекомендуемую модель с детальным описанием: что входит в бесплатный уровень, что платно, ценовые точки.
3. Ожидаемые риски при переходе на монетизацию (отток, негативная реакция).
4. Как минимизировать риски при запуске платной версии.
5. Метрики для оценки успеха монетизации через 3 и 6 месяцев.

Ограничение: модель должна учитывать, что резкий переход с “полностью бесплатно” на “полностью платно” скорее всего убьет аудиторию.

*****

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

20. Составление плана запуска продукта (go-to-market)

Проблема:
Продукт готов, а план выхода на рынок не готов – или существует в виде одного слайда “расскажем всем и они придут”.

Решение:
Промпт помогает разработать операционный план запуска с конкретными каналами, сроками и критериями успеха.

Текст промпта:

*****

Ты – [укажите роль, например, “продакт-менеджер с опытом запуска цифровых продуктов на российском рынке”].

Твоя задача – разработать операционный план выхода продукта на рынок.

Контекст: продукт – [опишите продукт, например, “сервис для автоматического мониторинга упоминаний бренда в социальных сетях и на новостных ресурсах”]. Целевая аудитория: [опишите, например, “PR-менеджеры и маркетологи компаний с оборотом от 500 миллионов рублей”]. Дата запуска: [укажите, например, “через 6 недель”]. Бюджет на маркетинг: [укажите, например, “300 тысяч рублей”]. Команда: [опишите, например, “1 маркетолог, 1 продакт, возможность привлечь внешних подрядчиков”].

Разработай план запуска:

1. Цели запуска (конкретные метрики на первые 30 и 90 дней).
2. Каналы привлечения первых клиентов с обоснованием выбора.
3. Ключевые активности по неделям на первые 6 недель.
4. Распределение бюджета по каналам.
5. Что будет означать успешный запуск, что – провал.
6. Сценарий “что делаем, если через 30 дней нет продаж”.

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

*****

Почему это работает:
Сценарий “что делаем, если через 30 дней нет продаж” – это встроенный антикризисный план, который большинство команд не готовит заранее и который оказывается нужен гораздо чаще, чем хотелось бы.

21. Описание персон пользователей (User Persona)

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

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

Текст промпта:

*****

Ты – [укажите роль, например, “UX-исследователь с опытом создания продуктовых персон на основе качественных и количественных данных”].

Твоя задача – создать описание персон пользователей, которые будут полезны при принятии продуктовых решений.

Контекст: продукт – [опишите продукт, например, “платформа для дистанционного обучения сотрудников корпораций”]. Данные для создания персон: [опишите источники, например, “результаты 12 интервью, данные аналитики о поведении пользователей, данные опросов”]. Ключевые вопросы, которые персоны должны помогать решать: [укажите, например, “как расставлять приоритеты функций, какой тон коммуникации выбирать, как проектировать онбординг”].

Создай 2–3 персоны. Для каждой:

1. Имя и краткое описание (профессия, контекст жизни – 2–3 предложения).
2. Цели (что хочет достичь с помощью продукта).
3. Барьеры (что мешает или пугает).
4. Поведенческие паттерны (как использует продукт, когда, в каком контексте).
5. Цитата (характерная фраза, которую мог бы сказать этот человек).
6. Что для него важно при выборе инструмента.

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

*****

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

22. Формулировка стратегии работы с обратной связью пользователей

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

Решение:
Промпт помогает выстроить систему работы с обратной связью, которая превращает поток запросов в структурированные продуктовые инсайты.

Текст промпта:

*****

Ты – [укажите роль, например, “продакт-менеджер с опытом выстраивания процессов работы с пользовательской обратной связью”].

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

Контекст: продукт – [опишите продукт, например, “сервис электронного документооборота для малого бизнеса”]. Текущая ситуация: [опишите, например, “обратная связь приходит через Telegram-чат поддержки, отзывы в магазинах приложений и письма на почту; ни один из каналов не обрабатывается системно”]. Размер команды: [укажите, например, “1 продакт, 1 менеджер поддержки, 4 разработчика”]. Цель: [укажите, например, “сделать так, чтобы обратная связь реально влияла на приоритеты бэклога”].

Разработай систему:

1. Каналы сбора обратной связи (какие оставить, какие добавить, как структурировать).
2. Процесс обработки: как часто, кто отвечает, как классифицировать.
3. Критерии перевода обратной связи в задачи бэклога.
4. Как отвечать пользователям, чтобы они чувствовали, что их слышат.
5. Метрики эффективности системы.

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

*****

Почему это работает:
Ограничение “без дополнительного найма” убирает идеальные, но нереализуемые системы и заставляет думать в рамках реальных возможностей – именно так устроена продуктовая работа большинства команд.

23. Подготовка к ретроспективе продуктовой команды

Проблема:
Ретроспективы превращаются в ритуал: “все хорошо, надо лучше коммуницировать” – и ничего не меняется до следующей ретроспективы.

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

Текст промпта:

*****

Ты – [укажите роль, например, “фасилитатор продуктовых команд с опытом проведения ретроспектив в Agile-проектах”].

Твоя задача – разработать структуру и вопросы для ретроспективы продуктовой команды, которая приведет к конкретным изменениям.

Контекст: команда – [опишите, например, “продуктовая команда из 7 человек: 1 продакт, 2 дизайнера, 4 разработчика”]. Период: [укажите, например, “последние 6 недель, два спринта”]. Известные проблемы периода: [опишите, например, “задержка релиза на 2 недели, конфликт по приоритетам между дизайном и разработкой, высокая нагрузка на всю команду”]. Цель ретроспективы: [укажите, например, “выявить системные причины задержки и договориться о конкретных изменениях в процессе”].

Разработай:

1. Формат ретроспективы (длительность, структура, инструменты).
2. Вопросы для каждого блока (не более 3 вопросов на блок, все – открытые).
3. Методику выявления системных причин (не симптомов, а причин).
4. Как зафиксировать договоренности так, чтобы они выполнялись.
5. Как проверить на следующей ретроспективе, что изменения произошли.

Ограничение: ретроспектива должна уложиться в 90 минут. Никаких упражнений ради упражнений – только то, что ведет к конкретным решениям.

*****

Почему это работает:
Требование отдельно работать с системными причинами, а не симптомами – это то, что отличает ретроспективу, после которой что-то меняется, от той, после которой команда расходится с чувством выполненного долга и полным сохранением статус-кво.

24. Создание документа о видении продукта (Product Vision)

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

Решение:
Промпт помогает сформулировать документ о видении продукта, который дает команде ориентир и помогает отвечать на вопрос “зачем мы это делаем”.

Текст промпта:

*****

Ты – [укажите роль, например, “опытный продакт-менеджер, специализирующийся на стратегическом позиционировании продуктов”].

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

Контекст: продукт – [опишите продукт, например, “платформа для управления репутацией малого бизнеса в интернете”]. Основатели и их мотивация: [опишите, например, “бывшие владельцы ресторана, которые потеряли бизнес из-за волны негативных отзывов, которую не смогли вовремя заметить”]. Целевая аудитория: [опишите, например, “владельцы малого бизнеса в сфере услуг”]. Горизонт видения: [укажите, например, “3–5 лет”].

Создай документ о видении продукта:

1. Проблема, которую мы решаем (1 абзац, максимально конкретно).
2. Для кого мы это делаем (кто наш идеальный пользователь через 3–5 лет).
3. Каким будет мир, когда наш продукт достигнет успеха (образ желаемого будущего).
4. Что отличает нас от всех других (принципиальное отличие, а не список функций).
5. Наши принципы – что мы никогда не сделаем ради роста.
6. Формулировка видения (1–2 предложения, которые можно повесить на стену).

Ограничение: документ должен помогать команде принимать решения в ситуации неопределенности. Если видение не помогает ответить “стоит ли нам делать X” – оно слишком абстрактное.

*****

Почему это работает:
Раздел “что мы никогда не сделаем ради роста” – это один из самых честных тестов на реальность видения: именно через ограничения, а не через амбиции, проявляется настоящий характер продукта.

25. Подготовка к защите продуктового решения перед командой

Проблема:
Продуктовое решение принимается в одиночку, а потом команда узнает о нем на встрече – и начинается сопротивление, вопросы и скрытый саботаж реализации.

Решение:
Промпт помогает подготовить аргументированную защиту продуктового решения, которая учитывает интересы всех участников команды.

Текст промпта:

*****

Ты – [укажите роль, например, “продакт-менеджер с опытом выстраивания доверия внутри кросс-функциональных команд”].

Твоя задача – помочь подготовить убедительную защиту продуктового решения для командной встречи.

Контекст: решение – [опишите, например, “отказаться от разработки десктопной версии продукта и сосредоточиться только на мобильном приложении”]. Данные, на которых основано решение: [опишите, например, “87% активных пользователей заходят только с мобильных устройств, поддержка десктопной версии занимает 30% ресурсов разработки”]. Состав команды: [опишите, например, “2 разработчика, 1 дизайнер, 1 менеджер поддержки, 1 менеджер по продажам”]. Ожидаемое сопротивление: [опишите, например, “менеджер по продажам говорит, что корпоративные клиенты требуют десктоп; разработчики привязаны к технологическому стеку десктопа”].

Подготовь материал для встречи:

1. Ключевой аргумент (1 предложение, суть решения и почему оно правильное).
2. Доказательная база (как данные поддерживают решение – 3–5 тезисов).
3. Что теряем и как с этим работаем (честное признание издержек решения).
4. Возражения каждого участника команды и ответы на них.
5. Что команда выигрывает от этого решения (в чем интерес каждого участника).
6. Как будет принято окончательное решение на встрече (процедура).

Ограничение: защита не должна быть манипулятивной – только честные аргументы. Команда должна понять логику, а не просто согласиться.

*****

Почему это работает:
Требование “что теряем и как с этим работаем” – это принципиальный момент: честное признание издержек решения вызывает больше доверия, чем попытка представить его идеальным, и именно это доверие определяет, будет ли команда реализовывать решение с полной отдачей или формально.

Типичные ошибки при работе с запросами для нейросети в продуктовой работе

1. Отправлять запрос без контекста продукта и аудитории. Нейросеть не знает, что за продукт, кто пользователи и в чем специфика – и генерирует универсальный ответ, который не подходит ни для одной конкретной ситуации.
2. Задавать несколько несвязанных задач в одном запросе. Когда в одном сообщении просят “проанализировать конкурентов, придумать 10 функций и написать письмо пользователям”, нейросеть пытается охватить все и не делает ничего хорошо – каждая из этих задач заслуживает отдельного, продуманного запроса.
3. Не указывать формат ответа и его объем. Без этого нейросеть выбирает формат сама – и часто выдает либо огромный список там, где нужен абзац, либо один абзац там, где нужна таблица с деталями.
4. Принимать первый ответ как финальный без итерации. Первый ответ нейросети – это заготовка, а не готовое решение; уточняющий запрос с конкретной правкой (“сделай более кратко”, “добавь пример для B2B”, “перепиши второй пункт”) дает результат принципиально другого качества.
5. Не указывать ограничения и то, чего делать не нужно. Если не сказать “не предлагай функции, требующие редизайна всего интерфейса” или “не используй западные примеры” – нейросеть будет предлагать именно это, потому что именно это статистически наиболее распространено в ее обучающих данных.
6. Использовать нейросеть для принятия стратегических решений без проверки данными. Нейросеть хорошо структурирует мышление и генерирует варианты, но не имеет доступа к реальным данным продукта – принятие решений на основе ее ответов без верификации реальными метриками – это дорогостоящая ошибка.
7. Не адаптировать промпты под специфику своего продукта. Готовые шаблоны промптов – это отправная точка, а не конечный инструмент. Продукт в сфере медицины требует совсем других акцентов, чем продукт в сфере логистики, и универсальный запрос это не учитывает.
8. Игнорировать раздел “почему это работает” при использовании готовых промптов. Понимание механики промпта позволяет адаптировать его под новую задачу; без этого понимания при первом же отклонении от шаблонной ситуации инструмент перестает работать.
9. Не сохранять удачные запросы и их результаты. Хороший промпт, который дал отличный результат, воспроизводим – но только если он сохранен; большинство специалистов каждый раз начинают с нуля и теряют время на то, что уже было решено.

Сравнение слабых и сильных запросов для продакт-менеджера

Задача	Слабый запрос	Сильный запрос (ключевые элементы)	Почему важна разница
Приоритизация бэклога	“Помоги расставить приоритеты в задачах”	Роль + метод RICE + список задач + горизонт планирования + ограничения команды + формат таблицы	Без метода и контекста нейросеть угадывает приоритеты по своим критериям, которые не совпадают с реальными целями
Анализ оттока	“Почему уходят пользователи?”	Роль + данные о поведении + текущий показатель оттока + запрос на разделение фактов и интерпретаций + конкретные следующие шаги	Без данных нейросеть генерирует типичные причины оттока, а не причины для конкретного продукта
Конкурентный анализ	“Расскажи про конкурентов сервиса X”	Роль + конкретные конкуренты + оси анализа + целевой сегмент + запрос на незакрытые потребности + явное указание на ограничения данных	Без осей анализа получается пересказ сайтов конкурентов, а не продуктовый инсайт
Ценностное предложение	“Напиши ценностное предложение для нашего продукта”	Роль + описание продукта + боль клиента + целевая аудитория + три формата + запрет общих слов	Без запрета на общие слова почти гарантированно получается “удобный и эффективный сервис”
Метрики успеха	“Какие метрики отслеживать для новой функции?”	Роль + описание функции + бизнес-цель + четыре уровня метрик + контрметрики + указание на технические ограничения	Без контрметрик система измерения не защищает от ситуации, когда одна метрика растет за счет другой
Пользовательские истории	“Напиши user story для функции уведомлений”	Роль + описание пользователя + контекст функции + структура с критериями приемки + граничные случаи + запрет на неизмеримые критерии	Без критериев приемки история считается выполненной в момент появления кнопки, а не в момент решения задачи пользователя
Онбординг	“Придумай онбординг для нашего приложения”	Роль + ключевая ценность продукта + портрет пользователя + текущая проблема + концепция первого успеха + ограничение на длительность	Без концепции первого успеха онбординг проектируется как экскурсия, а не как путь к ценности

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

1. Давайте нейросети роль, которая создает нужное напряжение. Если нужна критика идеи – просите роль “скептически настроенного инвестора”, а не “эксперта по продукту”: разные роли создают разные углы зрения и принципиально разные ответы на один и тот же вопрос.
2. Разбивайте сложные задачи на цепочку последовательных запросов. Вместо одного запроса “проанализируй данные и предложи стратегию” – сначала “структурируй данные и выдели паттерны”, потом “на основе этих паттернов сформулируй гипотезы”, потом “предложи стратегию проверки гипотез”: каждый шаг опирается на результат предыдущего и качество растет кратно.
3. Используйте нейросеть для проверки собственных решений через “адвоката дьявола”. После того как решение принято, отправьте его нейросети с запросом “найди все слабые места и контраргументы” – это дешевле, чем обнаружить слабые места после запуска.
4. Указывайте, какие данные у вас есть, а какие – нет. Фраза “у нас нет данных по конверсии” в контексте запроса заставляет нейросеть работать в реальных ограничениях, а не предполагать, что все данные доступны – и ответ становится применимым, а не идеальным.
5. Просите нейросеть перечислить сделанные допущения в конце ответа. Любой аналитический ответ содержит скрытые допущения; когда они явно перечислены, сразу видно, где реальность расходится с моделью и какие данные нужно проверить.
6. Сохраняйте контекст продукта в отдельном документе и вставляйте его в начало каждой новой сессии. Нейросеть не помнит предыдущие разговоры – и если каждый раз заново объяснять, что за продукт и кто пользователи, теряется время и качество: готовый блок “контекст продукта” в 5–7 предложений решает эту проблему.
7. Просите нейросеть задать уточняющие вопросы перед ответом на сложный запрос. Добавление фразы “прежде чем отвечать, задай 3 уточняющих вопроса, которые помогут дать более точный ответ” выявляет пробелы в постановке задачи и экономит итерации – особенно для стратегических и аналитических запросов, где контекст критически важен.