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