Консьерж и волшебник из страны Оз

Итак, предположим мы продали несуществующий продукт с помощью слайдов или лендоса. Это подтверждает востребованность продукта, но мало что говорит о жизнеспособности и совершенно ничего — о реализуемости:
▪️ Жизнеспособность — способны ли мы зарабатывать на продукте деньги (сойдется ли экономика)? Часть информации — о потенциальных доходах — у нас есть — мы же не бесплатно продавали продукт на предыдущем этапе, но в случае сложных продуктов мы пока не понимаем наши расходы.
▪️ Реализуемость — тут совсем сложно. Если у нас что-то купили, это вовсе не значит, что мы это можем сделать.

И снова есть куча вариантов, как это проверять, но мне нравятся два, причем достаточно похожих. Они подходят в первую очередь для сложных и новых продуктов, меняющих подходы или способы решения проблем потребителя. А для простых продуктов, где нам надо что-то заказать на стороне, соединить вместе и продать, оценить реализуемость и жизнеспособность все же легче.

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

Помним: продукта у нас еще нет. Пока есть только гипотеза о ценностном предложении, и мы ее уже даже как-то валидировали, например, так.

Теперь надо понять, а сможем ли мы этот продукт вообще сделать, причем сделать так, чтобы еще и экономика сошлась. Плюс мы хотим посмотреть на взаимодействие пользователя с продуктом и выбрать наиболее важную функциональность. Для этого нам надо, чтобы пользователь повзаимодействовал с продуктом, которого у нас нет.

Для таких ситуаций подходят два метода:
1. Консьерж
2. Волшебник из страны Оз

Оба заключаются в том, что вы выполняете операции вручную. То, что в продукте должно работать автоматически, делаете руками. В примере с сервисом подбора преподавателей английского, сами подбираете этого преподавателя на основе информации из профиля пользователя — скажем, он заполнил какую-то анкету. Да, в будущем вместо анкеты система будет анализировать его профиль, смотреть, с какими преподавателями он долго занимался, а с какими — быстро прекратил, искать похожих пользователей и брать их преподавателей и т.д., но это все непростая, долгая и дорогая разработка, чего мы делать не хотим, пока не поймем, что оно в принципе работает. Поэтому пока профили анализируем вручную и преподавателей тоже подбираем руками.

Помню, было приложение “для распознавания всего на свете”, которое могло по фото назвать любой предмет, а в сложных случаях давало описание текстом типа “деревянная квадратная штука, лежащая на светлой ткани”. Там на самом деле не было никакой автоматизации, машин лернингов и нейросетей — их заменяла армия индийцев, которые смотрели на фотки и писали, что видят.

Отличие консьержа от волшебника
В первом случае пользователь знает о том, что операции делаются вручную, а во втором — нет. В первом случае мы говорим: “Дорогой друг, у нас пока что не работает вся полная автоматизация, поэтому тебе поможет человек — и так будет только лучше. Заполни, пожалуйста, анкету”. Во втором случае ничего не говорим, а поступаем, как те индийцы.

Зачем это все надо
✔️ Во-первых, мы с большей достоверностью валидируем гипотезу ценностного предложения. Может, на лендинге пользователь нас не так понял, а как дело дошло до работы с сервисом, почему-то не хочет пользоваться.
✔️ Во-вторых, раскладываем сложную задачу на набор более простых действий — и выполняем их вручную. Это позволяет нам достовернее оценить, а сможем ли мы вообще такое сделать без участия человека.
✔️ В-третьих, становится яснее, сколько это может стоить. Например, сколько потребуется операций -> сколько расчетов и на каком объеме данных -> сколько будет стоить облако, чтобы это все хранить и обрабатывать. А доходную часть мы проверяли на этапе продажи.
В итоге экономика становится понятнее.