Как мы превратили 700 студентов‑гуманитариев в продуктовые команды и получили 51 MVP за 8 недель

Что произойдёт, если обучать гуманитариев как стартапы: результаты эксперимента на 700 студентах

Когда несколько лет назад мы создавали April Live, каждое продуктовое решение имело свою цену. Любая новая гипотеза означала необходимость собрать ресурсы, сформировать команду, выделить время разработки и пройти длинный путь от идеи до проверки на реальных пользователях. Позже мне пришлось решать похожие задачи уже в других масштабах: строить data‑driven и AI‑направления в контуре Ростеха, запускать продукты на основе больших данных, заниматься поиском product‑market fit для стартапов и выводом новых решений на рынок. В каждом случае меня преследовал один и тот же вопрос.

Что на самом деле является главным ограничением создания продукта?

За последние двадцать лет индустрия привыкла считать, что главный дефицит — это разработчики, технологии и инвестиции. Однако собственный опыт всё чаще подталкивал меня к другому выводу. Когда в IQ Auto мы запускали AI‑управляемую экосистему автомобильного рынка, успех MVP определялся не тем, насколько сложно был устроен алгоритм, а тем, насколько точно удалось понять реальные потребности покупателей и продавцов автомобилей. Когда мы создавали April Live, ключевые решения рождались не в обсуждении технологий, а в попытках понять психологические механизмы взаимодействия человека с цифровой средой.
Поэтому весной 2026 года, когда Институт психологии и образования Казанского федерального университета предложил мне стать научным руководителем практикума по созданию цифровых продуктов, меня заинтересовала не образовательная часть проекта. Меня заинтересовала возможность проверить продуктовую гипотезу.

Что произойдёт, если дать будущим психологам, педагогам, экономистам, юристам и лингвистам те же инструменты, которыми сегодня пользуются стартапы? Что произойдёт, если вместо очередного курса по искусственному интеллекту провести их через полный цикл создания продукта: от поиска проблемы и проведения Customer Development до построения MVP, подготовки инвестиционного питчдека и защиты проекта в формате настоящего Demo Day?

На старте проекта я не был уверен в результате. Даже профессиональные команды далеко не всегда способны пройти путь от идеи до работающего продукта за восемь недель. Тем более если речь идёт о людях, которые никогда не занимались продуктовой разработкой и не писали ни строчки кода.

Через два месяца 51 команда представила работающие цифровые продукты, а ещё 19 команд защитили проекты по Data Science и машинному обучению. Все проекты прошли через ту же продуктовую воронку, которую я обычно требую от собственных команд: проблема, аудитория, гипотеза, пользовательский сценарий, архитектура решения, MVP, метрики успеха и публичная защита перед экспертной комиссией.

Однако самым интересным результатом эксперимента стали вовсе не продукты.

Самым интересным оказалось то, что после появления генеративного искусственного интеллекта многие наши представления о том, кто способен создавать технологии, начинают стремительно устаревать.

Почему большинство проектов умирает ещё до первой строчки кода

За годы работы с продуктами я заметил одну закономерность: когда проект проваливается, команда почти всегда объясняет это техническими причинами. Наиболее распространенные «отмазки», которыми грешил сам автор:

1. Не хватило разработчиков или бюджета на лучших.

2. Не хватило бюджета.

3. Не успели реализовать функциональность. «Запускались, как могли, иначе вообще никогда бы не запустились»

4. Выбрали неправильный стек.

Однако если посмотреть глубже, в большинстве случаев причина оказывается другой: команда слишком рано начинает обсуждать решение и практически никто не хочет говорить о проблеме. Это особенно хорошо заметно на стартапах ранней стадии. Стоит собрать в одной комнате предпринимателя, разработчика и дизайнера, как через пятнадцать минут разговор почти неизбежно переходит к функциям продукта. Обсуждаются нейросети, мобильные приложения, архитектура, интерфейсы, API и способы масштабирования. При этом вопрос о том, какую именно проблему пользователя мы решаем и почему существующие решения не работают, зачастую остаётся без ответа. Именно поэтому первый месяц практикума оказался самым болезненным.

Студенты хотели обсуждать искусственный интеллект, [отели обсуждать чат‑ботов, хотели обсуждать мобильные приложения, интерфейсы, но я категорически запрещал говорить о продукте до тех пор, пока команда не могла ответить на четыре вопроса:

1. Кто наш пользователь?

2. Какую проблему он испытывает?

3. Как он решает её сегодня?

4. Почему существующие решения его не устраивают?

На первый взгляд эти вопросы кажутся банальными. На практике именно на них ломается большинство проектов.

Что я обычно требую от продактов

За последние годы мне приходилось запускать продукты в очень разных средах: от корпоративных платформ на основе больших данных до стартапов в области искусственного интеллекта и цифровой психологии. Независимо от масштаба проекта требования всегда оставались одинаковыми.

Я никогда не спрашиваю у команды, какие функции нужно реализовать. Я спрашиваю, какие пользовательские сценарии мы хотим изменить.

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

Я не спрашиваю, какие экраны появятся в приложении. Я спрашиваю, какие решения должен принять пользователь и что поможет ему принять их быстрее, проще или качественнее.

По сути работа продакта начинается в тот момент, когда он перестаёт думать о продукте и начинает думать о человеке.

Именно эту логику мы попытались воспроизвести в университете.

Почему психологи неожиданно получили преимущество

Примерно через три недели после начала практикума начали проявляться первые закономерности. Студенты‑психологи гораздо быстрее других групп справлялись с задачами Customer Development. Они лучше формулировали сегменты аудитории, лучше понимали мотивацию пользователей, лучше описывали барьеры и причины поведения.

Когда команды начинали строить Customer Journey Map, разница становилась ещё заметнее.

Многие технические специалисты традиционно воспринимают CJM как инструмент визуализации сценариев. Для психологов это оказался естественный способ анализа поведения человека. По сути они занимались тем же самым, чему их учили на протяжении нескольких лет: пытались понять мотивы, ожидания, переживания и точки принятия решений.

В какой‑то момент я поймал себя на неожиданной мысли: возможно, последние двадцать лет индустрия недооценивала значение гуманитарных компетенций в продуктовой разработке, потому что современный AI постепенно забирает часть технической сложности.

А вот понимание человека автоматизировать значительно труднее.

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

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

• Фронтенд.

• Бэкенд.

• Сущности.

• Типы данных.

• Бизнес‑процессы.

• События.

• API.

• Микросервисы.

Когда студенты‑психологи впервые слышали эти слова, многие были уверены, что попали не туда, куда думали. Однако здесь скрывается важная проблема современного рынка: большинство людей воспринимают цифровой продукт как интерфейс.

На самом деле интерфейс — это лишь вершина айсберга. Любой продукт представляет собой систему преобразования информации:

1. Пользователь совершает действие.

2. Система получает событие.

3. Происходит обработка данных.

4. Формируется бизнес‑логика.

5. Возвращается результат.

6. Меняются данные.

7. Обновляется интерфейс.

Если человек понимает эту цепочку, он начинает мыслить как создатель продукта, а не как пользователь приложения. Именно поэтому уже через несколько недель команды спокойно обсуждали сущности, связи между объектами, пользовательские события и потоки данных.

Не потому, что они стали разработчиками. А потому, что начали понимать устройство цифровых систем.

Где на самом деле помог искусственный интеллект

Многие, услышав историю про 700 студентов и создание десятков цифровых продуктов, ожидают увидеть в центре повествования искусственный интеллект. Логика понятна: если проект связан с AI, значит именно AI должен выступать главным действующим лицом. Однако по итогам практикума я пришёл к выводу, что роль искусственного интеллекта оказалась одновременно гораздо скромнее и гораздо интереснее, чем принято считать.

На протяжении всего проекта ИИ практически никогда не принимал ключевых продуктовых решений. Он не выбирал аудиторию, не формулировал ценностное предложение, не проводил Customer Development и не определял, какую проблему действительно стоит решать. Всякий раз, когда команда пыталась переложить эти задачи на нейросеть, качество результата резко снижалось, поскольку искусственный интеллект способен генерировать правдоподобные ответы, но не способен заменить понимание контекста, возникающее в результате живого взаимодействия с пользователями.

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

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

Фактически искусственный интеллект не заменял участников проекта, а перераспределял их внимание. Освобождая команды от большого объёма рутинной работы, он заставлял их сталкиваться с вопросами более высокого уровня сложности: почему пользователь должен выбрать именно это решение, каким образом изменится его поведение после взаимодействия с продуктом, какие скрытые мотивации стоят за наблюдаемыми действиями и где проходит граница между интересной идеей и действительно востребованным продуктом.

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

Именно поэтому главным результатом нашего эксперимента я считаю вовсе не 51 созданный продукт и не 19 проектов по Data Science. Значительно важнее оказался другой вывод: в мире, где технические барьеры стремительно снижаются, конкурентное преимущество всё чаще возникает не на стороне тех, кто лучше знает технологии, а на стороне тех, кто лучше понимает людей. И если эта тенденция сохранится, то в ближайшие годы мы можем увидеть весьма неожиданную трансформацию рынка, в которой психологи, педагоги и другие гуманитарии окажутся среди наиболее востребованных создателей новых AI‑продуктов.