Большая часть предзапускных пользовательских исследований — театр, и хуже всего то, что обе стороны знают свои реплики наизусть. Вы спрашиваете «стали бы вы пользоваться чем-то подобным», и человек по ту сторону звонка — который вежлив, которому ничего не грозит, который представляет продукт, которого не существует — отвечает «да». Вы записываете это как подтверждение. Это не подтверждение. Это незнакомец, вежливо отвечающий на гипотетический вопрос.
Раньше я проводил такие интервью религиозно, потому что так учит каждая книга по продуктовой стратегии. Поговорите с пятьюдесятью пользователями, прежде чем написать хоть строчку кода. Найдите боль. Проверьте проблему, прежде чем решение. Звучит дисциплинированно и хорошо смотрится на доске. Но реальный результат десяти ознакомительных звонков — это десять человек, говорящих вам то, что, по их мнению, вы хотите услышать, пропущенное через их собственную смутную память о проблеме, о которой они не думали с начала звонка. Никто не лжёт вам намеренно. У них просто ещё нет этой информации — потому что информация не существует, пока не существует сама вещь.
То, чего интервью дать не может
То, что действительно нужно знать перед разработкой, — это поведение, а не отношение: откроет ли человек это приложение во второй раз, заплатит ли он за него, застрянет ли на третьем экране и уйдёт. Ничего из этого не проявляется в разговоре. Это проявляется в записи сессии, графике оттока, тикете поддержки. Пользователь может совершенно искренне сказать вам, что онбординг «понятен», а потом бросить его через сорок секунд, потому что самооценка и поведение — два разных инструмента, измеряющих две разные вещи.
Экономика раньше всё равно вынуждала действовать в порядке «сначала интервью». Если создание вещи занимает восемь недель и трёх инженеров, вы не можете позволить себе узнать, что ошиблись, уже после выпуска — поэтому вы переносите риск на дешёвые разговоры в надежде, что они поймают дорогие ошибки. Этот компромисс имел смысл, когда разработка была узким местом. Теперь это не так. Рабочий прототип — с настоящей авторизацией, настоящей базой данных, интерфейсом, по которому можно реально кликать — теперь создаётся за один вечер с правильными инструментами, в том числе моими. Как только стоимость первой версии падает настолько, интервью перестаёт быть дешёвым способом снижения риска и становится дорогим этапом. Вы платите неделями календарного времени, чтобы избежать разработки, которая стоит вам выходных.
Что я делаю вместо этого
Создайте максимально небольшую реальную версию идеи, покажите её трём-пяти реальным людям с этой проблемой и наблюдайте, а не спрашивайте. Не «что вы думаете» — а где помедлил ваш курсор, на что вы нажали, что не сработало, что вы попытались сделать, но продукт этого вообще не поддерживал. Вот последнее — это золото: то, что человек попытался сделать без подсказки, — более достоверный сигнал, чем всё, что он сказал бы вам в гипотетическом интервью, потому что это выявленное предпочтение, а не заявленное.
Это переворачивает традиционную воронку исследований, и стоит явно проговорить, что меняется:
| Сначала интервью | Сначала разработка | |
|---|---|---|
| Что вы измеряете | Заявленное намерение («я бы, наверное, пользовался этим») | Реальное поведение (открыли приложение три раза за неделю или нет) |
| Цена ошибки | Низкая за один цикл, но можно ошибаться месяцами на протяжении десятков интервью | Один цикл разработки, после чего данные быстро вас корректируют |
| Лучший вопрос | «Что вас раздражает в том, как вы делаете это сегодня?» | «Покажите, как вы в последний раз пытались сделать X здесь» |
| Что хорошо выявляет | Существует ли проблема вообще | Работает ли именно ваше решение этой проблемы |
| Тип сбоя | Все вежливы, никто не честен, и вы уверенно строите не то | Вы выпускаете сырой продукт до того, как заслужили доверие, и производите плохое первое впечатление |
Обратите внимание: эти две строки не отменяют друг друга — они отвечают на разные вопросы. Интервью неплохо подтверждают, что проблема реальна. Но они плохо показывают, правильно ли ваше конкретное решение, потому что вашего конкретного решения ещё не существует, чтобы кто-то мог на него честно отреагировать. Это как раз то различие, которое большинство советов «поговорите с пользователями» упускают: обычно это хороший совет для поиска проблемы и плохой — для проверки решения, а люди применяют его и там, и там.
Один знакомый основатель провёл четырнадцать интервью для инструмента записи в парикмахерские. Тринадцать сказали, что проблема двойного бронирования реальна и болезненна. Она это построила. Внедрение оставалось на нуле. Оказалось, владельцы салонов ненавидели двойное бронирование в теории, но уже выстроили хрупкие личные обходные решения, от которых не хотели отказываться — об этом никто не упомянул, потому что никто не думает описывать свой способ выживания, пока ему не покажут замену и не увидят, как он от неё отказывается.
В чём критики правы
Это работает не всегда, и было бы преувеличением утверждать обратное. Если разработка действительно дорога в отмене — оборудование, регулируемый медицинский процесс, всё, где каждое изменение требует проверки на соответствие требованиям, — расчёт снова смещается в пользу интервью в первую очередь, потому что асимметрия затрат, которая делает разработку сначала дешёвой, здесь просто не работает. Прототип, который можно выбросить за полдня, — совсем другое дело, чем устройство, под которое уже изготовлена форма.
Ещё одна область, где исследование окупается, — корпоративные продажи с длинным циклом. Если ваш покупатель — закупочный комитет, а цикл продажи занимает четыре месяца, вы не можете «просто выпустить и посмотреть» до подписанного контракта — нужно знать до разработки, пройдёт ли продукт хотя бы проверку безопасности, потому что сорвавшаяся через полгода сделка обходится куда дороже любого интервью. А чистое исследование проблемы, проведённое рано и дёшево — когда вы сидите рядом с человеком, пока он выполняет свою реальную работу, а не просите его вообразить будущий продукт, — действительно недооценено и действительно полезно. Я не против разговоров с людьми. Я против того, чтобы вежливую гипотетическую беседу принимали за доказательство, когда грубый реальный прототип, показанный тому же человеку на десять минут, скажет правду вместо этого.
