Misha Ford – Промт-инжиниринг для разных профессий (страница 8)

Если в маркетинге нейросети чаще всего используют как генератор текстов и идей, то у продакт‑менеджеров картина немного другая. Вы, скорее всего, уже пробовали просить модель написать 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

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

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

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

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

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

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

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

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