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

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

Всё сразу значит ничего вовремя

У объёма есть свойство расти само. Каждый крайний случай кажется обязательным, каждая соседняя функция — логичным дополнением, каждое «а что если» — поводом добавить ветку. По отдельности всё разумно; в сумме получается план, который не доезжает до пользователя месяцами. А до тех пор обратной связи нет, и весь этот объём строится на непроверенных догадках.

Цена тут не только во времени. Чем больше построено до первого контакта с реальностью, тем дороже разворот, когда выяснится, что догадка была неверной. Большой объём — это не «сделали много», это «много поставили на ставку, которую не проверяли».

Есть простой способ поймать себя на этом: посмотреть на задачу и спросить, какая её часть доедет до пользователя раньше всего остального. Если ответа нет — значит, всё связано в единый пакет и выпустить что-то раньше невозможно без переосмысления структуры задачи. Именно тогда стоит резать.

Наименьший ценный срез

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

Продукт-инженер режет вертикально. Наименьший ценный срез — это самый узкий сквозной путь, который проходит через все слои и реально решает задачу хотя бы для одного случая. В кейсе маркетплейса проблему «продавец не может быстро поднять каталог» не обязательно закрывать сразу импортом любого формата с валидацией, картинками и вариациями. Наименьший срез — завести каталог из таблицы одного простого вида, без вариаций, с понятным сообщением об ошибке. Это уже снимает боль для части продавцов и проверяет главную гипотезу: будут ли вообще заводить каталог так. Остальное — после того, как срез показал, что путь верный.

Хороший срез отвечает на два вопроса сразу: даёт ли он ценность хоть кому-то прямо сейчас и проверяет ли он самое рискованное предположение. Если он только проверяет, но не помогает, — это эксперимент, не продукт. Если только помогает, но ничего не проверяет, — тебе везёт, что угадал.

Пример: личный кабинет

Возьмём задачу, которая с самого начала кажется неделимой, и покажем, как срез находится через бизнес-результат, а не через «что было бы хорошо».

Команда решает запустить личный кабинет для клиентов B2B-сервиса. Первоначальный список выглядит разумно: история заказов, текущий статус, документы (счета и акты), профиль компании, управление пользователями, уведомления по почте, фильтры и экспорт. Восемь блоков — каждый логичный, каждый «нужен».

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

Шаг первый — сформулировать бизнес-результат точно: клиент самостоятельно отвечает на вопрос «где мой заказ», не обращаясь к менеджеру. Под этот бизнес-результат нужны только две вещи: список заказов и статус каждого. Профиль компании, управление пользователями, документы, фильтры, экспорт — всё это бизнес-результата не двигает. В список «не строим сейчас» ушло шесть из восьми пунктов. Не отложено — именно не строим, пока данные не покажут иначе.

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

Наименьший срез: страница со списком заказов и статусом, доступная по ссылке из письма-подтверждения. Без отдельного логина, без управления аккаунтом, без истории документов. Сделано за две недели. После запуска смотрели одно число: доля входящих обращений с вопросом «где мой заказ» за следующий месяц. Она упала на 40%. Гипотеза подтвердилась — клиенты идут в кабинет. Следующим срезом добавили документы: именно их просили чаще всего по результатам первого контакта с реальностью.

Ключевой момент в этой истории — не размер среза, а последовательность решений. Сначала бизнес-результат, потом главный риск, потом минимальный путь, который проверяет и то и другое. Шесть из восьми блоков не «отложили» — убрали явно и по причине. Это позволило запустить через две недели то, что иначе ждало бы три месяца.

Заметьте: всё, что убрали, не исчезло навсегда. Документы вернулись в следующем срезе — потому что данные показали, что они нужны. Управление пользователями — не вернулось, потому что данные этого не показали. Решение «не строить» держится до тех пор, пока не появится причина его пересмотреть.

Что не строить

Решение «не строить» даётся тяжелее, чем «отложить», потому что звучит как поражение. Но «отложим на потом» в большинстве случаев — вежливая форма «не сделаем никогда», и честнее это признать сразу. Список «потом доделаем» почти не разгребается: появляются новые проблемы, у которых приоритет выше, и старое «потом» тихо устаревает.

Поэтому полезно явно держать не только список того, что делаем, но и список того, что сознательно не делаем — и почему. Этот второй список защищает от двух бед сразу: от раздувания текущей задачи и от чувства вины за «недоделанное». Не сделанное по решению — это не долг, это выбор. Крайний случай, который встречается у одного пользователя из тысячи, функция «на всякий случай», красивая ветка, которой никто не просил, — всё это кандидаты в список «не строим», пока бизнес-метрика или контакт с пользователем не докажут обратное.

На практике список «не строим» удобно вести прямо рядом со списком «строим» — в одном документе, одним из разделов задачи. Когда кто-то предлагает добавить функцию, ответ «это в нашем списке не строим, вот почему» — конкретнее и честнее, чем «отложим».

Приоритет по бизнес-результату и риску

Чем резать и что оставлять — решает не вкус, а две оси: вклад в бизнес-результат и риск гипотезы. Вклад в бизнес-результат отвечает, насколько кусок двигает ту метрику, ради которой всё делается; всё, что её не двигает, опускается вниз автоматически. Риск гипотезы отвечает, что будет дороже всего, если мы ошиблись; самое рискованное предположение стоит проверять раньше, пока цена разворота мала.

Из этих двух осей складывается простое правило очерёдности: раньше делается то, что и даёт ценность, и снимает главный риск. Дёшево и неважно — подождёт; дорого и неважно — в список «не строим»; важно, но проверяемо позже — после первого среза.

Когда приоритизировать трудно, полезно задать себе один вопрос: «Что случится, если мы ошиблись в главном предположении?» Если ответ — «придётся переделать большой кусок», значит, это предположение нужно проверить первым, и именно вокруг него строится наименьший срез.

Для продукт-инженера это особенно ценно, потому что он ведёт весь путь один и его время — самый дефицитный ресурс продукта. Каждый кусок, который он решил не строить, — это время, отданное тому, что действительно двигает бизнес-результат. Умение резать — это не про то, чтобы делать меньше; это про то, чтобы из ограниченного времени одного человека выжать максимум пользы.

Доведённый до пользователя узкий срез бьёт любой широкий план, застрявший на полпути.

Что это значит на практике

Умение резать — навык, который сопротивляется двум вещам сразу: интуиции («раз берёмся, сделаем хорошо») и внешнему давлению («а вот это тоже добавьте»). Вот где чаще всего ломается:

Типичные ошибки:

  • Срез режут горизонтально. «Сначала всё API, потом вся фронт» — и месяцами нет ничего проверяемого. Полезный срез всегда сквозной: от пользователя до базы данных, пусть и для самого узкого случая.
  • Откладывают проверку самого рискованного. Приятнее начать с понятного и надёжного — и оставить «мы не знаем, будут ли пользоваться» на потом. Но чем позже проверяется главная догадка, тем дороже её опровержение.
  • «Потом доделаем» записывают как план. Список «потом» не разгребается. Если функция не вошла в срез, честнее сразу пометить её как «не строим», а не «строим позже» — это меняет ожидания и снимает накапливающееся чувство долга.
  • Срез режут, не называя бизнес-результата. Без ответа на вопрос «какую метрику сдвинет этот срез» непонятно, что оставить, а что выкинуть. Нарезка без бизнес-результата — это угадывание, а не приоритизация.
  • Называют большой план «минимальным». «Минимальный» — это не «меньше, чем хотелось бы», а «наименьшее, что даёт ценность и проверяет гипотезу». Если срез нельзя выпустить за одну-две недели, скорее всего, он ещё не минимальный.

Дальше

Самый узкий срез бессмысленен, если его не довести до пользователя и не замерить результат. Следующий шаг — выпустить и измерить. Что именно мерить — решает бизнес-метрика, а не строить то, чего пользователь не просил, учит формулировка проблемы — начало всей цепочки.