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