Тема отвечает на вопрос, что делать с просьбой «сделайте кнопку», чтобы команда не построила функцию, которой потом не пользуются. Ответ: разложить запрос на три уровня и записать в работу не просьбу, а боль с подтверждением.
Ключевая мысль. Просьба — то, что заказчик произносит вслух. Боль — почему просьба возникла. Работа — результат, которого он пытается достичь. Заказчик лучше всех знает свою боль и хуже всех — какое решение её закроет.
У запроса почти всегда есть вопрос под вопросом: когда генеральный говорит «обоснуйте», он спрашивает, почему сейчас, почему столько ресурса и что будет, если не делать. С просьбой «сделайте кнопку» так же.
Боль без подтверждения остаётся гипотезой. Факт — это то, у чего есть источник, дата и автор и что можно перепроверить. «Клиенты сказали, что купят» фактом не является, это вежливость.
Как читать материалы:
- «Боль vs просьба: как правильно отличать» — основа темы: три уровня запроса и ловушки, из-за которых команда слышит просьбу. Возьмите оттуда разбор просьба → боль → работа.
- «Боль клиента как источник гипотезы» и «„Клиент всегда прав“: как буквальные запросы разрушают продукт» — короткие версии того же: четыре ловушки и семь шагов от словаря работ до exit-интервью.
- «Mom Test: интервью с клиентами, которым можно верить» — как спрашивать о прошлом опыте, а не об идее, и как проверить отчёт команды об интервью.
- «Как перестать проектировать для „среднего пользователя“» — карта эмпатии: кто на самом деле нажимает кнопку и что им движет.
- «Бесполезный JTBD — гипотезы, которые не выходят в рынок» — что происходит, когда боль найдена, но гипотеза тонет в документах и согласованиях; метрика времени до первого эксперимента.
Куда записать результат — в карточку входящего запроса из области «Вход».
