Де ШІ насправді вписується в тиждень продакта
Продакт-менеджмент, це чотири різні роботи в одному календарі. Ви багато читаєте (відгуки, тікети, транскрипти, вивантаження аналітики), багато пишете (специфікації, апдейти, брифи), трохи аналізуєте (воронки, когорти, результати опитувань) і постійно переконуєте. Кожна з цих задач вимагає іншої моделі, тому одна підписка на ШІ покриває приблизно дві третини роботи, а решта відчувається як боротьба.
| Завдання продакта | Найкраща модель | Чому |
|---|---|---|
| Наратив PRD, постановка проблеми, апдейти продукту | Claude | Утримує довгу аргументацію, пише текст, який інженер реально прочитає |
| Тематизація відгуків, кластеризація тікетів, структурований витяг | GPT | Надійна у строгих форматах виводу й послідовних мітках категорій |
| Дослідження ринку, огляд конкурентів, контекст ринку | Gemini | Найкраща на свіжому вебматеріалі, повертає джерела, які можна відкрити |
| Довгі транскрипти, дослідницькі презентації, звіти на 100 сторінок | Gemini | Контекстне вікно на 1 млн токенів, тож увесь корпус вміщується за один прохід |
| Критика специфікації й пошук крайових випадків | Будь-яка модель, яка не писала специфікацію | Незалежний читач помічає те, чого не бачить автор |
Ніщо з цього не замінює судження щодо того, що будувати. Це скорочує відстань між наявністю вхідних даних і готовим записаним результатом, а саме там більшість тижнів продакта втрачає час. Перемикання також дешеве: на Whizi Pro повідомлення в Claude Sonnet 5 коштує 10 кредитів із місячної квоти в 2 000 кредитів, витяг у GPT-5.6 Luna коштує 1, а Gemini 3.7 Flash читає транскрипти за 2 кредити за повідомлення.
Написання PRD, який інженер не поверне назад
Більшість специфікацій, написаних ШІ, провалюються на одному й тому ж: вони описують функцію, а не рішення. Розробці не потрібен абзац про те, чому клієнт важливий. Їй потрібні стани, крайові випадки і те, що станеться, якщо виклик завершиться помилкою. Запитуйте про це прямо, і результат змінює характер.
Промпт: спочатку постановка проблеми
Напиши розділ постановки проблеми для PRD. Мої докази: [вставити тікети підтримки, аналітику, цитати з інтерв'ю]. Не пропонуй рішення. Поверни: хто має цю проблему, як часто, що вони роблять зараз замість цього, у що це їм обходиться і що ми очікуємо змінити, якщо проблему вирішити. Познач будь-яке твердження, не підкріплене вставленими доказами, як ПРИПУЩЕННЯ.
Промпт: тіло специфікації
Перетвори це на специфікацію для команди розробки. Функція: [опис]. Стани користувача, які треба покрити: [список]. Поверни: користувацькі історії з критеріями прийняття, кожен стан, включно з порожнім, завантаженням, помилкою і відмовою через права доступу, поведінку при недоступності залежності, події аналітики з їхніми властивостями та відкриті питання. Не вигадуй вимог, які я не вказав. Перелічи все, що довелося припустити, в окремому розділі наприкінці.
Промпт: прохід критики
Виступи як старший інженер, який перевіряє цю специфікацію перед оцінкою. Перелічи лише проблеми: невизначену поведінку, відсутні стани, вимоги, що суперечать одна одній, приховану роботу з міграції та все, що спричинить додаткове питання під час уточнення. Не переписуй специфікацію.
Запускайте цей третій промпт у моделі, яка не писала специфікацію. Він стабільно виявляє три питання, які інакше підняла б ваша команда під час уточнення, а відповідь на них заздалегідь, це різниця між 20-хвилинною зустріччю з планування і 50-хвилинною.
Перетворення сирих відгуків на щось, що можна пріоритизувати
Найкорисніше завдання для ШІ в продакт-менеджменті, це не писати. Це прочитати 400 відгуків у формі, з якою можна діяти. Вручну це половина робочого дня. Добре зроблено з моделлю, це 20 хвилин, і якість залежить майже повністю від того, чи змушуєте ви систему тримати стабільні категорії.
Промпт: перший прохід тематизації
Ось сирі відгуки клієнтів. Розбий їх на теми. Для кожної теми поверни: мітку, кількість пунктів, серйозність, яку передбачає формулювання, репрезентативну цитату, скопійовану точно, і чи є ця тема багом, відсутньою можливістю, проблемою зручності використання чи невідповідністю очікуванням. Не об'єднуй теми з різними першопричинами, навіть якщо формулювання схожі. Не переказуй цитати своїми словами. Відгуки: [вставити].
Промпт: другий прохід за фіксованою таксономією
Перекласифікуй ті самі відгуки, використовуючи лише ці категорії: [вставити наявну таксономію]. Усе, що не підходить, іде в НЕКЛАСИФІКОВАНЕ з поясненням. Поверни таблицю категорії, кількості та відсотка.
Структура з двох проходів має значення. Перший прохід показує, що насправді є в даних. Другий робить результат порівнянним із минулим кварталом, і саме це робить його придатним для розмови про пріоритети, а не просто цікавим.
| Про що запитати | Що ви отримаєте | Для чого це годиться |
|---|---|---|
| Теми з кількостями | Ранжований список проблемних зон | Вхідні дані для дорожньої карти, квартальне планування |
| Лише дослівні цитати | Незмінена мова клієнтів | Копірайтинг, позиціонування, переконання керівництва |
| Розподіл серйозності й частоти | Матриця 2x2 болю проти обсягу | Рішення, що виправляти першим |
| Суперечності | Де сегменти хочуть протилежного | Раннє виявлення хибного консенсусу |
Останній рядок вартий постійного промпту: Де в цих відгуках різні користувачі хочуть несумісних речей? Назви сегменти й компроміс. Список тем згладжує розбіжності, а розбіжність зазвичай і є найкориснішою річчю в даних.
Дослідження, конкуренти й ринкові дослідження, на які ніколи не вистачає часу
Дослідження, це те, що ріжуть першим, коли реліз затримується, а саме тоді погане рішення обходиться найдорожче. Сканування за допомогою моделі не замінює розмов із клієнтами, але замінює виправдання того, що ви йдете в рішення наосліп.
Промпт: розбір конкурента
Побудуй розбір того, як [конкурент] вирішує [завдання користувача]. Охопи: їхнє заявлене позиціонування власними словами, потік, задокументований у їхньому центрі допомоги, ціни там, де вони публічні, що змінилося за останні 12 місяців із датами, і теми скарг, видимі в публічних відгуках. Підтверджуй кожне твердження посиланням. Розділяй те, що заявляє компанія, від того, що спостерігають треті сторони.
Промпт: синтез інтерв'ю
Прочитай ці транскрипти інтерв'ю. Поверни: завдання, які користувачі намагаються виконати, обхідні шляхи, які вони побудували, моменти, коли вони висловлювали розчарування, з точними цитатами, і будь-яке місце, де сказане користувачем суперечить описаній ним дії. Не узагальнюй поза межами транскриптів. Якщо патерн з'являється менш ніж у трьох інтерв'ю, познач його як окреме спостереження, а не патерн.
Це останнє обмеження продакти забувають найчастіше. Моделі охоче видають чисті патерни, а чистий патерн із двох інтерв'ю, це як дорожня карта закінчує тим, що обслуговує неіснуючого клієнта. Просіть кількості поряд із кожним твердженням.
Наратив для керівництва й комунікація запуску
Той самий контент має існувати на чотирьох рівнях: специфікація для розробки, апдейт для команди, абзац для огляду керівництвом і нотатка запуску для клієнтів. Перезапис між рівнями, це найбільш механічна робота в цій посаді і найлегша для делегування.
Промпт: зміна рівня
Перепиши це для [аудиторія]. Їх хвилюють [конкретні питання]. У них [рівень] контексту в цій сфері продукту. Зберігай кожне фактичне твердження ідентичним. Довжина: [обмеження]. Починай із рішення чи результату, а не з передісторії. Чернетка: [вставити].
Промпт: абзац для керівництва
Стисни цей апдейт до 120 слів для керівника, який прочитає це один раз. Структура: що змінилося, що це означає для метрики, за яку ми взяли зобов'язання, що нам потрібно від них, і єдиний ризик, вартий їхньої уваги. Жодних прикметників, які не виміряні.
Промпт: передпохоронний розбір
Уяви, що цей запуск провалився через шість місяців. Напиши три найбільш правдоподібні пояснення, впорядковані за ймовірністю, використовуючи лише те, що є в плані нижче. Для кожного вкажи ранній сигнал, який ми могли б відстежувати. План: [вставити].
Тримайте всі чотири рівні в одному потоці Whizi. Нотатка запуску успадковує контекст зі специфікації й аналізу відгуків, тож ви перестаєте пояснювати функцію заново щоразу, коли змінюєте аудиторію.
Де ШІ вводить в оману саме продакт-менеджерів
Три помилки мають більше значення на цій посаді, ніж на більшості інших.
Вигадані дослівні цитати. Якщо ви просите репрезентативні цитати, не прив'язуючи модель до вихідного тексту, іноді ви отримаєте правдоподібне речення, якого жоден клієнт не казав. Завжди вказуйте копіюй цитати точно, не переказуй своїми словами, і вибірково звіряйте три з них із сирими даними, перш ніж будь-яка цитата потрапить у слайд.
Хибна впевненість через малі вибірки. Модель тематизує вісім тікетів підтримки з такою ж впевненістю, як і вісімсот. Просіть кількості для кожної теми і ставтеся до всього, що менше жмені випадків, як до спостереження, а не сигналу.
Театр дорожньої карти. Прохання до моделі пріоритизувати ваш беклог дає впевнений рейтинг, отриманий лише зі слів у ваших тікетах. У неї немає доступу до вашої стратегії, ваших ресурсів, вашого технічного боргу чи угоди, яка закривається наступного кварталу. Використовуйте це, щоб структурувати компроміс, але ніколи, щоб ухвалити рішення.
- Збережіть шаблон промпту для PRD у Claude і промпт для критики, який запускати в іншій моделі
- Збережіть шаблон тематизації відгуків у GPT із вставленою наявною таксономією
- Збережіть шаблон сканування конкурентів у Gemini, який вимагає посилання для кожного твердження
- Завжди просіть кількості поряд із темами і ставтеся до малих кількостей як до спостережень
- Наказуйте моделі копіювати дослівні цитати точно, потім вибірково звіряйте три з джерелом
- Проводьте передпохоронний розбір для кожного плану запуску перед оглядом запуску, а не після
- Тримайте специфікацію, відгуки й комунікацію запуску в одному потоці, щоб контекст переносився
Поширені запитання
Чи можна вставляти інтерв'ю з клієнтами?
Так. Для довгих транскриптів використовуйте Gemini: його контекстне вікно на 1 млн токенів вміщує приблизно 2 000 сторінок тексту, тож повний набір інтерв'ю поміщається за один прохід замість поділу на частини. Спершу приберіть імена, електронні адреси та ідентифікатори компанії. Ролі та сегменти, це все, що потрібно для аналізу, а видалення решти тримає вас подалі від більшості внутрішніх політик щодо даних.
Чи інтегрується Whizi з Jira або Linear?
Поки що не нативно. На практиці робочий процес такий: згенеруйте структурований результат у Whizi (користувацькі історії з критеріями прийняття, таблицю тем із кількостями) і вставте у ваш трекер, що займає секунди, бо формат уже такий, якого очікує трекер. Просіть результат у вигляді Markdown-таблиці або по одному запису на блок, якщо хочете вставляти їх окремо.
Яка модель пише найкращий PRD?
Claude для наративних розділів, тобто постановки проблеми, обґрунтування і всього, у чому треба переконати людину. GPT для структурованих розділів, тобто користувацьких історій, критеріїв прийняття, таблиць станів і визначень подій аналітики. Розподіл документа між двома вимагає одного додаткового перемикання моделі і помітно скорочує етап редагування.
Чи безпечно вставляти внутрішню дорожню карту або дані про виручку?
Whizi не навчається на ваших розмовах, а політика даних кожного провайдера доступна ще до того, як ви увімкнете цю модель. Політика вашої компанії зазвичай суворіша. Надійна звичка, це індексувати чутливі цифри замість вставляння абсолютних значень, оскільки аналіз відносного руху працює так само, а числа перестають бути чутливими.
Чи може ШІ пріоритизувати мій беклог?
Він може структурувати компроміс, і це справді корисно: оцінити пункти за критеріями, які ви визначаєте, показати, де два пункти залежать один від одного, і продемонструвати, яким сегментам служить той чи інший вибір. Він не може ухвалити рішення, бо не має видимості вашої стратегії, ресурсів команди чи комерційного контексту. Ставтеся до будь-якого рейтингу, який він видає, як до приводу для обговорення.