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