На наших тренингах за последний год изменился состав участников. Раньше приходили в основном скрам-мастера и продакт-менеджеры. Сейчас все чаще появляются люди, которые между делом рассказывают, как за выходные собрали инструмент для своей команды. Аналитик, который автоматизировал еженедельную сверку данных. Маркетолог, которая сама делает лендинги для тестирования гипотез. Люди, которые год назад не написали бы ни строчки кода.
Их называют продакт-инженерами, и мне кажется, это одно из самых интересных изменений в том, как устроена работа команд.
Перевод между головами
Cursor, Claude, Bolt, все эти инструменты были вопросом времени. Андрей Карпатый в 2025 назвал подход вайбкодингом, и за год он превратился из эксперимента в рабочий инструмент для людей без технического бэкграунда.
Но что происходит с работой команды, когда такими инструментами начинают пользоваться люди с глубокой экспертизой в своей области?
Аналитик знает, что данные в двух системах расходятся, и знает почему, при каких условиях и с какой периодичностью. Он ставит задачу разработчику. Разработчик получает ТЗ «автоматизировать сверку таблиц А и Б». Через месяц готово, работает, но не совсем так, как нужно, потому что нюансы потерялись при переводе между головами.
Когда тот же аналитик может сам за два вечера собрать скрипт, который делает ровно то, что нужно (ему ведь не надо объяснять самому себе контекст), это другое качество решения. И другая скорость.
С маркетологами похожая история, но с другим эффектом. Проверка гипотезы раньше означала постановку задачи дизайнеру, потом фронтенд-разработчику, потом две-три недели ожидания. Сейчас маркетолог сама собирает лендинг, запускает трафик и к концу недели уже имеет данные. К моменту, когда в старом процессе разработчик только открыл бы задачу, она уже протестировала три варианта и знает, какой работает.
А продакт-менеджер, который вместо документа с требованиями приносит команде работающий прототип с обратной связью от десяти пользователей, это вообще другой разговор с разработкой. Он может показать, что именно нужно, а команда может обсуждать конкретное решение вместо абстрактного описания.
Отдельно стоит сказать про руководителей. Когда директор по продажам сам собирает себе дашборд с нужными ему срезами данных, или операционный директор за вечер делает инструмент для трекинга метрик, которые его волнуют, это фундаментальный сдвиг в том, как устроено управление. Руководитель перестает ждать, пока аналитический отдел подготовит отчет в том формате, который ему удобен. Он может сам задать вопрос данным и получить ответ. Решения начинают приниматься быстрее, потому что исчезает очередь на аналитику.
В этом, пожалуй, и есть суть продакт-инженерного подхода. Человек, который понимает проблему, и человек, который строит решение, это один и тот же человек. Перевод знания между головами исчезает, а вместе с ним исчезает и потеря информации на каждом шаге.
Подвох с продуктовым мышлением
Здесь есть подвох, который многие обнаруживают на собственном опыте. Собрать прототип с помощью AI несложно. Собрать прототип, который кому-то реально нужен и который переживет первую неделю использования, гораздо сложнее.
Мы видим это регулярно. Человек осваивает инструменты, с энтузиазмом собирает пять прототипов за две недели, и потом ни один из них не живет дольше месяца. Потому что вопросы «для кого это» и «как понять, что это работает» не задавались.
Продуктовое мышление, умение задать правильный вопрос перед тем как что-то строить, оказывается важнее умения строить. Какую проблему мы решаем? Для кого? Как поймем, что решение работает? Что будем делать, когда получим первую обратную связь? Когда стоит масштабировать, а когда честнее выбросить и начать заново? Без ответов на эти вопросы AI-инструменты превращаются в генератор незавершенных проектов.
И вот это за несколько вечеров с YouTube не освоишь. AI-инструменты можно освоить самостоятельно, это правда несложно. Способность задать правильный вопрос перед тем как что-то строить, это навык работы с людьми и решениями, и он формируется через практику с обратной связью.
Расширить возможности в своей области
Несколько лет подряд самым популярным карьерным запросом было «войти в IT». Люди шли на курсы Python, учили алгоритмы, готовились к собеседованиям на джуниорские позиции. Продакт-инженерный подход предлагает другую логику. Аналитик остается аналитиком, маркетолог остается маркетологом, но теперь их экспертиза перестает упираться в ограничения инструментов. Они могут сами проверять свои идеи.
Доменная экспертиза, понимание специфики отрасли, знание болей пользователей, все это и есть самое ценное. AI закрывает техническую часть. Продуктовые навыки помогают превращать экспертизу в работающие решения. И это другая точка входа, которая для многих оказывается гораздо естественнее, чем переучиваться на разработчика.
Что это меняет в компаниях
На уровне компании продакт-инженерный подход меняет скорость проверки идей. Когда гипотезу можно проверить за два дня вместо того, чтобы два месяца стоять в очереди к разработке, количество экспериментов растет кратно. Компания может позволить себе пробовать больше, потому что стоимость каждой попытки упала. Аналитик выяснил, что гипотеза не работает, за два дня. Это не провал, а экономия двух месяцев.
Но работает это только там, где есть доверие к людям ближайшим к проблеме. Если каждый прототип нужно согласовать с тремя уровнями менеджмента, подход не приживется, какие бы инструменты ни были доступны.
И отдельная история с поддержкой. Когда скрипт аналитика используют три месяца, а потом аналитик уходит в отпуск и скрипт ломается, кто-то должен с этим разбираться. Внутренние продукты, которые никто не планировал, все равно нуждаются в управлении. Agile-практики (беклог, ретроспективы, итерации) для этого на удивление хорошо подходят, потому что дают структуру для работы с тем, что начиналось как эксперимент одного человека.
Ограничения
Прототип это не продукт. Безопасность, масштабирование, интеграция с корпоративными системами, все это по-прежнему требует профессиональной разработки. Продакт-инженерный подход хорош для проверки идей и внутренних инструментов, но у него есть потолок, и важно этот потолок чувствовать.
AI-инструменты пока плохо работают с контекстом конкретной организации. Они не знают ваших внутренних процессов и ограничений безопасности. Решение, которое технически работает, может нарушать политики компании или создавать риски с данными. Продакт-инженер, который этого не учитывает, создает технический долг.
С чего начинать
Взять задачу, которая раздражает вас каждую неделю, и попробовать решить ее с AI. Cursor, Claude, Bolt, десятки туториалов. Если получится, продуктовое мышление поможет превратить прототип в полезный инструмент для команды. А если чувствуете, что инструменты освоены, но прототипы почему-то не доживают до реального использования, скорее всего, дело именно в продуктовых навыках.
Хотите развить продуктовое мышление и agile-навыки?
Тренинг Certified Agile Professional дает фундамент для итеративной работы с продуктом, включая AI-инструменты в agile-контексте.
Узнать подробней