Привет, меня зовут Настя. В Exante я прошла путь от Junior QA до Product Owner и иногда я пишу о том, как мы работаем над фичами. Сегодня хочу рассказать, как перестроила рутину и научилась быстрее и проще выполнять задачи с помощью AI-инструментов.

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

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

Спойлер №1. Это не обзор «Топ-10 AI-инструментов для продактов» и не набор готовых промптов. У каждого продакта свой стек, и то, что работает у меня, не обязательно подойдёт вам именно в текущем варианте. Но зато, возможно, даст пищу к размышлению, где и как вы можете эту логику применить в своих задачах.
Спойлер №2. AI не заменяет меня в моих задачах — он лишь забирает на себя рутину и помогает перераспределять время.

О том, как и какие именно задачи я ему делегировала, я и расскажу дальше.

Как я использую AI для discovery

Собираю основу для анализа конкурентов

Работа над любым новым продуктом начинается с анализа конкурентов. До AI это была неделя раскопок: сотни вкладок в браузере, скриншотов, PDF-файлов с туториалами, с десяток открытых платформ на разных устройствах, заметок с наблюдениями и страниц в Confluence с результирующими таблицами.

С AI все стало иначе. Я формулирую, что, у кого и как именно нужно сравнить — например, флоу регистрации, работу с несколькими счетами, механику расчётов или реализацию комплексной фичи. Конкретно это звучит примерно так: «сравни флоу регистрации ассет менеджера у конкурентов X, Y, Z: какие шаги проходит клиент, какие документы запрашиваются, есть ли видеоверификация, сколько занимает по времени, как привязываются клиентские счета. Верни таблицей: конкурент в строках, этапы в столбцах. Если данных в открытых источниках нет — помечай явно». И получаю структурированную матрицу по всем конкурентам за один проход.

Здесь критичны два момента:

Нельзя слепо верить тому, что выдал AI. Он с полной уверенностью может описать фичу, которой не существует, и для регулируемых продуктов это реальный риск. Поэтому я открываю каждый источник, который он упоминает, и проверяю данные.
Информация, которую он сгенерировал — это основа для работы, а не финальный результат. Я заношу структурированное сравнение конкурентов в мой документ в виде черновика. А потом вручную добавляю к нему комментарии, наблюдения, скриншоты и описания, которые сама нахожу в источниках.

AI сокращает путь от «мне нужен ресёрч по теме X» до «у меня есть весомые аргументы за или против предлагаемого решения» с недели до дня — с учётом ручного исследования и верификации.

Выясняю потребности пользователей

Интервью с клиентами — это часть фундамента, на котором строится discovery и дальнейшее принятие решений. И одновременно — это часы записей, которые потом нужно превратить во что-то человекочитаемое. Раньше превращение съедало почти столько же времени, сколько само интервью: надо было пересмотреть запись, выделить главное, конвертировать в задачи и приоритизировать с точки зрения боли пользователя.

Сейчас процесс выглядит так. Запись встречи я сначала отдаю в сервис транскрибации — на выходе получаю текстовую расшифровку. Затем закидываю её в AI вместе со своим промптом-шаблоном, в котором явно указано, что нужно выделить из текста:

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

На выходе получаю не «саммари», а сводную таблицу с этими колонками: каждая строка — отдельный инсайт из интервью. Дальше я уже преобразую её в action items и оборачиваю в таски в Jira.

Что здесь важно:

Шаблон позволяет одинаково обрабатывать данные. Каждое интервью AI превращает в таблицу по одинаковой логике. Впоследствии эти таблицы можно обрабатывать вместе, чтобы получить выводы для приоритизации бэклога. Когда у меня накапливается 10–15 интервью, я загружаю их сводные таблицы в AI и прошу провести анализ верхнего уровня. Запросы у меня типовые и обычно идут последовательно:
- Частотность проблем. «По всем этим таблицам выдели проблемы, которые упоминаются чаще всего; покажи количество упоминаний и из каких интервью они пришли.» Это даёт первый срез — что болит у многих.
- Кластеризация похожих болей. «Сгруппируй похожие по смыслу проблемы в кластеры, даже если они сформулированы разными словами.» Одна и та же проблема в десяти интервью может быть описана десятью разными формулировками — без этого шага частотный анализ занижает реальную картину.
- Сегментирование. «Разложи проблемы по сегментам пользователей — какие характерны для какой группы.» Это помогает понять, кому именно болит, и принять решение о приоритете не «в среднем», а с привязкой к конкретному сегменту.

На выходе получаю взвешенный список тем, к которому я уже добавляю собственное суждение о бизнес-приоритете и стоимости реализации.

Цитаты нужно сверять с оригиналом. AI умеет «слегка» перефразировать — для пересказа идей клиента для отчёта это нормально, но цитаты должны быть дословными.
Action items — это список того, с чем теперь нужно что-то сделать. План действий я собираю сама, глядя на все интервью вместе.

AI сокращает время между точкой «Мы провели интервью» и точкой «Мы сделаем с этим Х через У спринтов». Раньше между ними проходили дни, а сейчас — часы.

Уточняю причины поведения пользователей

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

Цифры сами по себе не говорили, что с ними делать. Сначала мне казалось, что 29% использования у одной из опций — это мало, и она кандидат на удаление; глубоко спрятанная настройка, которой пользовались редко, тоже выглядела как edge case, на который жалко тратить ресурс.

Затем я отдала ту же таблицу AI с промптом — «вот мои выводы по этим данным. Поспорь со мной: какие альтернативные интерпретации возможны, что я могла упустить?». И получила контраргументы, которые поменяли картину. AI подсказал, что 29% — это может быть не мало, а наоборот много для фичи, рассчитанной на профессиональных трейдеров. А редкое использование глубоко спрятанной настройки не обязательно значит, что она не важна, — туда просто не доходят, и прежде чем убирать, имеет смысл проверить гипотезу: перенести её на видное место и посмотреть на динамику.

Решение всё равно было за мной. Но я принимала его с учётом более масштабного набора аргументов.

Что здесь важно:

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

Так AI помогает взглянуть на ситуацию с другой стороны. Быть влюблённым в свой продукт и стремиться его развивать — это хорошая и полезная черта для продакта. Но если идея, которая кажется бриллиантовой, потенциально улучшит интерфейс только с точки зрения UI, но не увеличит чистую прибыль, AI поможет снять розовые очки.

Как я использую AI для сбора требований и дизайна

Превращаю абстрактную идею в прототип

В EXANTE фаза full discovery заканчивается набором артефактов — описание продукта, технические спецификации, мокапы и динамический прототип, который можно прокликать и понять логику как общего концепта, так и частных кейсов. Именно на динамических прото AI экономит мне больше всего времени.

Когда нужно сделать прототип сложного модуля, у которого уже есть устоявшиеся решения на рынке, мы проходим несколько этапов. Вот, как они выглядели раньше и какими стали с AI.

Формулируем требования. Раньше формализация требований проходила через несколько обсуждений с дизайнером. Я приходила с идеей в общих словах, мы вместе её прорабатывали — задавали друг другу уточняющие вопросы, рисовали на доске первые наброски, проговаривали, что вообще должно быть в фиче. На каждый цикл уходили дни, и только после нескольких итераций появлялись формализованные требования.

Теперь я описываю концепцию AI текстом. На вход подаю пять вещей: что за фича, какую проблему пользователя она решает, как похожие задачи решены у конкурентов (с конкретными ссылками или скриншотами), что в нашем случае точно должно быть и какие edge cases важны. Дальше прошу сформулировать функциональные требования, описать пользовательский флоу пошагово и выделить нестандартные сценарии. Через несколько минут получаю черновик, который остаётся проверить и поправить.

Создаём визуальный макет. Раньше дизайнер уходил отрисовывать макет в Figma на несколько дней — зато получался дизайнерский результат: выверенный по композиции, на компонентах системы. Сейчас я этот этап не заменяю, а сдвигаю первую отрисовку до дизайнера: передаю AI готовые требования и прошу собрать интерактивный HTML-прототип на простых компонентах — без pixel-perfect и фирменного визуала, но с рабочей логикой и реакцией на ввод. Через несколько минут получаю кликабельный черновик, на котором можно проверить, как поведение фичи ощущается в моменте.
Создаем дизайн в Figma. Раньше надо было вносить правки в макет от дизайнера. Сейчас все основные правки уже учтены в сгенерированном визуале и дизайнеру остается только пересобрать этот концепт в Figma на компонентах наших проектов.
Оформляем концепт в продуктовую документацию. Раньше надо было вручную написать её по тому, как это работает. Теперь AI пишет продуктовую документацию в Confluence.

Затем остаётся согласовать дизайн с руководством и обсудить его реализацию с командой — в этой части работы AI не может и не должен ничего ускорять.

В результате дизайн можно сделать за несколько дней вместо одной-трёх недель.

А ещё преимущество прототипа от AI в том, что он динамический — в нём можно менять параметры. Например, на стартовом этапе delivery команда QA анализирует требования и спрашивает: «А график пересчитается, если мы вот здесь поменяем вот этот параметр?». QA пробует тут же, фиксирует ответ и идёт дальше.

Работаю с одной фичей для трёх интерфейсов

У нас кроссплатформенный продукт, поэтому обычно одна и та же фича появляется на десктопе, вебе и иногда где-то ещё — например, в личном кабинете или мобильном приложении. Раньше для этого надо было отдельно пройти три итерации со спецификацией, три согласования с дизайном и три разговора с разработкой. И получить почти неизбежные расхождения в поведении между интерфейсами, в силу того, что над каждой платформой работает отдельная команда - со своими процессами, релизными циклами, приоритетами.

С AI я делаю это почти самостоятельно. Я описываю базовую логику фичи один раз, а AI помогает мне развернуть её в три версии спецификации с учётом особенностей каждой платформы. Запрос к AI выглядит примерно так:

Опиши реализацию фичи [короткое описание фичи] на трёх платформах — десктоп, веб, мобильное приложение. Общая логика на всех платформах одинаковая: [user flow]. Для каждой платформы пропиши: какие элементы интерфейса используются, какие edge cases, какие особенности взаимодействия — горячие клавиши на десктопе, тач-жесты на мобилке, ограничения экрана и ширины блоков. Формат: три отдельные секции, по одной на платформу.

На выходе получаю три версии спецификации. Дальше я их проверяю по простому чек-листу: совпадает ли user flow между платформами, везде ли одинаковая терминология (названия кнопок, полей, статусов) и учтены ли реальные особенности — например, на десктопе появились шорткаты, а на мобилке UX перестроен под одну руку. Если что-то выпало или, наоборот, вылезло лишнее — итерирую запрос. Обычно достаточно одного-двух кругов.

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

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

Дизайнер и разработка всё равно включаются — прототип не отменяет ревью, но разговор начинается с более проработанной точки.

Перевожу документацию

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

Раньше я тратила час или больше, чтобы перевести документ через онлайн-переводчик. Он плохо справлялся с биржевой терминологией: «order» становился «заказом» вместо «ордера», «position» — должностью вместо торговой позиции. После машинного перевода документ приходилось перечитывать целиком, выискивая такие места. Сейчас перевод занимает 10-15 минут. AI создаёт достаточно качественный черновик перевода, я бегло его вычитываю, внимательно проверяю терминологию и её применение в конкретных местах — и документ готов.

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

Как я использую AI для планирования и delivery

«Распиши плюсы и минусы»

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

В таких случаях я снова использую AI, чтобы посмотреть, какие варианты он предложит, и выбрать одну или несколько подходящих идей. Я описываю существующую структуру и новые задачи, прописываю условия, которые необходимо учесть, и прошу предложить варианты организации с преимуществами и недостатками.

Например, недавно я разбирала ситуацию: компании нужно запустить несколько новых направлений одновременно, без дополнительного найма и без полной остановки текущих задач существующих команд. В запросе к AI я описала, какие команды есть, чем они заняты, какие у нас новые направления и в какие сроки нужно уложиться. На выходе получила три варианта организации — распределить новое между существующими командами, собрать временные feature-команды за счёт выгрузки людей из текущих, матричная модель с шерингом разработчиков — каждый с явными плюсами и минусами.

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

«Сделай черновик странички в Confluence»

Документация — это место, где каждый продакт себя тихо недолюбливает. AI помогает написать черновик. Я закидываю в него спецификацию, ссылки на дизайн или прототип, расшифровку интервью или любой другой артефакт, из которого мне надо создать документ, и прошу написать первую версию. Получаю структурированный драфт, который соответствует паттернам, принятым в EXANTE. После этого обычно переписываю 20-40% текста, зато больше не начинаю с нуля.

«Мой первый merge request»

Я участвую в delivery не только как PO, который согласовывает результат, но и как человек, который открывает merge request (да, самой неожиданно).

Работает это так: небольшие, более-менее изолированные задачи я делаю сама через Claude Code. Процесс таков:

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

После нескольких таких циклов в случае успеха пушу коммит и формирую merge request. При этом Claude добавляет в таску в JIRA описание того, что было сделано и что нужно проверить команде QA.

Дальше мой merge request проходит обычный код-ревью от разработчиков и вливается в стейдж билд, на котором уже проводит тестирование команда QA. Если на ревью или тестировании найдены баги, мой merge request уходит в переделку. И после всех фиксов цикл проверок повторяется.

В прод решенная задача уходит ровно по тому же пайплайну, что и любой другой merge request.

Я не делаю сложных архитектурных изменений, меняю только понятное и изолированное. Всё, что затрагивает ядро, протоколы взаимодействия и интеграции с внешними системами, по-прежнему остаётся работой инженеров. И, конечно, это не делает меня разработчиком. Зато теперь мелкие изменения не лежат в бэклоге команды неделями — я делаю их сама.

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

Где я сознательно не использую AI

Я не отдаю AI продуктовые решения. Приоритеты, сокращение скоупа, «запускаем или нет» — это моя зона ответственности.
Я не доверяю AI финальный фактчекинг. Регуляторные детали, характеристики инструментов, правила бирж — если AI утверждает, что у конкурента есть какая-то фича, я проверяю это до того, как информация попадёт в любой документ, за который я ответственна.
Я не использую AI вместо разговора с пользователем. AI помогает обрабатывать уже проведённые интервью, но не заменяет само общение. В живом разговоре можно идти за ниточкой — задать уточняющий вопрос, переспросить, считать паузу и эмоциональную реакцию. Этого не даст ни опросник, ни AI-форма. Плюс клиенту обычно проще делиться с живым человеком, чем с автоматизированным интерфейсом, — а это влияет на то, насколько он откроется в следующий раз.
AI-черновики не отменяют ревью от дизайнеров и разработчиков. Прототипы — это быстрые черновики, MR — это вход в общий пайплайн. Полированный результат и архитектурная чистота — это по-прежнему ремесло.

Ключевые принципы для продактов, которые только начинают использовать AI

Делюсь тем, что сработало у меня.

Используйте AI, чтобы создавать первые черновые версии и избегать страха чистого листа. Не воспринимайте то, что он выдаёт, за готовый окончательный результат.
Проверяйте факты. Всегда. Особенно в регулируемых и технических доменах, где одна ошибка в спецификации может стоить команде недель правок, а компании — репутации.
Создайте собственные шаблоны промптов для интервью, спецификаций и ресёрча. По хорошему промпту AI выдаёт в десять раз более полезный результат, чем по общему запросу. «Обработай это интервью» — это плохой промпт. «Вытащи из расшифровки болевые точки, прямые цитаты, упомянутые workarounds и сегмент пользователя, верни таблицей» — хороший. Разница в результате колоссальная.
Не стремитесь делегировать AI всю работу головой, оставляйте пространство для самостоятельного мышления. Если начать слишком полагаться на AI, вы начнёте хуже понимать собственный продукт — и почувствуете это в первый же раз, когда вам зададут сложный вопрос на мите.
Определите для себя, что вы хотите контролировать лично, а где можете положиться на AI. Например: цитаты из интервью сверяю с оригиналом всегда, факты о конкурентах верифицирую вручную, финальные приоритеты решаю сама. Всё остальное — структурирование, черновики, форматирование, переводы — может делать AI. Когда границы чёткие, любая ошибка имеет понятный адрес, и можно разобраться, что именно сломалось и как починить на будущее.
Относитесь к AI как к тиммейту, который может быть прав, а может ошибаться — давайте ему контекст, спорьте со слабыми или подозрительными ответами. Не принимайте первый вариант, который он выдал, за идею для финального решения.

Заключение

С появлением AI в моей работе путь от идеи до релиза фичи стал ощутимо короче. Фича, которая год назад проходила этот путь за полтора-два месяца, сегодня проходит его за три-четыре недели. Подготовительный слой работы, который раньше растягивал discovery и требования на недели, теперь умещается в дни.

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

AI перераспределил время между задачами. На чистые листы, первые черновики, расшифровки, переводы и пересказывание одного и того же в разных форматах стало уходить меньше времени. И больше времени начало оставаться для того, что действительно должно быть в зоне ответственности человека: подбор решений, поиск компромиссов и переговоры с живыми людьми. Без этой части у команды остаётся набор артефактов; с ней — продукт.

А ещё AI немного стёр границу между «продакт описывает» и «продакт делает». В отдельных случаях я теперь дохожу до production-кода — не вместо разработчиков, а рядом с ними. И эта перемена, пожалуй, самая интересная из всего, что со мной произошло за последний год.

* * *

P.S. Принесли ли AI-инструменты реальные изменения в вашу продакт-рутину? Куда вы осознанно решили их не пускать? Пишите — будет интересно почитать!

Как я использую AI в работе продакт-оунера в EXANTE: от ресёрча до релиза