Боль vs просьба: как правильно отличать

Клиент на созвоне говорит: «Нам бы интеграцию с Salesforce». Продакт записывает. Дизайнер рисует. Разработчик пилит два спринта. Интеграция выходит. Клиент не пользуется. Не потому что сделали плохо. А потому что решили не ту задачу. Клиенту не нужна была интеграция - он видел это как инструмент решения, ключевая проблема, что он терял по 3ч в неделю на перенос данных из одной системы в другую. Решение могли быть в 3 раза проще: выгрузить в CSV по расписанию ему на почту в 10:00. Или вовсе - уведомление, что нужно обновить данные до отчета с руководством.

Это самая частая точка провала команд. Команда не отличает инструмент от проблемы, воспринимает видение клиента как свою задачу и придумывает космолеты там где нужен фантик от конфеты. Вместо того чтобы понять: зачем именно так клиент делает, что у него болит здесь и сейчас?

Просьба, боль и работа: три уровня клиентского запроса

Прежде чем разбирать ловушки, нужно развести три понятия.

Просьба - это то, что клиент произносит вслух. Конкретная функция, решение, форма. «Добавьте дашборд». «Нам нужен API». «Сделайте мобильную версию». Просьба — поверхностный уровень. Она говорит о том, что клиент уже придумал за вас.
Боль — это то, почему просьба возникла. Что мешает, что тормозит, что раздражает. Боль на один уровень глубже: «Я трачу полдня на ручную выгрузку отчётов для руководства» или «Я не вижу, что происходит с проектом, пока не спрошу у трёх человек».
Работа (в терминах Jobs-to-be-Done -, рамка, которая описывает, для какой задачи клиент «нанимает» продукт) — это то, что клиент пытается достичь в итоге. Корневой уровень. Не «хочу дашборд», не «трачу время на отчёты», а «мне нужно за пять минут понять статус проекта и принять решение — эскалировать или нет».

Вот как это выглядит на конкретных B2B-примерах:

Просьба (что говорит)	Боль (почему говорит)	Работа (что пытается сделать)
«Добавьте интеграцию с CRM»	Ручной перенос данных отнимает 3 часа в неделю	Быстро видеть актуальные данные о клиенте при принятии решений
«Нам нужен дашборд»	Руководство запрашивает статус — каждый раз собираю вручную	За 5 минут дать руководству картину проекта без ручной работы
«Сделайте экспорт в Excel»	Аналитик не может работать с данными в вашем интерфейсе	Анализировать данные в привычных инструментах без потери контекста
«Нужен API»	Команда автоматизирует процессы, а ваш продукт — ручное узкое место	Встроить ваш продукт в автоматизированный pipeline без ручных шагов

Когда вы работаете на уровне просьбы — вы исполнитель. Когда на уровне боли — вы решаете реальную проблему. Когда на уровне JTBD — вы строите продукт, который клиент не сможет заменить.

Ловушка 01. Клиент приходит с готовым решением

Интуитивное действие:** принять запрос как техзадание и отправить в бэклог. Клиенты в B2B — это профессионалы своей индустрии. Они сами думали о проблеме, обсуждали её внутри команды, возможно даже писали ТЗ для своего IT-отдела. К моменту, когда они приходят к вам, решение в их голове уже оформлено. Они не описывают боль — они предлагают конструкцию.

Механика: клиент подсознательно фильтрует свой опыт через знакомые паттерны. Если он видел, как конкурент сделал X — он попросит X. Не потому что X — лучшее решение его проблемы, а потому что X — единственное решение, которое он видел.

Метрика: процент реализованных фич с adoption rate ниже 20% за первый месяц. Если вы построили то, что просили, а этим не пользуются — вы решили просьбу, а не боль.

Пример: B2B SaaS для управления проектами получила от трёх крупных клиентов запрос на «диаграмму Ганта с зависимостями». Потратили квартал на реализацию. Через два месяца после запуска фичу использовали 4% пользователей. Настоящая боль была не в отсутствии Ганта — менеджеры проектов не могли быстро увидеть, какие задачи блокируют другие. Простое визуальное выделение блокеров в существующем списке задач решало проблему за две недели разработки.

Ловушка 02. Боль настолько привычна, что клиент её не замечает

Интуитивное действие: если клиент не жалуется — проблемы нет.

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

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

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

Пример: SaaS для HR-команд обнаружил, что клиенты тратили в среднем 40 минут в неделю на ручное обновление статусов кандидатов в двух системах параллельно. Ни один клиент не упомянул это как проблему на интервью. Обнаружилось только когда продакт попросил показать процесс от начала до конца — не рассказать, а именно показать на экране.

Большинство PM приходят на интервью с вопросом «что бы вы хотели улучшить?» — и получают ответ о косметических неудобствах. Настоящие боли прячутся в том, что клиент уже считает нормой

Ловушка 03. Клиент хочет выглядеть конструктивно

Интуитивное действие: радоваться, что клиент «помогает» формулировать решение.

В B2B-контексте ваш собеседник - часто менеджер среднего или старшего звена. У него есть репутация. Ему неловко просто жаловаться - он хочет прийти с готовым предложением. «У нас проблема с X, и мы думаем, что если вы сделаете Y — это решит вопрос».

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

Метрика: в записях интервью посчитайте соотношение «клиент описывает проблему» vs «клиент описывает решение». Если больше 70% разговора - про решения, вы не добрались до боли.

Фаундеры часто путают конструктивного клиента с информированного. Клиент, который говорит «добавьте webhook» — конструктивен. Но это не значит, что webhook — правильный ответ на его задачу именно в вашем сервисе

Ловушка 04. Общий знаменатель на уровне функций, а не проблем

Интуитивное действие: собрать запросы от пяти клиентов, найти пересечение, поставить в roadmap.

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

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

Метрика: после запуска фичи посмотрите на сегментацию использования. Если фичу активно используют только 1–2 клиента из тех, кто просил — вы нашли общий знаменатель не на том уровне.

Пример: финтех для SMB получил от двенадцати клиентов запрос на «мультивалютность». Построили. Пользуются трое. Девять остальных имели в виду не мультивалютные операции, а возможность видеть расходы в своей локальной валюте — что решалось простым пересчётом на уровне UI-интерфейса.

«Мы провели 15 интервью и услышали одно слово — "отчётность". Только на шестнадцатом поняли, что под этим словом скрываются три совершенно разных задачи» — паттерн, который повторяется в каждом втором B2B-продукте.

Три техники, чтобы добраться до боли

Теперь — как с этим работать. Три техники, которые переводят разговор с поверхности на глубину.

Техника 01. «Пять почему»

Метод, популяризированный Toyota для анализа производственных дефектов, но отлично работающий в продуктовых интервью. Суть: на каждый ответ клиента задавайте «почему?» — до тех пор, пока не доберётесь до корневой причины.

Пример в B2B: — Нам нужна интеграция с Jira. — Почему? — Потому что наши разработчики работают в Jira, а задачи от клиентов приходят к нам. — Почему это проблема? — Потому что я вручную переношу задачи из нашей системы в Jira. — Почему вы делаете это вручную? — Потому что нет другого способа. — Почему это важно решить именно сейчас? — Потому что команда выросла с 5 до 20 человек, и я трачу на это уже 6 часов в неделю.

Боль: 6 часов в неделю ручного труда, который масштабируется линейно с ростом команды. Это не про Jira — это про ручное узкое место в процессе.

Критерий успеха: вы дошли до конкретной цифры (время, деньги, частота) или до конкретного последствия (упущенные сделки, задержки, отток).

Техника 02. «Расскажите мне о последнем разе, когда...»

Гипотетические вопросы («Вы бы использовали такую функцию?») дают гипотетические ответы. Поведенческие вопросы о конкретных прошлых ситуациях дают факты. Эту технику описывает Роб Фитцпатрик в «The Mom Test» — книге о том, как разговаривать с клиентами так, чтобы они не могли вам солгать (даже из вежливости).

Пример:

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

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

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

Техника 03. «Что происходит, если вы этого не делаете?»

Цена бездействия — самый честный индикатор реальности боли. Если клиент говорит «нам нужен X» — спросите, что случится, если X не будет. Если ответ «ну, ничего страшного, просто неудобно» — перед вами не боль, а пожелание. Если «мы теряем клиентов» или «мы получаем штрафы» — это боль с ценой.

Пример:

— Нам нужна автоматизация onboarding-процесса. — Что происходит сейчас, если вы этого не делаете? — Каждый новый клиент требует 4 часа ручной настройки от нашего Customer Success. — А если клиентов станет вдвое больше? — Нам придётся нанять ещё двух CS-менеджеров, это $120 000 в год.

Теперь у вас есть не просто запрос — у вас есть цена проблемы: $120 000 в год. Это число, которое определяет и приоритет фичи, и ценовую модель вашего решения.

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

Как записывать боли для последующей гипотезы

Услышать боль — половина дела. Вторая половина — записать её так, чтобы через неделю вы могли превратить запись в гипотезу, а через месяц — в текст лендинга.

Шаблон записи:

Контекст: Кто этот человек, какая роль, размер компании, стадия. Триггер: Что запускает проблему — событие, ситуация, периодичность. Боль (в словах клиента): Дословная цитата или максимально близкая к ней формулировка. Последствие: Что происходит, если боль не решена — в конкретных числах. Текущий способ справляться: Как клиент решает проблему сейчас (workaround).

Пример заполненной записи:

Контекст: Head of Sales, B2B SaaS, 50 человек в компании, серия A. Триггер: Каждый понедельник нужно обновить pipeline для weekly standup с CEO. Боль: «Я трачу утро понедельника на то, чтобы свести данные из CRM, таблиц и Slack — вместо того чтобы продавать». Последствие: ~4 часа в неделю, плюс данные часто неточные, что приводит к неверным прогнозам. Текущий workaround: Ручная сводка в Google Sheets + просьба к каждому менеджеру обновить свои сделки до воскресенья.

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

Красные флаги: вы услышали просьбу, а не боль

Быстрый чек-лист для самопроверки после интервью:

01 Клиент назвал конкретное решение или фичу. Если в ваших записях стоит «клиенту нужен дашборд» — вы записали просьбу. Вернитесь к записи и задайте себе вопрос: зачем ему дашборд? Что он не может сделать без дашборда?
02 Вы не можете ответить на вопрос «почему это важно для него». Если единственный ответ — «ну, так удобнее» — вы на поверхности. Боль бизнеса всегда отражена в деньгах, боль исполнителей во времени, боль клиента в сервисе
03 Разные клиенты говорят разное, но вы находите общий знаменатель на уровне функций. «Все хотят отчётность» — это агрегация просьб. Попробуйте агрегировать боли: «Трое из пяти не могут быстро принять решение, потому что данные разрознены». Это совершенно другой контекст для просьбы и инструмента. Совершенно разные контекст применения - это сотни часов работы программистов.
04 Вы можете переформулировать запрос как задачу для разработчика, но не как проблему клиента. «Сделать API для выгрузки данных» — задача, которая не относится к продукту. «Клиент не может встроить наш продукт в свою IT экосистему через своих разработчиков» — проблема. Если у вас в бэклоге задачи, но нет проблем — вы работаете проектным руководителем и занимаетесь проектом, а не продуктовым решением.
05 После интервью у вас нет ни одной цифры. Ни времени, ни денег, ни частоты. Боль без цифры — это ощущение. Ощущения не помогают приоритизировать.

Что происходит на рынке

Стоимость ошибки на этапе «услышать клиента» выросла. Раньше команда могла позволить себе пару холостых спринтов — итерации были дешёвыми. Сегодня, когда burn rate B2B-стартапов на серии A доходит до $150–200K в месяц, два потраченных месяца на решение не той проблемы — это $300–400K прямых потерь. Плюс упущенное время: конкурент, который правильно определил боль, за эти два месяца уже тестирует решение.

В B2B SaaS добавляется ещё один фактор: клиенты стали более избирательными. Средний B2B-покупатель рассматривает 4–6 альтернатив перед покупкой. Если ваш продукт говорит на языке функций («у нас есть дашборд, интеграции и API»), а конкурент — на языке боли («мы избавляем вашу команду от 6 часов ручной работы в неделю»), решение принимается не в вашу пользу.

Как делать правильно: 7 шагов от запроса к гипотезе

Начните интервью с контекста, а не с продукта. Первые пять минут — про клиента: чем занимается, как устроен процесс, что изменилось за последний квартал. Никаких вопросов о вашем продукте на этом этапе. Критерий: вы понимаете рабочий день клиента лучше, чем до начала разговора.
Когда клиент называет решение — задайте «почему». Не один раз, а до тех пор, пока не дойдёте до конкретной ситуации с измеримым последствием. Три-четыре «почему» обычно достаточно. Критерий: в записи есть конкретная цифра — время, деньги или частота.
Переведите разговор в прошлое. «Расскажите о последнем разе» — ваш главный инструмент. Конкретная ситуация ценнее десяти обобщений. Критерий: клиент рассказывает историю с деталями, а не отвечает «обычно мы...».
Проверьте цену бездействия. «Что будет, если это не решить?» — вопрос, который отделяет боль от пожелания. Критерий: последствие бездействия конкретное и значимое для бизнеса клиента.
Запишите боль по шаблону сразу после интервью. Контекст → Триггер → Боль (в словах клиента) → Последствие → Текущий workaround. Не откладывайте — через день вы потеряете детали. Критерий: запись понятна человеку, который не был на интервью.
Агрегируйте на уровне болей, а не функций. После пяти интервью посмотрите на записи и ищите паттерны не в том, что клиенты просят, а в том, от чего они страдают. Критерий: вы можете сформулировать боль одним предложением, и три из пяти респондентов кивнут.
Сформулируйте гипотезу от боли, а не от решения. Не «если мы сделаем дашборд — конверсия вырастет», а «менеджеры тратят 4 часа в неделю на сбор данных для отчётов — если мы автоматизируем сборку, они будут использовать это как основной инструмент». Критерий: в гипотезе есть боль, сегмент и поведенческий предикт — а не описание фичи.

Литература и источники

Rob Fitzpatrick, «The Mom Test» — фундаментальная книга о том, как разговаривать с клиентами. Объясняет, почему люди врут на интервью (не из злости — из вежливости) и как строить вопросы, на которые невозможно дать социально желательный ответ. Берите оттуда: конкретные формулировки вопросов и принцип «спрашивай о прошлом поведении, а не о будущих намерениях».
Clayton Christensen, «Competing Against Luck» — книга, которая развивает теорию Jobs-to-be-Done. Главная идея: клиент «нанимает» продукт для выполнения конкретной работы в своей жизни. Берите оттуда: рамку для анализа «работы» клиента, которая позволяет выйти за пределы функциональных запросов.
Cindy Alvarez, «Lean Customer Development» — практическое руководство по проведению custdev-интервью в условиях ограниченного времени. Особенно полезно для B2B-контекста: как рекрутировать корпоративных респондентов, как структурировать 30-минутный разговор, как обрабатывать результаты. Берите оттуда: шаблоны интервью и процесс синтеза.
Teresa Torres, «Continuous Discovery Habits» — о том, как встроить разговоры с клиентами в еженедельный ритм команды. Не один раз в квартал «проводим исследование», а каждую неделю — два-три разговора. Берите оттуда: технику Opportunity Solution Tree, которая связывает боли клиентов с конкретными экспериментами.
Ash Maurya, «Running Lean» — как переходить от наблюдений к формулировке гипотез. Полезен для шага «от боли к гипотезе»: объясняет структуру Lean Canvas и как заполнять блок Problem на основе реальных интервью. Берите оттуда: критерии отсечения «топ-3 проблемы» и принцип приоритизации по болезненности.

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