Escaping the Build Trap, глава 17: Исследование проблемы

Главная мысль: сначала найдите настоящую проблему и её причину. Без этого любое решение — угадывание.

Кейс Marquetly: Kata для опции

Christa провела команду по вопросам Product Kata:

Вопрос	Ответ команды
Какая цель?	Доля опубликованных курсов 50%, доля вторых курсов 30%
Где мы сейчас?	Публикуется 25% начатых курсов. Вторых курсов 10%
Главное препятствие?	Мы мало знаем о проблемах преподавателей
Следующий шаг?	Исследование: 20 часовых сессий, смотрим, как преподаватели создают курс

Что узнали на сессиях:

Портал для преподавателей проектировал разработчик. UX-дизайнеров в компании раньше не было.
У многих курсы уже есть в других системах. Их хотят перенести.
Контент делают вне системы. В систему его хотят просто быстро загрузить.

Christa записала проблемы в формате «Когда я …, я хочу …, чтобы …». Например:

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

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

Говорите с людьми

Продакт-менеджер — «голос клиента». Но многие с клиентами почти не говорят.
Причина простая: организовать интервью трудно. Проще сразу запустить A/B-тест или смотреть данные.
Анализ данных важен. Но он не рассказывает всю историю.
Инструменты: интервью, наблюдение, опросы, обратная связь клиентов.

Два вида исследований:

Вид	Цель	Пример
Evaluative	Проверить, удобно ли пользоваться решением	Usability-тест прототипа
Generative	Найти проблему и её корень	Наблюдение и вопрос «Что больше всего мешает закончить курс?»

На этой фазе нужен generative research.

Проблема — это не отсутствие фичи

Типичный разговор автора с компаниями:

«Какую проблему вы решаете?» — «У пользователей нет кастомных дашбордов».
«Какое решение?» — «Кастомные дашборды».

Когда спросили «зачем им дашборды», вышло три разные задачи:

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

Для 1 и 3 нужен интерфейс выбора метрик с динамикой.
Для 2 нужна настраиваемая отчётность для начальника.
Если у клиента только задача 2, часть работы можно не делать.

Не влюбляйтесь в решение

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

Кейс: пользователям не нужно приложение

Сообщество женщин в бизнесе хотело новое приложение. Прошлое приложение много скачивали, и компания ждала того же.

Идея: интерфейс как в Tinder, чтобы находить бизнес-ментора.
Гипотеза: женщины готовы быстро знакомиться с незнакомыми менторами в своём городе.
Эту гипотезу проверили интервью. Реакция была резко негативной.
Причина: с ментором обсуждают личные детали работы. Нужно что-то общее. Менторов находили по рекомендациям: знакомые, выпускники вуза, коллеги, митапы.

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

Когда к клиентам не пускают

Часто мешает бюрократия. Ищите обход.
Крис Маттс поднимался по цепочке до человека, который «запретил» общаться с клиентами. Оказалось, запрета не было — нужно было заполнить форму.
Немного информации лучше, чем ничего.
B2C: друзья друзей, которые пользуются продуктом.
B2B: попросите отдел продаж задавать ваши вопросы на встречах с клиентами.
Marquetly не могла связаться с ушедшими посетителями. Поэтому поставила опрос Qualaroo.

Ещё одна ловушка: клиенты сразу предлагают решение («мне нужна кнопка»). Спрашивайте «зачем?». Решать проблему — не работа клиента. Ваша работа — задать правильные вопросы.

Валидация проблемы

Christa предложила автоматизировать создание курса. Rich сомневался: курсы разные, формат не стандартный. Чтобы не спорить, команда снова прошла Kata. Следующее, что нужно узнать: что именно в загрузке занимает время и нужен ли преподавателям шаблон.

Эксперимент:

Написали 20 преподавателям, которые начали новый курс. 10 сказали, что им трудно загружать контент.
5 согласились: команда сама загрузит их курс. Две недели, любой формат.
Пришли ссылки Dropbox, Google Docs, таблицы, YouTube. Видео пришли без монтажа, с инструкциями, аудио отдельно.

Что поняли:

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

Портал всё равно надо переделать. Но главная проблема другая.

Ключевые термины

Термин	Значение
`generative research`	Исследование, чтобы найти проблему и её корень
`evaluative research`	Исследование, чтобы проверить готовое решение (usability)
`root cause`	Первопричина проблемы
`problem statement`	Проблема в формате «Когда я …, я хочу …, чтобы …»
`user journey`	Путь пользователя по шагам, с плохими местами
`problem validation`	Проверка, что найденная проблема настоящая и массовая

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

Запрос «нужен дашборд» — это решение, а не проблема. Спросите, какое решение человек примет по этому дашборду. Пример из главы показывает: за одной просьбой могут быть три разные задачи и три разных продукта.
Данные показывают «что», а не «почему». Метрика Marquetly «75% курсов не публикуются» дала направление. Причину нашли только на интервью. Не ждите, что одна витрина объяснит отток.
Первая гипотеза может быть неверной даже с данными. Команда была уверена, что проблема в загрузке. Это опровергли за две недели ручной работы. Перед тем как строить сложный пайплайн, сделайте ручную версию для 5 пользователей: выгрузку, таблицу, разовый отчёт.
Ходите на встречи с пользователями данных. Посмотрите, как аналитик или менеджер работает с вашей витриной. Часто данные выгружают в Excel и доделывают руками. Это и есть настоящая проблема.
Когда пользователь просит колонку или фильтр, спросите «зачем». Так вы найдёте общую задачу и не сделаете десять похожих отчётов.

Вопросы для самопроверки

Чем generative research отличается от evaluative? Какой нужен на фазе исследования проблемы?
Почему «у пользователей нет дашбордов» — плохая формулировка проблемы?
Как найти клиентов для разговора, если доступ закрыт?
Как ручной эксперимент Marquetly изменил понимание проблемы?

Предыдущая: 16. Направление и метрики успеха. Следующая: 18. Исследование решений.