Почти каждая задача приходит к инженеру уже одетой в решение. «Сделайте кнопку экспорта в Excel». «Нужен дашборд». «Добавьте фильтр по дате». Это удобно — есть что брать в работу. И это же ловушка: решение — всего лишь чей-то ответ на вопрос, который вслух не прозвучал. Построишь буквально то, что просят — построишь чужую догадку и выдашь её за продукт.
Продукт-мышление начинается с обратного движения: раздеть просьбу обратно до проблемы. Не «какую фичу сделать», а «какую задачу человек пытается закрыть и что ему мешает». Пока проблема не названа, любое решение — ставка вслепую, даже если оно технически безупречно.
Просьба говорит решениями
Люди формулируют желания в виде готовых действий, потому что так проще думать. Заказчик внутри компании, клиент, коллега — все приносят не проблему, а её первое попавшееся решение. «Кнопка экспорта» — это уже выбранный механизм. За ним прячется что-то вроде «мне нужно унести данные туда, где я с ними работаю». А «там» может оказаться вовсе не Excel, и «унести» — не разовая выгрузка, а регулярная сверка.
Опасность не в том, что человек неправ. Он лучше всех знает свою боль. Опасность в том, что он уже сделал за тебя шаг проектирования — выбрал решение — не видя остальных вариантов и их цены. Приняв этот шаг как данность, ты наследуешь чужой выбор вместе со всеми его слепыми пятнами.
Чем проблема отличается от решения
Проблему удобно держать как тройку: кто, какую задачу делает и что встаёт на пути. «Продавец заводит новый ассортимент на площадку и не может внести пятьсот позиций руками за вечер». Здесь есть субъект, его работа и препятствие — и ни слова о том, как это чинить.
Решение — это уже один из способов убрать препятствие. Их всегда несколько: импорт таблицы, загрузка через интеграцию из учётной системы, копирование по шаблону, временный помощник на стороне площадки. У каждого своя цена, свой срок и свои риски. Просьба «дайте импорт Excel» схлопывает весь этот веер в одну ветку — и обычно не в лучшую.
Полезная оптика здесь — смотреть на продукт как на то, что человек «нанимает» на работу. Пользователь не хочет дрель, он хочет отверстие; не хочет кнопку экспорта, а хочет, чтобы данные оказались там, где он принимает решения. Вопрос «на какую работу меня наняли?» возвращает разговор от механизма к задаче.
Докопаться до задачи за просьбой
Инструмент простой и почти грубый: на каждую просьбу-решение задавать вопрос «что ты пытаешься сделать?» и «что случится, если этого не будет?». Два-три таких вопроса подряд — и формулировка съезжает с механизма на задачу.
Возьмём сквозной кейс маркетплейса. Продавец просит «массовую загрузку товаров через Excel». Первый вопрос — что пытаешься сделать: «завести весь каталог при выходе на площадку». Второй — что мешает сейчас: «по одной карточке — это неделя работы». Третий — что будет, если не дать: «не выйду к сезону, уйду к конкуренту». Проблема проявилась: новому продавцу нужно поднять каталог в пятьсот позиций за разумное время, иначе он не стартует. Excel в этой формулировке исчез — он был лишь одной из догадок. Может оказаться, что у продавца уже есть выгрузка из его системы, и интеграция закроет задачу лучше; а может, хватит шаблона и проверки на ошибки. Решение выбирается после того, как проблема названа, а не до.
Та же дисциплина защищает от противоположной крайности — раздувания. Когда проблема сформулирована узко и честно, видно, что половина «очевидных» требований решает не её, а воображаемую. Названная проблема — это и список того, что строить, и список того, что строить не нужно.
Почему это первый шаг продукт-инженера
Всё, что идёт дальше в продуктовой работе, опирается на этот шаг. Нельзя выбрать метрику исхода, если не знаешь, какую проблему меришь, — останется мерить выпуск фич. Нельзя нарезать наименьший ценный срез, если не понимаешь, что именно создаёт ценность. Нельзя владеть результатом до пользователя, если результат определён как «сдал фичу», а не «снял боль».
Для продукт-инженера это особенно важно, потому что один человек ведёт весь путь — и некому подстраховать на входе. В большой команде неверно понятую задачу иногда ловит аналитик или тестировщик. Когда продукт делает один с AI, ошибка на входе проходит дальше беспрепятственно. AI быстро и охотно построит ровно ту догадку, которую ты ему дал. Чем мощнее исполнитель, тем дороже обходится неназванная проблема — он доведёт до прода не то.
Поэтому первый навык продуктовой специализации — не придумывать решения, а останавливаться на полшага раньше и спрашивать: какую задачу человек пытается сделать и что ему мешает. Решения подождут; сначала — проблема. А узнаётся она не за столом, а в контакте с пользователем — об этом следующее эссе.