C.R.E.A.T.E.
Путь от идеи к проверяемому продукту.

Используйте для превращения сырой идеи в ясный продуктовый контекст.

Ты — продуктовый стратег. Помоги собрать базовый контекст нового продукта.

Сырая идея: [ОПИШИТЕ ИДЕЮ]
Кому помогаем: [АУДИТОРИЯ]
Что уже известно: [ФАКТЫ, ИНТЕРВЬЮ, ОГРАНИЧЕНИЯ]
Что пока является гипотезой: [ГИПОТЕЗЫ]

Сделай:
1. Vision — одно короткое утверждение об идеальном будущем, которое стремится создать продукт.
2. Mission — одно конкретное утверждение: какую фундаментальную проблему, для кого и через какую трансформацию решает продукт.
3. Emotional Problem — опиши не функциональную задачу, а состояние пользователя до решения проблемы.
4. Desired Transformation — как должно измениться состояние, поведение или способность пользователя после взаимодействия с продуктом.
5. Список из 5 допущений, которые необходимо проверить, прежде чем считать этот контекст верным.

Не придумывай факты. Явно помечай, где ответ основан на моих входных данных, а где это гипотеза.

Ценности становятся правилами для интерфейса, контента и AI-функций — не декларацией на странице «о нас».

Ты — продуктовый дизайнер, работающий с AI-функциями.

Vision: [ВСТАВЬТЕ]
Mission: [ВСТАВЬТЕ]
Emotional Problem: [ВСТАВЬТЕ]
Контекст аудитории и рисков: [ВСТАВЬТЕ]

Предложи 3–5 Core Values продукта. Для каждой ценности дай:
- краткое название;
- что она означает для пользователя;
- правило для продукта или команды;
- как это правило ограничивает поведение AI;
- пример плохого решения, которое эта ценность не допускает.

В конце составь короткий «контракт AI с пользователем» из 5 проверяемых правил. Не используй общие слова вроде «инновационность» или «качество» без операционного смысла.

Сначала создаёт карту того, что именно надо найти, а не подменяет исследование правдоподобным текстом.

Ты — product researcher. Составь проверяемый план исследования для продукта.

Контекст продукта: [VISION, MISSION, CORE VALUES]
Аудитория: [АУДИТОРИЯ]
Проблема: [ЭМОЦИОНАЛЬНАЯ И ФУНКЦИОНАЛЬНАЯ ПРОБЛЕМА]
Известные альтернативы: [СПИСОК]
География / рынок: [РЫНОК]

Сделай таблицу:
1. Вопрос исследования.
2. Почему он важен для решения.
3. Где искать первичные данные.
4. Какой сигнал будет подтверждать или опровергать гипотезу.
5. Риск ложного вывода.

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

Не утверждай, что нашёл факты, если их нет во входных данных.

Подходит после того, как у вас есть расшифровки интервью, ответы опросов или отзывы.

Ты — UX-исследователь. Проанализируй сырые пользовательские данные.

Контекст продукта: [КРАТКО]
Данные: [ВСТАВЬТЕ ЦИТАТЫ ИЗ ИНТЕРВЬЮ / ОТЗЫВОВ / ОПРОСОВ]

Правила:
- не превращай единичную цитату в статистический факт;
- отделяй явное высказывание пользователя от своей интерпретации;
- сохраняй дословные формулировки, которые полезны для языка продукта.

Сделай:
1. 5–7 повторяющихся паттернов с цитатами-основаниями.
2. Сегменты по ситуации и мотивации, а не по демографии, если демография не влияет на задачу.
3. CJM: триггер → поиск альтернатив → выбор → первое действие → результат → причины отказа.
4. Список неудовлетворённых задач и противоречий.
5. Вопросы, которые нельзя решить этими данными и нужно дополнительно проверить.

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

Ты — product manager. На основе исследований помоги сформулировать JTBD и гипотезы.

Проблема: [ВСТАВЬТЕ]
Паттерны из исследований: [ВСТАВЬТЕ]
Цитаты пользователей: [ВСТАВЬТЕ]
Ограничения продукта: [ВСТАВЬТЕ]

Сделай:
1. 3–5 JTBD в формате: «Когда [ситуация], я хочу [мотивация / действие], чтобы [ожидаемый прогресс]».
2. Для каждой JTBD: текущие альтернативы, барьеры, эмоциональные и функциональные критерии успеха.
3. По 2–3 гипотезы решения на каждую JTBD.
4. Для каждой гипотезы: кого затрагивает, какое изменение предполагает, почему оно может сработать, метрика, минимальный способ проверки, главный риск.
5. Приоритизацию через Impact / Confidence / Effort с пояснением всех субъективных оценок.

Не просит «сгенерировать приложение»: сначала выбирает одну критическую неопределённость и способ её проверить.

Ты — product designer и product manager. Помоги выбрать минимальный тест, который уменьшит ключевую неопределённость.

Выбранная JTBD: [ВСТАВЬТЕ]
Гипотеза: [ВСТАВЬТЕ]
Аудитория: [ВСТАВЬТЕ]
Что уже известно: [ВСТАВЬТЕ]
Ограничения: [СРОК, БЮДЖЕТ, ДАННЫЕ, КОМАНДА]

Сделай:
1. Сформулируй главное неизвестное, которое нужно проверить.
2. Предложи 3 формата теста: ручной / кликабельный прототип / минимальная работающая функция.
3. Для каждого: что именно узнаем, стоимость, риск ложноположительного результата.
4. Выбери один тест и опиши сценарий пользователя от входа до результата.
5. Определи событие активации, качественный сигнал успеха и стоп-критерий.
6. Составь краткий scope MVP: включить сейчас / отложить / сознательно не делать.

Помогает разделить нужное для теста и всё, что кажется полезным, но не отвечает на вопрос гипотезы.

Ты — delivery manager. Составь план сборки MVP.

Цель теста: [ВСТАВЬТЕ]
Сценарий пользователя: [ВСТАВЬТЕ]
Scope MVP: [ВСТАВЬТЕ]
Ограничения: [ВСТАВЬТЕ]
Команда и инструменты: [ВСТАВЬТЕ]

Сделай таблицу задач с колонками:
- пользовательский результат;
- задача;
- приоритет: must / should / later;
- зависимость;
- риск;
- критерий готовности;
- кто проверяет;
- где AI может ускорить работу и где его нельзя использовать без проверки.

После таблицы укажи:
1. самый короткий критический путь;
2. три задачи, которые чаще всего ошибочно включают в MVP;
3. список решений, которые нужно принять до начала разработки.

Особенно важен для AI-функций: «пользователь получил ответ» не равно «продукт сработал».

Ты — product analyst. Составь измеримую схему качества для MVP с AI-функцией.

Ключевой сценарий: [ВСТАВЬТЕ]
AI делает: [ВСТАВЬТЕ]
Пользователь получает: [ВСТАВЬТЕ]
Риски ошибки: [ВСТАВЬТЕ]

Сделай:
1. Северную звезду и 3–5 продуктовых метрик с точными определениями.
2. Событийную схему: событие, свойства, зачем измеряем.
3. Метрики качества AI: полнота, точность, релевантность, безопасность — только применимые к сценарию.
4. Где обязателен human-in-the-loop и почему.
5. Сценарии отказа: что делать, когда модель не уверена, ответ небезопасен или данные отсутствуют.
6. Минимальный QA-чек-лист перед первым запуском.

Нужен для первичной диагностики, не для окончательного решения о причине.

Ты — product analyst. Разбери данные воронки и помоги сформировать проверяемые объяснения.

Цель продукта: [ВСТАВЬТЕ]
Определения этапов воронки: [ВСТАВЬТЕ]
Данные по периодам и сегментам: [ВСТАВЬТЕ]
Изменения в продукте за период: [ВСТАВЬТЕ]
Качественная обратная связь: [ВСТАВЬТЕ]

Сделай:
1. Укажи, где именно находится узкое место, не подменяя его причиной.
2. Раздели наблюдения на факты, возможные объяснения и недостающие данные.
3. Предложи 5 гипотез причин, ранжируя по правдоподобию и потенциальному влиянию.
4. Для каждой гипотезы: какой дополнительный сигнал поможет её проверить.
5. Назови риски неверной интерпретации: сезонность, изменение трафика, малый размер выборки, технические ошибки и другие релевантные факторы.
6. Предложи один следующий шаг с наименьшей стоимостью проверки.

Применяйте после того, как выбрали одну объясняющую гипотезу, а не просто «идею улучшения».

Ты — product manager. Спроектируй безопасный эксперимент.

Проблема: [ВСТАВЬТЕ]
Гипотеза причины: [ВСТАВЬТЕ]
Предлагаемое изменение: [ВСТАВЬТЕ]
Сегмент: [ВСТАВЬТЕ]
Базовая метрика: [ВСТАВЬТЕ]
Ограничения и риски: [ВСТАВЬТЕ]

Сделай карточку эксперимента:
- гипотеза в формате «если / то / потому что»;
- какой пользовательский механизм меняем;
- primary metric и guardrail metrics;
- минимальный размер / период наблюдения, если данные позволяют оценить;
- критерий успеха, критерий остановки и что будет считаться неинформативным результатом;
- риски для пользователей и план отката;
- что узнаем при каждом из трёх исходов: улучшение / без изменений / ухудшение.

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

Ты — growth product manager. Помоги выбрать гипотезы развития продукта.

Подтверждённая ценность: [ВСТАВЬТЕ]
Сегменты и их поведение: [ВСТАВЬТЕ]
Данные по активации / удержанию / выручке: [ВСТАВЬТЕ]
Текущие каналы привлечения: [ВСТАВЬТЕ]
Ограничения: [ВСТАВЬТЕ]

Сделай:
1. Раздели возможности на: ценность и удержание / дистрибуция / монетизация / операционная эффективность.
2. Предложи до 3 гипотез в каждой группе.
3. Для каждой укажи: механизм, сегмент, ведущую метрику, риск и первый дешёвый тест.
4. Отдельно назови, какие данные нельзя надёжно предсказать с помощью AI и нужно получить экспериментом.
5. Построй простой порядок проверки гипотез на 90 дней без выдуманных прогнозов роста.

AI помогает готовить анализ и варианты; решение, тест и выкладка остаются под управлением команды.

Ты — product operations lead. Спроектируй управляемый цикл непрерывных улучшений продукта с AI-инструментами.

Продукт: [ВСТАВЬТЕ]
Источники данных: [ВСТАВЬТЕ]
Кто в команде принимает решения: [ВСТАВЬТЕ]
Какие AI-инструменты уже доступны: [ВСТАВЬТЕ]
Риски: [ДАННЫЕ, БЕЗОПАСНОСТЬ, РЕПУТАЦИЯ, РЕГУЛЯТОРНЫЕ]

Сделай рабочий цикл:
1. Какие сигналы собираем еженедельно / ежемесячно.
2. Что AI может делать: кластеризовать обратную связь, находить аномалии, готовить черновики гипотез, суммировать исследования.
3. Что AI не должен делать без человека: [ДОПОЛНИТЬ ПРИМЕНИМОЕ].
4. Кто подтверждает качество входных данных, гипотезы, эксперимент и выкладку.
5. Как журналировать решения, версии промптов и результаты экспериментов.
6. Какие пороги требуют остановить автоматизацию и провести ручную проверку.