top of page

Вайбкодинг та автодокументація: нові суперсили продакт-менеджера

Вайбкодинг та автодокументація: нові суперсили продакт-менеджера


ШІ-інструменти для продакт-менеджера або економлять години, або краде фокус. Різницю визначає те, як саме їх вбудувати в щоденну роботу. Павло Шнуренко, Product Manager у Promova поділився з HBJ підходами до використання ШІ для документації, UX та локалізації, оптимізації роботи, аналітики й предиктивних моделей, а також вайбкодингу. 



ree


Загальні підходи 


Щоб ШІ давав придатний результат для будь-якої задачі, важливо правильно підготувати контекст:


  • при кожній новій задачі пояснити, що це за продукт, яка саме стоїть задача і яку проблему вона має вирішити;

  • «згодовувати» якнайбільше релевантної інформації: документацію, результати попередніх тестів, пов’язані матеріали — що більше, то якісніший результат;

  • створювати окремі чати / проєкти під різні типи задач, для кожного з них задавати роль і давати приклад ідеально виконаної задачі. 


Список ШІ-інструментів, які використовую:


  • Claude — основний робочий інструмент замість ChatGPT. Менше галюцинує, краще обробляє складні таски, підтримує MCP для інтеграцій з різними платформами.

  • ChatGPT — для стилізації документів під Notion: швидко форматує текст у потрібний вигляд.

  • Chat PRD — спеціалізований інструмент для написання технічної документації у сталому форматі.

  • Figma Make (з підключеною дизайн-системою) — для генерації прототипів на базі готових компонентів.

  • Notion AI — збирає контекст по всіх документах для підготовки до написання документації, формую мітінг ноутс

  • Gemini — для перевірки якості та тональності UX copy та локалізацій, згенерованих іншими AI.

  • Cursor — для розробки iOS-застосунків без глибоких технічних знань.



Робота з документацією


У продакт-менеджменті ШІ найкраще проявляє себе саме в написанні документації й технічних завдань. Це допомагає пришвидшити роботу, зняти частину нудної мануальної рутини (детальний опис кроків, переходів між екранами) і не втрачати при цьому якість. 


Для продуктових документів добре підходить Chat PRD. Цей інструмент дозволяє писати таски у сталому форматі без постійного пояснення структури й контексту з нуля — частина інструкцій у ньому вже налаштована.


Коли велика кількість інформації розкидана по Notion, варто підключати Notion AI. Його можна попросити зібрати контекст по всіх доступних документах на конкретну тему: інструмент структурує дані й повертає посилання на потрібні сторінки, спрощуючи підготовку до написання документації.


ШІ не можна сприймати як джерело істини за замовчуванням. У випадку роботи з документацією це особливо критично. Claude, з яким я працюю, може «додумувати» код або вигадувати зайві, неіснуючі кроки інтеграції, якщо отримує неповний чи неоднозначний вхід. Кожен результат потрібно перевіряти, перш ніж віддавати його в розробку, — логіку, кроки, параметри інтеграції.



UX writing та локалізація


ШІ добре працює як тимчасова заміна UX-райтерів і локалізаційних команд, коли потрібно швидко запустити тест і немає часу чекати на тексти. Якщо критично важлива швидкість, а не відполірований текст, ШІ закриває версії в першому ітераційному колі. Пізніше їх можна віддати на рев’ю профільним командам.


Щоб зменшити ризик помилок і некоректної тональності, зручно використовувати зв’язку з двох ШІ:


  1. Спочатку тексти (рядки інтерфейсу, повідомлення, мікрокопі) перекладаються або адаптуються в Claude.

  2. Отриманий результат передається в Gemini з запитом: перевірити коректність перекладу, оцінити відповідність tone of voice продукту, за потреби запропонувати правки.


Коли один ШІ «рев’юить» іншого, зменшується шанс пропустити помилки або невдалу тональність.



Meeting notes


ШІ зручно використовувати для фіксації результатів зустрічей, особливо коли наприкінці дня складно пригадати всі домовленості та наступні кроки.


Базовий процес виглядає так:


  1. Notion AI використовується для автоматичного створення транскриптів мітингів. Водночас якість сирого транскрипту з цього інструменту часто низька, тому його доцільно сприймати як проміжний технічний крок.

  2. Повний транскрипт мітингу копіюється з Notion і передається в Claude як вхідні дані. У промпті до Claude можна перерахувати всіх учасників мітингу, які брали участь в обговоренні, та попросити виписати окремо для кожного учасника follow-up повідомлення зі всіма кроками, які він має зробити.


Такий підхід дає якісно структурувати результати зустрічі. Це один із найпоширеніших практичних кейсів.



Аналітика та предиктивне моделювання


ШІ добре працює не лише з текстами, а й з цифрами — з його допомогою зручно будувати предиктивні моделі для ключових продуктових метрик. 


Предиктивні моделі в цьому підході застосовуються насамперед для:


  • розрахунку юніт-економіки;

  • прогнозування ребілу підписок (повторних списань за підписку) та ретеншену користувачів;

  • швидшого прийняття рішень після запуску тесту — без очікування довгої валідації.


Як побудувати модель за допомогою Claude:


  1. Обирається математична модель — у цьому кейсі використовується Shifted Beta Geometric, яка добре працює з предиктивними метриками.

  2. У Claude формулюється запит на генерацію коду для Google Colab на базі цієї моделі.

  3. Код підхоплює дані з Google Sheet, бере потрібний зріз (наприклад, конкретний рядок чи набір рядків), трансформує дані у формат, з яким може працювати модель, передає їх у Shifted Beta Geometric. 

  4. Розрахований прогноз повертається назад у Google Sheet.


У результаті з’являється робочий пайплайн: дані з таблиці → модель → оновлений прогноз у тій самій таблиці.


Модель необхідно перевіряти на реальних даних. Наприклад, вона розраховує ретеншен на 52 тижні, маючи лише три вихідні точки; далі цей прогноз порівнюється з фактичними даними за ті ж 52 тижні. Тоді за результатами перевірки буде видно, чи модель достатньо точно відображає реальний ретеншен.


Щоб рішення не «застигало» в моменті, предикти варто регулярно оновлювати — наприклад, раз на тиждень на дедалі більшому масиві даних і дивитися, як змінюється динаміка.



Vibe-coding та розробка


Поточні ШІ-інструменти дозволяють запускати власні ідеї й pet-проєкти, навіть якщо немає базових технічних знань. Для багатьох продакт-менеджерів це спосіб нарешті отримати «свій» продукт, а не працювати тільки з чужими гіпотезами.


Один із прикладів — прототип застосунку для менеджменту підписок, яких стає занадто багато і списується відчутна сума грошей. Для цього використовувалися інструменти: Cursor, ChatGPT, Figma AI, Xcode. Наразі це прототип працюючої логіки, над UI потрібно працювати окремо.


ree

Результатом став повністю працюючий функціонал, протестований на телефоні. Додаток дозволяє:


  • додавати всі підписки;

  • вказувати ціну, категорії, цикл (як часто списуються гроші) та день / тиждень / місяць списання;

  • дивитися узагальнену інформацію на головній сторінці;

  • аналізувати витрати в окремому розділі інсайтів.


Наступний логічний крок у такому підході — додати пуш-сповіщення, які за кілька днів до списання нагадуватимуть користувачу про підписку, щоб її можна було вчасно переглянути або скасувати.


Попри те, що я маю базові знання з Python, натомість важливішими є розуміння, як будується розробка iOS застосунків та працюють навігація й екрани. Саме на налаштування навігації пішло найбільше зусиль у Cursor: інструменту доводилося детально пояснювати, як саме мають працювати переходи між екранами та попапами, і неодноразово фіксити помилки, поки логіка не починала працювати правильно.


Якщо немає досвіду з Cursor та Xcode, можна використати сервіс Rork. Він може відмалювати дизайн, оформити все у код, а також одразу завантажити його. Це дозволяє сфокусуватися на продукті та сценаріях використання, а не на низькорівневих деталях реалізації.


Загалом варто використовувати ШІ збалансовано: делегувати йому рутину, але зберігати відповідальність за зміст і залишати частину роботи собі як продакт-менеджеру.



© 2035 by Business Name. Made with Wix Studio™

bottom of page