Head of Product Notion Макс Шьонінг — людина, яку складно втиснути в одну роль. У минулому він був продакт-менеджером у Google, очолював дизайн у Heroku, був дизайн-лідером і одночасно інженером у GitHub за Ната Фрідмана, двічі запускав власні стартапи. Сьогодні він керує продуктом у Notion і системно ламає кордони між ролями: дизайнери й продакт-менеджери там не лише малюють макети, а й прототипують у коді та, до певної міри, комітять у продакшн.
Ця трансформація — не про «усі мають навчитися програмувати». Вона про інше: як AI-інструменти зробили створення робочих прототипів настільки доступним, що компанії, які хочуть рухатися швидко, змушені переосмислювати саму структуру ролей. У центрі цієї зміни — поняття «agency» (дієздатність, суб’єктність): очікування, що люди виходитимуть за межі посадових інструкцій і братимуть на себе більшу частину життєвого циклу продукту — від ідеї до працюючого софту.
Від Figma до термінала: як у Notion з’явився «дизайн у коді»
Кілька років тому типовий робочий процес у продуктових командах виглядав знайомо: дизайнери працюють у Figma, PM пише стратегію й PRD, інженери реалізують. Межі між дисциплінами були чіткими, а перехід через них — радше винятком.
У Notion ця схема почала ламатися з дуже конкретної проблеми: команда будувала багато чат-інтерфейсів для AI-функцій, але статичні макети в Figma виявилися майже безпорадними для такого типу продукту. Статичний скрін чату — це «мертва риба»: він не дає відчути поведінку моделі, динаміку діалогу, відгук системи на різні типи запитів.
Щоб вирішити це, двоє дизайнерів разом із Шьонінгом зібрали невеликий, максимально простий playground — окремий кодовий репозиторій, спеціально «підлаштований» під можливості LLM. Це був не ідеальний фреймворк і не новий продукт, а свідомо «найгірший можливий» кодовий майданчик: мінімум складності, максимум дружності до моделей і людей, які бояться термінала.
Цей playground став альтернативою Figma саме для чат-інтерфейсів. Замість того, щоб малювати черговий статичний екран, дизайнери й PM почали працювати з живою системою: змінювати промпти, структуру діалогу, поведінку відповіді. Важливо, що це відбувалося не в основному коді Notion, а в окремому, «безпечному» середовищі, де важко щось зламати й легко експериментувати.
Ключовий дизайн цього середовища був підпорядкований одній меті: зняти психологічний бар’єр. Інтерфейс і процес взаємодії були зроблені так, щоб:
- термінал не лякав людей, які ніколи не працювали з ним;
- більшість дій можна було виконати «в один постріл» — одна команда, одна зміна, один результат;
- AI-інструменти могли ефективно допомагати з кодом, бо структура репозиторію була «LLM-friendly».
Результат: люди, які раніше жили виключно в Figma чи документах, почали працювати з реальним кодом — спочатку для прототипів, а потім, поступово, і в напрямку продакшн-змін.
Культура «drive Notion like it’s stolen»: агентність як норма
Технічні інструменти самі по собі не змінюють культуру. Те, що сталося в Notion, — це наслідок іншого очікування, яке Шьонінг формулює дуже прямо: «drive Notion like it’s stolen». Метафора з автокультурою означає стиль поведінки, коли людина поводиться з компанією й продуктом не як з чимось далеким і бюрократичним, а як із власним інструментом, який можна й треба активно «крутити» під себе.
У такій культурі дизайнер не зупиняється на макеті, якщо бачить, що наступний логічний крок — перевірити гіпотезу в живому інтерфейсі. Продакт не обмежується стратегією в документі, якщо може сам зібрати робочий прототип і показати команді, як це має працювати.
Це й є «agency» у практичному сенсі: не чекати, поки хтось із «правильними скілами» дозволить рухатися далі, а самому братися за наступний етап. Шьонінг прямо говорить, що раніше було дуже легко сказати собі: «Я ніколи цього не зроблю, бо в мене немає потрібних навичок». У світі, де AI робить більшу частину технічної рутини, така відмовка перестає працювати. Навички стають доступнішими, а от внутрішня готовність діяти — ні. Вона, на його думку, «розподілена в світі дуже нерівномірно».
У Notion ця готовність підкріплена структурно. Playground — це не просто технічний тул, а сигнал: від дизайнерів і PM очікують, що вони будуть працювати з живим софтом, а не лише з презентаціями. Коли людина один раз проходить через страх термінала й бачить, що може змінити поведінку продукту власноруч, кордони ролі для неї розмиваються.
Це не означає, що всі мають стати фулстек-інженерами. Але означає, що «я не інженер» більше не приймається як причина не спробувати.
AI як каталізатор: коли перші 10% проєкту стають безкоштовними
Шьонінг описує ще одну фундаментальну зміну: перші 10% будь-якого проєкту сьогодні фактично безкоштовні. З появою LLM та інструментів на їх основі зібрати першу версію стартапу чи фічі стало справою годин, а не тижнів. Це не означає, що весь продукт будується «сам», але стартовий бар’єр різко впав.
У такому середовищі було б дивно, якби компанія продовжувала жорстко відділяти «мислення» від «роблення». Якщо AI може допомогти дизайнеру чи PM написати робочий код для прототипу, то логічно очікувати, що вони цим скористаються. І навпаки, якщо організація продовжує тримати реалізацію за щільною інженерною «брамою», вона просто втрачає швидкість, яку дають нові інструменти.
У Notion це виглядає як поступове розширення зони відповідальності неінженерних ролей. Спочатку — окремий playground для чатів. Потім — невеликі зміни в основному коді: стилі, дрібні правки, поведінкові деталі. Зараз дизайнери й PM уже «до певної міри» комітять у продакшн-кодову базу. Масштаб їхнього внеску поки обмежений, але тренд очевидний: зі зростанням можливостей моделей зростає й обсяг роботи, яку можуть виконувати люди без класичної інженерної освіти.
Це не просто про економію часу. Це про зміну того, хто має право «торкатися» продукту. Якщо раніше шлях від ідеї до тестованої версії пролягав через кілька рук і кілька команд, то тепер одна людина може пройти значну частину цього шляху самостійно. І компанії, які це заохочують, отримують суттєву перевагу в темпі.
Чому важливо, щоб дизайнери й PM розуміли код — але не обов’язково шипили його
На тлі загальної моди на «дизайнери мають шипити код» Шьонінг займає помітно відмінну позицію. Він прямо каже: йому байдуже, чи потрапляє написаний дизайнером код у продакшн. Справжня цінність — у тому, що робота в коді змушує людину глибоко зрозуміти матеріал, з яким вона працює.
Для класичного UI це означає розуміння обмежень і можливостей фронтенд-стека. Для AI-продуктів — ще важливіше: розуміння того, як працюють агентні петлі (agent loops), як система приймає рішення, як вона взаємодіє з користувачем у динаміці.
Шьонінг формулює це дуже чітко: якщо обирати між дизайнером, який уміє трохи підкручувати UI через Claude Code чи Codex, але не розуміє, як влаштована агентна петля, і дизайнером, який глибоко розуміє агентні цикли, але не вміє верстати стилі, він без вагань обере другого. Тому що майбутнє продуктів — у поведінці систем, а не в дрібних візуальних нюансах.
Парадокс у тому, що зрозуміти ці агентні петлі по-справжньому можна лише працюючи з ними в їхньому «рідному» середовищі — коді. Документи й діаграми тут мало допомагають. Потрібно будувати, запускати, ламати, дивитися на реальну поведінку.
Саме тому в Notion так багато уваги приділяється прототипуванню в коді. Не для того, щоб перетворити дизайнерів на ще одну гілку інженерного відділу, а щоб вони стали «майстрами матеріалу», з якого зроблений продукт. Коли людина мислить у термінах реальної поведінки системи, а не лише візуальних станів, вона приймає інші продуктові рішення.
Це вже дає побічний ефект: як тільки людина звикає до нового матеріалу, вона природно починає заходити й у продакшн. Лінія між «прототипом» і «фічею» розмивається. Але для Шьонінга це радше наслідок, а не мета.
Межі, що розмиваються: швидкість проти глибокої спеціалізації
Зі сторони може здатися, що така модель неминуче веде до зникнення глибоких спеціалістів. Якщо всі трохи дизайнери, трохи PM, трохи інженери, хто тоді будує складні, надійні системи? Сам Шьонінг не ідеалізує повне злиття ролей і прямо говорить, що є ризик втратити сильних інженерів і дизайнерів як окремі професії.
Ще одна його тривога — «vibe coding»: коли AI дозволяє дуже швидко збирати працюючий на вигляд софт, але загальна надійність продуктів від цього не росте. За його оцінкою, за останні 12 місяців кількість софту вибухово збільшилася, а от якість і стабільність — не дуже. Прототипи стають схожими на готові продукти, але під капотом часто лишаються «3D-друкованими» моделями, які не витримують навантаження.
Щоб пояснити цю різницю, Шьонінг використовує апаратну метафору: 3D-друкований прототип і масово вироблений продукт — це різні світи. Перший дозволяє швидко перевірити форму й базову функцію, другий вимагає інженерної дисципліни, матеріалознавства, виробничих процесів. Те саме відбувається й у софті: те, що легко зібрати в playground, ще не означає, що воно готове до мільйонів користувачів.
Тому в Notion намагаються тримати баланс. З одного боку, заохочують дизайнерів і PM заходити в код, щоб прискорити шлях від ідеї до тестованого прототипу. З іншого — не перетворюють це на культ «усі шиплять у продакшн». Інженерна команда залишається відповідальною за перетворення 3D-друкованих моделей на «масове виробництво»: оптимізацію, безпеку, масштабованість.
Це не повернення до старої моделі «кинути через стіну в розробку», а радше новий розподіл праці: більше людей залучені на ранніх етапах у реальний код, але фінальна інженерна обробка не зникає.
Як це змінює темп: від ідеї до тесту — за дні, а не місяці
Найпомітніший наслідок цієї культурної й технічної трансформації — швидкість. Коли дизайнери й PM можуть самі зібрати робочий прототип у коді, компанія отримує кілька переваг одночасно.
По-перше, скорочується кількість «перекидань» між командами. Замість того, щоб чекати, поки інженери знайдуть час на експеримент, люди, які придумали ідею, самі доводять її до стану, коли її можна потестити на реальних користувачах або хоча б на внутрішній аудиторії.
По-друге, зменшується розрив між задумом і реалізацією. Коли автор ідеї працює безпосередньо з матеріалом, менше шансів, що задум буде спотворений у процесі передачі. Це особливо критично для AI-функцій, де дрібні зміни в промптах чи логіці агента можуть радикально змінити користувацький досвід.
По-третє, з’являється можливість робити більше ітерацій за той самий час. Шьонінг говорить про «репи» як про тренування моделі: щоб розвинути «смак» до хороших рішень, потрібно багато разів прогнати цикл «ідея — реалізація — зворотний зв’язок». Коли кожна ітерація вимагає повного інженерного циклу, це дорого. Коли значну частину роботи можуть зробити дизайнери й PM у playground, кількість ітерацій зростає.
У підсумку Notion отримує те, що багато компаній намагаються досягти роками: короткий шлях від задуму до чогось, що вже можна «помацати» в продукті. І це не результат чарівної методології, а наслідок дуже конкретних рішень: дати неінженерам інструменти для роботи з кодом, очікувати від них такої роботи й при цьому не руйнувати інженерну глибину.
Висновок: майбутнє продукту — за тими, хто переходить межі
Історія Notion під керівництвом Макса Шьонінга показує, як AI не просто додає нові фічі в продукти, а змінює саму тканину організацій. Коли перші 10% будь-якого проєкту стають майже безкоштовними, головним обмеженням стає не доступ до навичок, а готовність людей виходити за межі своїх ролей.
Культура високої агентності — «drive Notion like it’s stolen» — у поєднанні з продуманими інструментами на кшталт LLM-дружнього playground’у робить те, що ще кілька років тому здавалося екзотикою: дизайнери й PM не просто «впливають на продукт», а безпосередньо працюють із його кодом. Вони не обов’язково стають інженерами, але стають глибокими знавцями матеріалу, з якого зроблений сучасний софт — особливо там, де йдеться про AI й агентні системи.
Це не скасовує потреби в сильних інженерах і не вирішує автоматично проблему якості. Прототипи все ще потрібно перетворювати на надійні, масштабовані продукти. Але компанії, які вміють поєднати високу агентність із інженерною дисципліною, отримують головну перевагу епохи AI: здатність рухатися швидше за конкурентів, не розсипаючись на ходу.
У світі, де AI робить навички доступнішими, ніж будь-коли, саме така організаційна «суб’єктність» — готовність людей брати на себе більше, ніж формально прописано в їхній ролі, — стає новим дефіцитним ресурсом.
Джерело
Why cultivating agency matters more than cultivating skills in the AI era | Max Schoening (Notion)