Читать книгу Промт-инжиниринг для разных профессий - - Страница 3

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

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

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

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

Проблема: почему «напиши user story» – это слишком мало.

Многие продакты используют нейросеть так: «Вот идея фичи, напиши user story и acceptance criteria».

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

Проблема здесь в том, что:

вы даёте модели уже «решение», а не проблему

вы не делитесь с ней реальным контекстом продукта

вы не описываете пользователей и метрики

вы не объясняете, какие ограничения есть у команды и бизнеса

То есть вы просите помощника «красиво оформить» фичу, но не просите его помочь вам подумать, нужна ли эта фича, кого она затронет, какие метрики должна сдвинуть и насколько она приоритетна.

В результате нейросеть превращается в «текстовый принтер», а не в партнёра для размышлений.

Промт‑инжиниринг в продакт‑работе – это умение давать модели:

контекст продукта и пользователей

проблему, а не только решение

бизнес‑цели и метрики

ограничения и чётко формулировать, что вы хотите получить:

анализ, гипотезы, формализованные требования, приоритизацию, черновик презентации.

Давайте начнём с теоретических принципов: как объяснять модели ваш продукт, фичи, пользователей и метрики.

Теоретические принципы: как описывать фичи, пользователей и метрики.

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

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

Как описывать пользователей

Если вы просто пишете «наши пользователи – это владельцы интернет‑магазинов» или «обычные пользователи мобильного приложения», модель видит только очень общий портрет.

Сформулируйте немного подробнее:

кто они по роли: владельцы бизнеса, маркетологи, операционисты, разработчики, конечные пользователи

на каком этапе они приходят к вашему продукту

какую задачу они хотят закрыть

какие у них ограничения по времени, ресурсам, знаниям

Например:

«Наш пользователь – владелец малого интернет‑магазина (от 10 до 100 заказов в день), который сам занимается и ассортиментом, и рекламой, и частично операционкой. Он не силён в аналитике и технических деталях, боится сложных интерфейсов, но хочет быстро понимать, что происходит с продажами и рекламой».

Такая формулировка сразу даёт модели понимание, какой уровень интерфейса, терминов и сценариев уместен.

Как описывать фичу

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

Например:

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

Если вы так описываете фичу в промте, модель может вам помочь:

уточнить проблемное место

предложить варианты интерфейса

сформулировать user stories

подсказать критерии готовности

Как описывать метрики

Без метрик модель тоже будет фантазировать.

Чётко укажите:

какой тип продукта (SaaS, маркетплейс, мобильное приложение, онлайн‑курс и т.д.)

какие ключевые метрики для вас сейчас в фокусе (активация, удержание, конверсия в оплату, LTV, MAU, DAU и т.п.)

что вы хотите сдвинуть именно этой фичей или инициативой.

Например:

«У нас B2B SaaS для управления задачами. Основная метрика, на которой мы сейчас сфокусированы, – активные команды через 30 дней после регистрации (пользователи, у которых создано 5+ задач и есть хотя бы один приглашённый коллега). Эта фича должна помочь нам увеличить активацию и в итоге улучшить удержание».

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

Ограничения по конфиденциальности данных

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

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

В промтах мы будем:

обезличивать данные, заменяя реальные имена, почты, ID

описывать типовые паттерны, а не конкретные записи указывать модели, что она не должна запрашивать персональные данные и не должна использовать их в ответах.

Например, вы можете прямо писать:

«Все данные ниже обезличены. Не запрашивайте и не используйте реальные имена, контакты, персональные данные пользователей».

Теперь перейдём к кросс‑доменным шаблонам, адаптированным под работу продакта.

Кросс‑доменные шаблоны: продакт‑версия

Мы возьмём три базовых сценария:

анализ требований

генерация продуктовых гипотез

приоритизация

Вы можете воспринимать их как «скелеты» промтов, в которые будете подставлять свои данные.

ШАБЛОН АНАЛИЗА ТРЕБОВАНИЙ

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

Текстовый промт:

Вы – опытный product manager с практическим опытом не менее 10 лет.

Я опишу вам идею фичи и контекст.

Продукт: {{описание_продукта}}

Тип продукта (SaaS, мобильное приложение, маркетплейс и т.п.): {{тип_продукта}}

Пользователи: {{описание_пользователей}}

Общая идея фичи: {{идея_фичи}}

Бизнес‑цели, на которые фича должна повлиять: {{бизнес_цели}}

Продуктовые метрики, которые она должна сдвинуть: {{метрики}}

Ограничения (технические, ресурсные, юридические): {{ограничения}}

Ваша задача:

Помочь мне уточнить problem statement: в чём реальная проблема пользователя и бизнеса, которую мы решаем.

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

Предложить 3–5 вариантов формулировки user stories для этой фичи.

Предложить список возможных acceptance criteria, которые можно использовать как стартовую точку.

Ограничения по конфиденциальности:

Предполагайте, что все описания обезличены;

не запрашивайте конкретные персональные данные пользователей;

не давайте рекомендаций, нарушающих закон или внутренние политики компании.

Формат ответа:

Чёткий problem statement.

Уточнённое описание фичи.

Список user stories.

Список возможных acceptance criteria.

ШАБЛОН ГЕНЕРАЦИИ ПРОДУКТОВЫХ ГИПОТЕЗ

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

Текстовый промт:

Вы – опытный product manager и аналитик.

Продукт: {{описание_продукта}}

Тип продукта: {{тип_продукта}}

Основные пользовательские сегменты: {{сегменты_пользователей}}

Текущая ситуация и проблема: {{описание_ситуации}}

Ключевые метрики, которые нас волнуют: {{метрики}}

Ваша задача – помочь мне сформулировать продуктовые гипотезы.

Пожалуйста:

Предложите 5–10 гипотез по улучшению продукта (фичи, изменения в онбординге, интерфейсе, уведомлениях, тарифах и т.п.).

Для каждой гипотезы укажите:

какой сегмент пользователей она затрагивает;

в чём сущность изменения;

на какую метрику она должна повлиять;

как можно проверить эту гипотезу (идея простого эксперимента или A/B‑теста).

Отметьте 3–5 гипотез, которые вы считаете наиболее перспективными, и кратко объясните, почему.

Ограничения:

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

не предлагайте решения, нарушающие законы или политику конфиденциальности.

ШАБЛОН ПРИОРИТИЗАЦИИ (RICE / MOSCOW)

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

Текстовый промт (для RICE):

Вы – опытный product manager, умеющий применять методику RICE для приоритизации.

Я дам вам список инициатив/фич.

Контекст продукта: {{описание_продукта}}

Цели на ближайший квартал: {{цели}}

Список инициатив с кратким описанием: {{список_инициатив}}

Ваша задача:

Для каждой инициативы предложить примерные оценки по RICE: Reach, Impact, Confidence, Effort (словесно и приблизительно по шкале, если это возможно).

Рассчитать примерный RICE‑score на основе этих оценок (даже если оценки приблизительные).

Отсортировать инициативы по приоритету и кратко прокомментировать логику.

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

Ограничения:

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

Точно так же вы можете сделать промт под MoSCoW:

Классифицируйте инициативы на Must / Should / Could / Won’t для текущего периода с пояснением причин.

ПРИМЕРЫ ЗАДАЧ И ПРОМТОВ

Теперь давайте посмотрим на конкретные сценарии продакт‑работы и промты под них.

Сформировать backlog из сырых идей

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

Вместо того чтобы мучительно их структурировать вручную, вы можете сделать так.

Вы – опытный product manager.

У меня есть набор сырых идей и заметок по развитию продукта. Они разного уровня и качества.

Продукт: {{описание_продукта}}

Тип продукта: {{тип_продукта}}

Основные пользовательские сегменты: {{сегменты}}

Текущие цели продукта на ближайшие 3–6 месяцев: {{цели}}

Ниже я дам вам список сырых идей в свободной форме.

{{сырые_идеи}}

Ваша задача:

Сгруппировать эти идеи по темам или направлениям.

Для каждой идеи постараться:

понять и переформулировать предполагаемую пользовательскую проблему;

предложить более чёткое описание возможной фичи или изменения;

указать, какой сегмент пользователей – это может затрагивать;

предположить, на какие метрики это может повлиять.

Сформировать предварительный структурированный backlog: список инициатив с кратким описанием и полем «что нужно уточнить/какие данные собрать».

Ограничения:

Не придумывайте несуществующие цели бизнеса;

если информации недостаточно, укажите это явно.

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

Описать фичу: от problem statement до acceptance criteria.

Теперь хотите одной фиче уделить внимание и оформить её по всем правилам.

Текстовый промт, который использует шаблон анализа требований:

Вы – опытный product manager.

Продукт: SaaS‑сервис для управления задачами в малых командах (до 20 человек).

Пользователи: основатель бизнеса, руководители отделов и сотрудники.

Общая идея фичи:

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

Бизнес‑цели:

снизить перегрузку ключевых сотрудников;

повысить прозрачность распределения задач.

Метрики:

доля задач, просроченных более чем на 3 дня;

удовлетворённость руководителей интерфейсом управления задачами (по опросам);

частота использования нового экрана визуализации.

Ограничения:

команда разработки ограничена по времени;

нельзя требовать от пользователей сложного ручного ввода данных;

интерфейс должен быть понятен не‑технарям.

Ваша задача:

Сформулировать чёткий problem statement для этой фичи.

Переформулировать идею фичи в одном абзаце понятным языком.

Предложить 3–5 user stories в формате «Как [роль] я хочу [цель], чтобы [результат]».

Предложить список возможных acceptance criteria для первого итерационного релиза.

Вы можете подставить сюда свой продукт, свою фичу и свои метрики.

Подготовить продуктовую презентацию