Карта болей — не то, что вы думаете. Как перестать собирать хотелки и начать видеть реальные проблемы

Команда собрала 47 болей. Реальных оказалось 6

B2B SaaS для логистических компаний. Команда из 4 человек провела 25 интервью за 3 месяца. Результат: таблица из 47 «болей клиентов». Каждая — по цитате из интервью. Команда гордится: «мы глубоко погрузились».

Проблема: из 47 пунктов 41 — это хотелки, а не боли. «Было бы здорово, если бы система сама формировала отчёты». «Хочется интеграцию с 1С». «Неплохо бы иметь мобильное приложение». Всё это — пожелания, за которые клиент не готов платить прямо сейчас.

Реальных болей — 6. Тех, за которые клиенты уже платят: временем (ручной ввод данных 4 часа в день), деньгами (штрафы за опоздания из-за неточного планирования), нервами (менеджер уволился, потому что устал от хаоса).

Боль vs хотелка vs job: точные определения

Термин	Определение	Индикатор	Пример
Боль (Pain)	Негативный опыт, за устранение которого клиент уже тратит ресурсы	Есть текущее решение-костыль, тратит время/деньги/нервы	«Каждый понедельник трачу 3 часа на ручную сверку заказов с Excel»
Хотелка (Wish)	Желание без поведенческого подтверждения	Нет текущего решения, не тратит ресурсы на проблему	«Было бы классно иметь AI-ассистента для планирования»
Работа (Job)	Задача, которую клиент пытается выполнить в конкретном контексте	Есть контекст, действие и желаемый результат	«Когда приходит 50+ заказов утром, хочу видеть оптимальные маршруты за 5 минут, чтобы водители выехали до 9:00»

Ключевое отличие: боль — это про прошлое и настоящее (клиент уже страдает). Хотелка — это про будущее (клиент мечтает). Job — это про действие (клиент пытается сделать).

Pain Map работает с болями и трансформирует их в работы. Хотелки — отфильтровываются.

3 индикатора реальной боли

Как отличить боль от хотелки в интервью? Три проверки:

1. Частота (Frequency)

Как часто клиент сталкивается с этой проблемой?

• Ежедневно — критическая боль (workflow-level)
• Еженедельно — значительная боль (operational-level)
• Ежемесячно — умеренная боль (может терпеть)
• Раз в квартал и реже — скорее всего не боль, а неудобство

2. Стоимость (Cost)

Сколько клиент уже тратит на эту проблему?

• Время: «4 часа в неделю на ручной ввод» = 200 часов/год = ~300 000 руб. зарплатных расходов
• Деньги: «Штрафы за опоздания — 150 000 руб./мес»
• Упущенная выгода: «Теряем 2-3 заказа в неделю из-за долгого ответа» = ~50 000 руб./неделю
• Нервы: «За полгода уволились 2 менеджера» = стоимость найма + онбординга

3. Эмоциональный заряд (Emotional charge)

Как клиент говорит о проблеме?

• Высокий заряд: «Меня бесит!», «Это кошмар», «Я ненавижу понедельники из-за этого» — реальная боль
• Нейтральный: «Ну, бывает неудобно иногда» — скорее хотелка
• Рационализация: «Да ладно, все так работают» — подавленная боль (может быть сильной, но клиент привык)

graph TD
  Q1{"Частота?"} -->|Ежедневно/Еженедельно| Q2{"Стоимость?"}
  Q1 -->|Раз в месяц и реже| WISH["Хотелка — отфильтровать"]
  Q2 -->|"> 50K руб/мес или > 10 ч/нед"| Q3{"Эмоциональный заряд?"}
  Q2 -->|Низкая / неизвестна| MED["Потенциальная боль — уточнить"]
  Q3 -->|Высокий| HIGH["🔴 HIGH severity"]
  Q3 -->|Средний| MED2["🟡 MED severity"]
  Q3 -->|Низкий| LOW["🟢 LOW severity"]

Методика: Pain → Job трансформация

Боль — это симптом. Job — это то, что клиент пытается сделать. Pain Map трансформирует одно в другое:

Боль (что болит)	Job (что пытается сделать)
«Трачу 3 часа на ручную сверку заказов»	«Когда приходят заказы из 3 каналов, хочу видеть единую сводку за 5 минут»
«Водители опаздывают, потому что маршруты неоптимальные»	«Когда утром 50+ заказов, хочу оптимальные маршруты за 5 минут до выезда»
«Клиенты жалуются, что не знают, где их посылка»	«Когда клиент звонит с вопросом, хочу за 10 секунд показать статус доставки»

Формат job statement: «Когда [контекст], я хочу [действие], чтобы [результат]». Контекст — из Product DNA (DP02 — триггерное событие). Действие — конкретное. Результат — измеримый.

Severity ranking: HIGH / MED / LOW

После трансформации pain → job каждая боль получает severity на основе 3 индикаторов:

Severity	Частота	Стоимость	Эмоция	Действие
HIGH	Ежедневно	> 100K руб/мес или > 20 ч/нед	Высокий заряд	Решать первым. Это ваш core value proposition.
MED	Еженедельно	20-100K руб/мес или 5-20 ч/нед	Средний заряд	Включить в MVP. Усиливает Pull.
LOW	Ежемесячно	< 20K руб/мес или < 5 ч/нед	Низкий заряд	Backlog. Не тратить ресурсы сейчас.

Пример: B2B SaaS для логистики — от 12 болей к 2 core jobs

Вернёмся к нашему примеру. Из 47 «болей» отфильтровали хотелки (41 штуку). Осталось 6 реальных. Вот процесс ранжирования:

#	Боль	Частота	Стоимость	Эмоция	Severity
1	Ручная сверка заказов из 3 каналов	Ежедневно	200 ч/год, ~300K руб	Высокая	HIGH
2	Неоптимальные маршруты → опоздания	Ежедневно	150K руб/мес штрафы	Высокая	HIGH
3	Клиенты не знают статус доставки	Ежедневно	2-3 потерянных клиента/нед	Средняя	MED
4	Нет отчётности по водителям	Еженедельно	40K руб/мес (переработки)	Средняя	MED
5	Сложно масштабировать на новые города	Ежеквартально	Высокая, но редкая	Низкая	LOW
6	Интеграция с бухгалтерией вручную	Ежемесячно	20 ч/мес	Низкая	LOW

Результат: 2 боли HIGH severity → 2 core jobs:

1. «Когда приходят заказы из 3 каналов (сайт, телефон, Telegram), хочу видеть единую сводку за 5 минут, чтобы диспетчер не тратил 3 часа на сверку»
2. «Когда утром 50+ заказов, хочу получить оптимальные маршруты за 5 минут, чтобы водители выехали до 9:00 и не было штрафов за опоздания»

Это — core value proposition. Всё остальное — secondary. Одна таблица из 6 строк заменила 47 строк «фидбека» и дала чёткий фокус: автоматическая сверка + оптимизация маршрутов.

Ошибка: плоский список без ранжирования

«У нас 47 болей клиентов. Все важные.»

Когда «всё важно» — ничего не важно. Плоский список без severity создаёт 3 проблемы:

1. Паралич приоритизации — команда не знает, за что браться. Решают голосованием или мнением самого громкого.
2. Feature creep — пытаются решить все 47 болей в MVP. Релиз затягивается на год.
3. Ложная уверенность — «мы знаем все боли клиентов». На деле знают 6 реальных и 41 хотелку вперемешку.

Pain Map с severity-ранжированием решает все три: HIGH — делаем первым, MED — включаем в MVP, LOW — в бэклог.

Как AI CPO строит Pain Map из диалога

В AI CPO вы описываете проблемы клиентов в чате — как обычным языком, так и цитатами из интервью. Система автоматически:

1. Извлекает боли из текста (отделяя от хотелок)
2. Определяет severity по 3 индикаторам
3. Трансформирует pain → job statement в Product DNA-формате
4. Группирует работы по иерархии (core → small → micro)

Результат — структурированная Pain Map с ранжированием, а не «куча стикеров на Miro».

Попробуйте рассказать AI CPO о проблемах ваших клиентов — система отделит реальные боли от хотелок и покажет severity. Попробовать бесплатно →

Pain Map и другие артефакты

Pain Map — не изолированный документ. Он связан с другими артефактами через Product DNA:

• Pain Map → Job Statements — каждая боль HIGH/MED трансформируется в формулировку работы
• Pain Map → ABCDX-сегменты — кластеры клиентов с похожими наборами болей = сегмент
• Pain Map → Positioning — HIGH-severity боль A-сегмента = основа позиционирования
• Pain Map → Feature Priority — severity прямо определяет приоритет фич

Упражнение: аудит вашего списка болей

Возьмите текущий список «болей клиентов» (из Miro, Notion, Google Docs — неважно). Для каждой строки ответьте:

1. Частота? Клиент сталкивается ежедневно, еженедельно, ежемесячно, реже?
2. Стоимость? Сколько это стоит в часах/рублях прямо сейчас?
3. Эмоция? Как клиент говорит об этом — с болью или нейтрально?
4. Есть костыль? Клиент уже решает эту проблему каким-то способом (пусть плохим)?

Если на вопросы 1-3 ответ «не знаю» — это не боль. Это предположение, которое нужно проверить.

Следующие шаги

Pain Map — это входная точка в product discovery. Дальше:

1. HIGH-severity боли → core job statements → value proposition
2. Сегменты по наборам болей → ABCDX
3. Balance of forces → Switch Formula

Сгенерируйте Pain Map с ранжированием severity для вашего продукта → aicpo.ru