Как ищешь суть проблемы которая лежит в основе поведения или жалоб пользователей?

Как найти суть проблемы в основе поведения пользователей

Это, пожалуй, самый важный навык PM — поиск истинной причины. Люди часто говорят на поверхностном уровне, но проблема глубже. Вот мой систематический подход основанный на years практики и техниках как "Five Whys" и "Root Cause Analysis".

Принцип: Surface vs Root Cause

Что видим на поверхности:

• Пользователь не заполняет профиль
• Клиент отменяет заказ в последний момент
• Сотрудник жалуется что система медленная
• Пользователи не возвращаются на сайт

Что может быть истинной причиной:

• Не понимает зачем нужен профиль
• Обманувается в цене (скрытые платежи)
• Раньше не использовал подобные системы
• Они нашли конкурента с лучше UX

Я должен копать глубже и найти корень.

Методология: Five Whys

Это классический подход от Toyota Production System. Спрашиваю "Why?" пять раз:

Пример 1: Пользователи не используют new feature

Повер-юзер: "Я не использую функцию Reports"

ПМ (1st Why): "Почему?"
Пользователь: "Потому что это не помогает мне"

ПМ (2nd Why): "Почему это не помогает?"
Пользователь: "Я не понимаю что там внутри"

ПМ (3rd Why): "Почему ты не понял?"
Пользователь: "Когда я нажимаю на Reports, я не знаю что будет"

ПМ (4th Why): "Почему нет подсказки?"
Пользователь: "Нет иконки, нет описания, это выглядит как просто ещё одна кнопка"

ПМ (5th Why): "Почему это не выделяется как новое?"
Пользователь: "У вас нет badge "New" или описания что это делает"

═══════════════════════════════════
ROOT CAUSE: Плохой onboarding для новой фичи, недостаточная визуальная иерархия

НЕ ошибка в самой фиче, а в том как мы её представили!

Пример 2: Клиент отменяет заказ

Лад: "Много клиентов отменяют заказы после оплаты"

ПМ (1st Why): "Почему они отменяют?"
Лад: "Говорят что не ожидали такой цены"

ПМ (2nd Why): "Но цена же указана перед оплатой?"
Лад: "Да, но они говорят что видели другую цену ранее"

ПМ (3rd Why): "Это странно, как они видели другую цену?"
Лад: "Я спросил клиента. Он показал скриншот из Google Ads где была цена ниже"

ПМ (4th Why): "Значит цена в Ads не совпадает с реальной?"
Лад: "Да, Ads показывает $50 а checkout показывает $65"

ПМ (5th Why): "Почему такая разница?"
Лад: "В checkout добавляются комиссии, доставка и налоги"

═══════════════════════════════════
ROOT CAUSE: Несоответствие между ценой в маркетинге и реальной ценой в checkout.

РЕШЕНИЕ: Показать все сборы уже в Ads, или изменить checkout чтобы показать breakdown раньше

Техника: Hole Digging vs Ladder Climbing

Есть два подхода:

1. Hole Digging (Копание вглубь) Спрашиваю всё глубже и глубже про ОДНу проблему:

- Почему не используют фичу?
- Почему не понимают?
- Почему нет подсказки?
- Почему плохой UX?
- Какой именно UX проблема?

2. Ladder Climbing (Лазание по лестнице) Спрашиваю всё выше и выше:

- Пользователь не использует фичу
- Почему? Плохой UX
- Связано ли это с general strategy?
- Может быть нам нужен другой approach к onboarding?
- Нужно ли переделать весь flow?

Я использую оба метода в зависимости от ситуации.

Методология: SCAMPER анализ

Для более комплексного понимания проблемы, задаю себе вопросы:

S - Substitute: Что можно заменить?
   "Может быть вместо text description использовать video?"

C - Combine: Что можно объединить?
   "Может быть объединить onboarding с first time user experience?"

A - Adapt: Что можно адаптировать из других продуктов?
   "Как Netflix объясняет новые фичи? Может быть нам копировать их подход?"

M - Modify: Что можно изменить?
   "Может быть сделать кнопку большей и с другим цветом?"

P - Put to another use: Как использовать по-другому?
   "Может быть эта фича нужна не для основного сценария, а для power users?"

E - Eliminate: Что можно убрать?
   "Может быть фича слишком сложная и нужно убрать 50% функционала?"

R - Reverse: Как это работает наоборот?
   "Вместо того чтобы показывать Reports автоматически, может быть сделать opt-in?"

Техника: Обратные вопросы (Socratic Method)

Я часто задаю обратные вопросы:

Узер: "Ваша система очень медленная"

НЕ ЭТО:
ПМ: "Нет, она быстрая, у вас интернет плохой" ❌

А ЭТО:
ПМ: "Спасибо за feedback. Помни когда ты в последний раз заметил что система медленная?"
Узер: "Вчера когда я загружал документы"

ПМ: "А сколько документов?"
Узер: "Штук 500"

ПМ: "А это нормальное для тебя количество?"
Узер: "Да, я часто загружаю bulk"

ПМ: "Понял. Может быть проблема в том что мы не оптимизировали bulk upload?"
Узер: "Да, может быть. Когда я загружаю по одному быстрее"

═══════════════════════════════════
ROOT CAUSE: Не медленная система в целом, а именно bulk upload медленный

НЕ НУЖНО: Переделывать весь backend
НУЖНО: Оптимизировать именно bulk upload feature

Методология: Job to be Done (JTBD)

В основе поведения пользователя есть работа которую он пытается выполнить:

Отуда шум, что мобильное приложение не используют.

ПМ: "Для какой работы ты используешь наш продукт?"
Узер: "Я использую это на компьютере когда я в офисе"

ПМ: "А почему не на мобильном?"
Узер: "Потому что мне нужно вводить данные, а на телефоне это неудобно"

ПМ: "А какая работа ты пытаешься делать на мобильном?"
Узер: "Я хочу проверить статус когда я в пути"

═══════════════════════════════════
JOB: "Проверить статус в пути"

НЕ НУЖНО: Полный функционал мобильного приложения
НУЖНО: Быстрый view status без ввода данных

Практический процесс: Как я это делаю

Шаг 1: Собираю жалобы/feedback

- Support tickets
- In-app feedback
- User reviews
- Behavior analytics (что делают люди)
- NPS comments

Шаг 2: Ищу паттерны

Жалоба 1: "Система медленная"
Жалоба 2: "Не могу загрузить файл быстро"
Жалоба 3: "Upload takes forever"
Жалоба 4: "Why is bulk import so slow?"

Паттерн: Это не "система медленная", это "UPLOAD медленный"

Шаг 3: Глубокие интервью Выбираю 5-10 пользователей и проводу 30-мин интервью:

1. "Расскажи мне о твоём опыте с нашим продуктом"
2. "Когда ты в последний раз столкнулся с проблемой?"
3. "Расскажи подробно что произошло"
4. (Five Whys)
5. "Это влияет на какую часть твоей работы?"
6. "Как ты сейчас справляешься с этой проблемой?"

Шаг 4: Анализ данных

Я смотрю на analytics:
- Какой % пользователей используют upload?
- Сколько времени они тратят?
- На каком этапе они drop-off?
- Используют ли они снова или только один раз?

Это помогает понять масштаб проблемы

Шаг 5: Гипотеза root cause

На основе всей информации я формулирую:

ROOT CAUSE: Upload slow для bulk operations (100+) файлов

WHY: Мы не используем parallel uploads, не оптимизировали backend

IMPACT: 15% пользователей это делают, теряем 20% из них

Инструменты которые я использую

Качественные:

• Интервью (UserTesting, Respondent)
• Customer visits
• Surveys с открытыми вопросами
• Support chat анализ

Количественные:

• Heatmaps (Hotjar)
• Session recording (FullStory, LogRocket)
• Funnel analysis (Amplitude, Mixpanel)
• User cohort analysis
• Behavior analytics

Частые ошибки

❌ Верить первому объяснению пользователя

• Пользователи часто не знают истинную причину
• Они дают симптомы, а не причину

❌ Спрашивать leading questions

• "Правда ли что interface сложный?" (наводящий)
• "Что было сложного?" (открытый)

❌ Интервьюировать только очень активных users

• Нужно говорить с людьми которые БРОСИЛИ
• Они часто дают лучше инсайты

❌ Останавливаться на первой причине

• Часто нужно копать еще глубже
• "Медленно" → "Upload медленный" → "Параллельные запросы не используются"

❌ Решать проблему до понимания

• Разработчик уже начал писать код
• А мы потом понимаем что это не правильная проблема

Резюме

Поиск root cause — это искусство и наука:

1. Техники: Five Whys, SCAMPER, JTBD
2. Процесс: Collect feedback → Find patterns → Deep interviews → Data analysis → Hypothesis
3. Mindset: Curiosity, Skepticism, Empathy
4. Важно: Говорить с реальными пользователями, не делать assumptions

Когда я понимаю настоящую причину, решение часто становится очевидным. А когда я решаю не ту проблему, я трачу много времени впустую.

Это умение — различие между хорошим PM и отличным PM.