Современное разделение ролей в продуктовых командах — дизайнер, продакт-менеджер, разработчик — выглядит как нечто очевидное и постоянное. Но оно было придумано в конце 1990-х — начале 2000-х под конкретные технологические ограничения. Эти ограничения исчезают.

Сал Хан, основатель Khan Academy: «Нынешняя модель сформировалась в конце 90-х, начале 2000-х, когда мы только учились создавать веб-приложения. Но в новом мире дизайнеры и PM уже не ограничиваются прототипами».

Почему разделение труда возникло

В классическом product development каждая роль решала свою проблему.

Разработчик — человек, умеющий писать код. Это был редкий навык, занимавший годы обучения. Создание даже простого веб-приложения требовало понимания HTML, CSS, JavaScript, backend-языка, баз данных, серверной инфраструктуры. Дизайнер — человек, умеющий создавать удобные интерфейсы. В 2000-х UX как дисциплина только формировалась. Дизайнер создавал макеты в Photoshop или Sketch — статичные картинки, которые разработчик потом реализовывал. Продакт-менеджер — человек, умеющий переводить между бизнесом и разработкой. PM формулировал требования, расставлял приоритеты, брал на себя коммуникацию. Без PM разработчики не знали, что строить; без PM бизнес не понимал, что происходит в инженерном отделе.

Каждая роль была создана потому что технология была сложной и требовала специализации. Если технология упрощается — специализация теряет смысл.

Что происходит в Khan Academy

«В Академии Хана мы даём дизайнерам и продакт-менеджерам доступ к инструментам разработки, чтобы они сами могли работать с кодом, делать пул-реквесты и полностью выкатывать фичи».

Это не эксперимент. Это текущая практика. Дизайнер делает прототип не в Figma, а сразу в коде. PM проверяет гипотезу не через бэклог разработчика, а запуская собственный вайб-кодинг-эксперимент.

Один из руководителей продуктовых команд описывает: «Я заставляю всех своих PM делать прототипы». Хан: «Ещё пару лет назад я подумал: "Ничего себе, смело". А сейчас это становится нормой».

T-образный специалист становится нормой

Стирание границ не означает, что все становятся равно хороши в разработке, дизайне и продукте. Это означает появление T-образного специалиста в новом смысле.

Горизонтальная планка T — базовое понимание смежных дисциплин. PM должен уметь запускать код, читать diff, понимать что значит «это технически невозможно». Дизайнер должен понимать технические ограничения и уметь сгенерировать рабочий прототип. Разработчик должен думать категориями пользовательского опыта и бизнес-метрик.

Вертикальная планка T — глубокая экспертиза в своей области. «Специалист, который глубоко разбирается в своей области, будет всё равно очень востребован и намного продуктивнее».

T-образность — не новая идея. Но раньше «базовое понимание смежных дисциплин» означало «знать теорию». Теперь ИИ-инструменты дают возможность практиковаться в смежных областях с гораздо меньшим порогом входа.

Новый тип разработчика

Хан описывает ещё одну трансформацию: «Появится новый тип инженеров — тех, кто будет больше работать напрямую с клиентами».

Это инженер, который не просто реализует требования из бэклога, а самостоятельно взаимодействует с пользователями, понимает их проблемы и немедленно проверяет решения через код. Раньше такой человек назывался «full-stack с product-мышлением» и стоил очень дорого. Теперь инструменты снижают порог.

Что это означает для циклов разработки

«Профессии действительно совмещаются, и циклы разработки ускоряются, и людям нужно к этому привыкнуть».

Классический цикл: PM пишет требование → дизайнер делает макет → разработчик реализует → QA тестирует → PM принимает. Каждый этап — отдельная очередь, отдельный приоритет, отдельный контекст-свитч.

Новый цикл: PM вайб-кодит черновой прототип → показывает пользователям → дизайнер улучшает в браузере → разработчик оптимизирует и интегрирует с бэкендом → выкатывают через неделю. Очереди сокращаются, контекст сохраняется.

Что роли всё ещё требуют человека

Стирание границ создаёт ощущение, что все роли скоро исчезнут. Это не так. Есть то, что ИИ не делает хорошо.

Понимание незартикулированных потребностей. Пользователь не всегда может сформулировать, что ему нужно. «Сделайте мне удобнее» — это не спецификация. Понять, что стоит за неудовлетворённостью — задача для человека с эмпатией и опытом. Принятие стратегических решений. «Мы делаем это, а не то, потому что через три года рынок будет там» — это суждение, требующее понимания контекста, который не умещается в промт. Коммуникация со стейкхолдерами. Убедить совет директоров, инвестора, крупного клиента — это навык влияния, который строится на доверии и репутации. ИИ помогает готовиться, но не заменяет само взаимодействие.

Роли не исчезают — они трансформируются. Дизайнер, который только рисует макеты в Figma, не умея ни написать прототип, ни измерить метрику — находится под угрозой. Дизайнер, который владеет кодом на уровне «могу выкатить прототип», понимает аналитику и умеет говорить с разработчиками — становится более ценным, а не менее.

Адаптация требует не смены профессии, а расширения компетенций. Это болезненно, но управляемо.

Дизайнеры пишут код, PM делают прототипы: как ИИ стирает границы профессий