Нові правила створення продуктів: вайбкодинг, ШІ та майбутнє роботи

Вранці в продакт-менеджера виникає ідея, а до обіду вже є робочий прототип. Засновник може перевірити продукт, коли команди ще майже немає. Розробник може доручити агенту частину написання коду й зосередитися на тому, що досі потребує власного судження: чи справді отриманий результат хороший. Ще недавно це звучало б як спосіб зрізати шлях. Тепер так просто виконується значна частина роботи.

У цьому випуску Retention Podcast ми говоримо про те, що відбувається, коли ШІ перестає бути допоміжним інструментом і починає змінювати сам зміст роботи. Хто тепер може створювати прототипи? Де досі потрібен дизайнер або розробник? Які навички раптом стають важливішими, а які частини робочого процесу починають виглядати вкрай неефективними?

До нас приєдналися Andrii Mandryka — радник і ментор із продакт-менеджменту, засновник і тренер Hard Skills for PdM — та Rostyslav Salata, Head of Product (B2C) у Jooble, продакт-менеджер у KOLO й коуч у Hard Skills for PdM.

Прототипування завжди було частиною роботи над продуктом

Прототипування — не новий етап життєвого циклу розробки продукту. Продакт-менеджерам завжди був потрібен спосіб перетворити проблему чи гіпотезу на щось, що команда може побачити й критично оцінити. Це могло бути тривале обговорення з командою для уточнення ідеї, ескіз на папері або макет у Figma, Sketch, Balsamiq чи навіть Photoshop.

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

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

ШІ перетворює прототипи на новий робочий документ

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

Це важливо, адже розробка зазвичай є найдорожчою частиною процесу. Прототип може виявити прогалини ще до залучення інженерів, спростити раннє тестування з користувачами й дати зацікавленим сторонам щось конкретне для зворотного зв’язку. Пройти робочий сценарій також набагато зрозуміліше, ніж пояснювати ту саму логіку на 47 екранах Figma або намагатися узгодити бачення десяти людей навколо документа.

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

Найкраще створить прототип той, хто бачить проблему

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

Уявіть працівника складу, який досі обліковує вхідні палети на папері. Замість того щоб чекати на команду розробки, він може створити простий інструмент для оцифрування процесу, випробувати його у своїй роботі та показати результат тим, хто відповідає за систему загалом. Якщо ідея спрацює, інженери згодом зможуть перетворити її на безпечне, масштабоване й належно інтегроване рішення.

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

ШІ-інструменти стають найшвидшим способом перевірити, чи варто створювати продукт

Деякі продукти тепер народжуються майже повністю в ШІ-інструментах для написання коду. Мета — не створити там фінальну версію, а перевірити попит до залучення повної команди. Один із прикладів — Fitly, сервіс, що адаптує резюме під конкретну вакансію. Його ранню версію створили в Replit, використали для перевірки попиту й перших кампаній із залучення, а до традиційнішого процесу розробки команда перейшла лише після появи перших ознак попиту.

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

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

Для деяких ролей прототипування з ШІ вже є обов’язковою навичкою

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

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

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

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

ШІ може написати код. Розробники все одно мають знати, як виглядає хороший код.

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

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

Тому досвід і вміння оцінювати стають важливішими, а не менш важливими. Розробники мають розуміти, як робота виконується вручну, перш ніж зможуть надійно оцінювати результат ШІ. Той самий принцип діє й поза інженерією: автоматизуйте роботу лише тоді, коли достатньо добре розумієте процес, щоб розпізнати поганий результат.

Спочатку опануйте процес. Потім автоматизуйте.

ШІ по-різному змінює навчання залежно від того, чого саме людина намагається навчитися. Якщо мета — зрозуміти когортний аналіз, навчитися писати код, визначати продуктові метрики чи створювати MVP, надто раннє використання ШІ може приховати, чи розуміє людина базову логіку. Коли навичка вже є, повторювані або допоміжні частини роботи можна автоматизувати без втрати цього розуміння.

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

Різниця — між використанням ШІ для обходу навчання та для скорочення повторюваної роботи. Спочатку зрозумійте, як працює процес; коли зможете оцінювати якість результату, автоматизуйте стільки, скільки доцільно.

ШІ може допомогти навчатися, але не змусить захотіти вчитися

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

Для тих, хто хоче вчитися, ШІ може зробити процес значно гнучкішим. Курс можна перетворити на навчальні картки, тести чи план самостійного навчання, а такі інструменти, як NotebookLM, допомагають організувати матеріал навколо власних прогалин у знаннях. Водночас структуровані курси зберігають перевагу: вони позбавляють потреби розбиратися в усьому самотужки й дають чіткий шлях.

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

У малих групах знання краще закріплюються

Групове навчання дає більше, ніж просто навичку. Воно дає змогу порівнювати підходи, бачити, як інші розв’язують ту саму проблему, і вчитися в тих, хто вже на кілька кроків попереду. Поєднання підтримки, здорової конкуренції та спільного прогресу допомагає зберігати мотивацію й справді завершувати роботу.

Але формат має значення. У групі з чотирьох-п’яти людей може виникнути достатньо довіри, щоб учасники ставили базові запитання, помилялися й навчалися одне в одного. Зберіть 30 чи 40 людей на одному занятті — і підтримувати таку динаміку стане значно складніше.

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

Одні ШІ-інструменти заощаджують час. Інші додають труднощів

Для нетехнічних користувачів, які просто хочуть візуалізувати ідею чи створити базовий прототип, такі інструменти, як Lovable і Replit, зберігають низький поріг входу. Lovable добре підходить для простих візуальних прототипів, а Replit доречніший, коли проєкту потрібні аналітика, автентифікація, бази даних або повніша воронка. Технічніші інструменти, як-от Cursor чи Claude Code, стають корисними, коли завдання потребує більшого контролю, але можуть додати зайвої складності тому, кому потрібно лише донести ідею.

Ширша тенденція — об’єднання інструментів. Замість перемикання між окремими сервісами для досліджень, прототипування, документації, написання коду й керування роботою такі платформи, як Claude, дедалі більше прагнуть стати єдиним інтерфейсом, підключеним до Jira, Notion, календарів та інших частин робочого процесу. Google рухається в схожому напрямі, що також може бути важливим для компаній, де політики безпеки обмежують доступні працівникам ШІ-платформи. Запровадження надійних протоколів безпеки ШІ стало критично важливим, оскільки організації прагнуть запобігти витоку конфіденційних внутрішніх даних через ці пов’язані робочі процеси.

Тому вибір ШІ-інструмента не варто починати з пошуку найпотужнішого. Варто почати із завдання, рівня технічної впевненості користувача й того, яку частину процесу справді потрібно виконувати в одному місці.

Один інтерфейс може взяти на себе більшу частину вашої роботи

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

Це не означає, що всім потрібно створювати власні навички чи плагіни. Важливіше розуміти призначення кожної частини екосистеми — навички, плагіна, конектора чи MCP — і вибирати найпростіший варіант, який розв’язує проблему. У багатьох випадках наявні інструменти вже покривають завдання; справжня майстерність — добре узгодити їхню роботу.

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

ШІ більше змінюватиме професії, ніж замінюватиме їх

ШІ вже може виконувати частини багатьох ролей: аналізувати дані, готувати тексти або генерувати рекомендації. Але результат усе одно потребує людини, яка розуміє контекст і вирішує, що з ним робити. Що більше робота залежить від судження, стратегії, взаємодії із зацікавленими сторонами та відповідальності за рішення, то складніше автоматизувати її повністю.

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

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

Підсумок

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

Це змінює те, що стає цінним у команді. Виконання дешевшає, тож уміння ухвалювати рішення дорожчає. Уміти писати промпти корисно, але важливіше знати, що варто створити, що не так із результатом і коли щось не варто автоматизувати. Та сама людина раптом може робити більше, але лише якщо достатньо добре розуміє роботу, щоб не плутати швидкість із якістю.

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