В двадцати интервью собеседники хвалили идею, а через полгода после запуска продуктом почти никто не пользуется. Записи разговоров при этом честные, люди действительно так говорили. Ошибка случилась раньше, в том, о чём их спрашивали и что команда решила засчитать в плюс.
Почему "Спроси маму" написана о самообмане, а не о технике интервью
Роб Фицпатрик выпустил "The Mom Test" в 2013 году, по-русски книга вышла как "Спроси маму". Название и есть главный тезис. Спросите маму, хороша ли ваша бизнес-идея, и она скажет "да", потому что любит вас. Хорошие вопросы устроены так, что соврать на них не сможет даже мама.
Книгу обычно читают как пособие по пользовательским интервью: как формулировать вопросы, как не сбить собеседника, как вытянуть полезное. Но техника здесь вторична. Настоящая тема книги: самообман, который почти всегда появляется в Customer Development. Глупость и нечестность тут ни при чём. Причина в обычном желании услышать, что идея хорошая, и перестать тревожиться. С этим желанием книга и работает.
Customer Development задуман как поиск правды о рынке. На деле он часто превращается в обряд, где гипотезы только подтверждают. Команда общается с пользователями, проводит интервью, аккуратно собирает "обратную связь". И идёт туда, куда собиралась с самого начала. Разговоры были искренними, а пользы ноль, потому что вопросы задавались не те.
Почему так выходит даже у честных людей? В разговоре люди стараются быть вежливыми. Собеседник не хочет грубить и расстраивать вас, а свои настоящие мотивы часто и сам понимает смутно. Команда в ответ слышит то, что ей приятно слышать. Получается круг взаимной вежливости, который выдаёт себя за исследование. Хуже того, Customer Development обычно подают как набор приёмов, хотя это привычка честно думать. Интервью можно провести по форме, ответы записать, выводы сделать и при этом спокойно пройти мимо всех неудобных сигналов.
Что метод даёт, а чего от него ждать не стоит
Сильнее всего подход в интервью о проблеме клиента. Он учит понимать сигналы и решать по тому, что люди делают, а не по тому, что они говорят. Отсюда и принципы: не обсуждать саму идею, спрашивать про прошлый опыт, разбирать реальные действия. Отдельный навык: различать слабые сигналы. Похвала, вежливый интерес, красивые рассуждения "в целом" не считаются подтверждением гипотезы, как бы ни хотелось засчитать их в плюс.
Границы стоит обозначить сразу. "Спроси маму" не закрывает весь Customer Development. Она не заменяет эксперименты, метрики, аналитику и тестирование решений. Это инструмент для самого начала, он помогает честно смотреть на данные. Улучшать им готовый продукт бесполезно. И правильных решений книга не гарантирует. Она снижает риск самообмана, но выбирать без полной уверенности всё равно придётся вам.
Кому это нужнее всего
Пользу метод приносит не всем одинаково. У каждой группы своя точка, где он выручает, и своя, где даёт сбой.
Первая группа: фаундеры и продакт-менеджеры, эмоционально сросшиеся с идеей. Чем сильнее вовлечённость, тем нужнее внешняя проверка. Метод пробуксовывает в тот день, когда человек решает, что про этот рынок он уже всё понял.
Вторая: команды, которые Customer Development вроде бы делали и всё равно получили провал MVP. Разбор почти всегда показывает одно и то же: интервью были, а выводы из них оказались ложными. Это неосознанный самообман в чистом виде. Правда, метод сильнее до запуска, чем после. Потраченного на MVP он не вернёт.
Третья: опытные команды в крупных компаниях, где есть и процессы, и исследования. В корпорации самообмана только больше, и книга возвращает разговор от внутренней политики к фактам. Ломается она там, где решение уже нужно защитить и согласовать. Тогда честный сигнал перебивают согласованием.
Обычно такой инструмент ищут в самом начале или после нескольких болезненных ошибок. Тогда становится ясно, что дело было не в исполнении: команда плохо понимала рынок.
Как это выглядит в работе
Всё начинается с честного признания: команда склонна толковать данные в свою пользу. С порядочностью это не связано, так устроен человек. Пока признания нет, любые техники применяются формально. Практически это значит выкинуть вопросы, которые приятно звучат и ничего не стоят: "что вы думаете об идее", "насколько вам это интересно". Такие вопросы почти гарантированно портят данные. Гипотезы на этом шаге пишут про проблему и обстоятельства, без готового решения внутри. Иначе команда просто пойдёт искать подтверждение своему продукту.
Дальше идут сами разговоры. Задача интервьюера: сделать так, чтобы собеседнику не хотелось просто быть вежливым. Не рассказывать про свою идею, не выпрашивать одобрения, не реагировать на ответы эмоционально. Вопросы разворачиваются в прошлое. Вместо "стали бы вы этим пользоваться" спрашивают "как вы решали это в прошлый раз". Так разговор уходит из зоны фантазий в зону фактов. Записывать нужно и слова, и действия. Человек уверяет, что проблема важна, но не может вспомнить ни одного случая? Это сильный сигнал, отмахиваться от него нельзя.
Чаще всего самообман пробирается на последнем шаге, при разборе. Помогает простое разделение фактов и выводов. Команда ищет то, что повторяется у разных людей: одно подтверждение, как и один энтузиаст, рынка не делает. Смотрят, какие проблемы люди действительно пытаются решить и какими средствами. И здесь же принимается решение о движении дальше: иногда это отказ от идеи. В такие моменты "Спроси маму" и оправдывает себя, останавливая дорогую ошибку.
Что остаётся на бумаге после разговоров
Первое: список гипотез о проблемах, в нейтральной формулировке и без зашитого внутрь решения, который регулярно пересматривают. Второе: заметки по интервью, где факты, прямые цитаты и ваши толкования записаны отдельно. Тогда к сырым данным можно вернуться позже и перечитать их на холодную голову. Третье: карта сигналов. На ней сильные признаки отделены от слабых, а реально потраченные время и деньги помечены иначе, чем слова поддержки. И, наконец, интервью полезно разбирать всей командой: коллективный взгляд гасит личные искажения.
Карту сигналов удобно свести в простой счёт. Вернёмся к двадцати интервью из начала и допустим, что они разложились так. Идею похвалили 17 человек. Конкретный случай с проблемой за последние три месяца вспомнили 6. Уже тратят деньги или часы на обходное решение 2. Команда, которая смотрит на 17 из 20, запускает продукт. Команда, которая смотрит на 2 из 20, сначала ищет, чем эти двое отличаются от остальных восемнадцати. Порог засчитывания пишут до первого разговора, например "не меньше 5 из 20 уже платят за обходной путь". Порог, придуманный после, почти всегда подстраивается под услышанное.
На чём обычно спотыкаются
Ошибок немного, и они предсказуемы. Вопрос, в который уже зашит желаемый ответ. Похвала, принятая за подтверждение. Противоречивые данные, которые тихо игнорируют. Разные сегменты, слепленные в один вывод. Заключение, сделанное после двух разговоров. Слова, истолкованные в отрыве от действий. Исследование, свёрнутое после первых "да". И подмена исследования защитой идеи, когда интервью проводят, чтобы обосновать уже принятое решение. Каждая из этих привычек кормит самообман и превращает Customer Development в формальность.
Плохой сценарий стоит узнавать сразу. Он начинается с идеи и желания доказать, что она ценная. Интервью превращается в презентацию, а вопросы подгоняют так, чтобы собеседник сказал что-нибудь приятное. Рядом живёт привычка отбрасывать неудобные ответы. Пользователь говорит, что проблема ему неважна, а его записывают в "не нашу аудиторию" и даже не проверяют это. И крайний случай, когда после интервью не меняется вообще ничего. Если данные не влияют на решения, значит Customer Development превратился в алиби.
Как переспросить, чтобы не услышать вежливую ложь
Опаснее всего вопросы, на которые приятно отвечать. Вот типичные формулировки, механизм их искажения и рабочая замена:
| Вопрос, который портит данные | Почему вводит в заблуждение | Как спросить иначе |
|---|---|---|
| "Нравится ли вам идея?" | провоцирует похвалу и вежливое согласие, а не факт | "Что вы уже пробовали, чтобы решить эту задачу?" |
| "Стали бы вы этим пользоваться?" | человек предсказывает будущее, а прогнозы о себе недостоверны | "Как вы решали это в последний раз?" |
| "Сколько бы вы заплатили за такое?" | гипотетическая цена ничего не стоит собеседнику | "Сколько вы уже тратите на решение этой проблемы сейчас?" |
| "Важна ли вам эта проблема?" | легко ответить "да" из вежливости | "Когда вы в последний раз сталкивались с ней и что сделали?" |
Правило под всей таблицей одно: засчитывать только то, что человек уже делал и на что уже тратил время или деньги.
Когда метод останавливает проект вовремя
Истории ниже обобщённые: без имён, с упрощёнными деталями. Одна команда делала сервис автоматизации задач и купалась в позитивных отзывах об идее. Потом провели интервью по принципам "Спроси маму" и стали расспрашивать, как люди на самом деле управляли задачами раньше. Картина перевернулась: люди уже как-то решают эту проблему и острой её не считают. Проект закрыли.
Во втором случае фаундер был уверен, что рынок готов к новому формату обучения. Он отказался обсуждать продукт и начал спрашивать о прошлых попытках учиться и о том, на что при этом тратились деньги. Выяснилось, что проблема не приоритетна. Инвестиций в ненужный MVP удалось избежать.
Порядок для следующей серии разговоров
Порядок простой, хотя дисциплины требует. Сначала признать риск самообмана и сформулировать гипотезы о проблемах, оставив решения на потом. Затем выбрать конкретную группу клиентов и найти в ней людей с реальным опытом. Первые согласившиеся для этого обычно не годятся.
В разговоре держать вопросы про прошлое, не реагировать эмоционально, записывать факты отдельно от трактовок и отдельно отмечать, что человек действительно делал. Одного интервью мало. Нужна серия, в которой ищут повторы, не смешивают разные группы клиентов и особо смотрят на потраченные время и деньги. Разговаривать лучше понемногу и регулярно, а не большим проектом раз в полгода. Тогда самообману негде накопиться. Серию останавливают, когда новые встречи перестают приносить новые факты. Продукт на них лучше не показывать вовсе: показанная идея давит на ответы сильнее любого вопроса. Данные полезно разбирать командой, гипотезы регулярно пересматривать, а похвалу без единого факта за спиной не засчитывать. И, наконец, принять неприятный вывод, если он есть, и честно решить, стоит ли продолжать.
Работу над продуктом такая дисциплина почти не тормозит: неделя разговоров обходится дешевле квартала разработки, которую потом придётся выбросить.
Похвала и "звучит полезно" спрос не подтверждают, сколько бы раз их ни повторили. Уточните, с какой задачей человек сталкивался и что предпринял, а ответ запишите отдельно от своей интерпретации. Если после серии разговоров вы не можете назвать ни одного случая, когда собеседник действительно сталкивался с проблемой и что-то предпринимал, вывод будет неприятным, но честным: подтверждения нет. Вовремя закрытая идея здесь считается хорошим исходом: ради этого метод и применяют. Самообман при этом распределён неравномерно: чаще всего он сидит в той гипотезе, которую команде страшнее всего проверять.