Как подход RAT помогает мне убивать идеи продуктов еще до создания MVP (Евгений Паршин)

Евгений Паршин, CPO, Альфа-Банк

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

Кто я? Женя Паршин, CPO а «Альфа-банке» и СЕО продуктовой студии по подписке ProductHub. Если ретроспективно посмотреть на весь мой прошлый опыт с 2016 по 2020 год, кроме того, что я работал в найме, я еще дико люблю запускать свои собственные продукты, тестировать идеи. Это прямо моя страсть, очень люблю это делать. За четыре года я протестировал около тридцати своих продуктовых идей, только три из них взлетело. Тут классика, тут как с гипотезами. Выстреливает одна гипотеза из десяти, с продуктами примерно то же самое.

Но есть очень классная особенность. За всё это время, несмотря на то, что я протестировал достаточно много продуктовых идей, я потратил очень мало времени и очень мало денег. Если бы я запускал и тестировал все эти продукты через такой классический подход, когда я исследую, запускаю MVP и получаю какую-то обратную связь от рынка, то, скорее всего, я бы потратил достаточно много денег. Если примерно умножить количество идей на среднюю сумму, которая требуется для создания MVP, то получится в среднем по больнице около 20 миллионов рублей либо пять лет. И в общем кажется, что я сэкономил реально много денег и реально много времени.

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

Прежде чем начну, хочется сказать, что здравый смысл — наше всё. Существует достаточно большое количество разных подходов, методик тестирования продуктов. На слайде вы видите около восьми разных подходов, но базово их все объединяет одно — здравый смысл. И в том подходе RAT (Risk assumption test), про который я буду сегодня рассказывать, здравый смысл действительно самое важное.

Сейчас на пальцах прямо объясню, в чем разница между MVP и RAT, потому что очень часто либо оба этих понятия смешиваются в одно, либо MVP называют RAT, а RAT называют MVP, либо прототипом. Хочется тут внести чуть больше ясности и рассказать, как это вижу я, и сделать это прямо на примере.

Предположим, я придумал идею сервиса, примерно как «Яндекс.Шеф», но только продукты не режем и фасуем, а привозим из «Перекрестка», потому что мы умные, мы хотим снизить операционные издержки и приносить достаточно большую ценность клиенту.

Как бы выглядел MVP этого сервиса? Базово, верхнеуровнево — три задачи. Первая задача — разработка MVP-платформы, вторая задача — интеграция с «Перекрестком» (мы же хотим получать в real-time остатки, менять товары в real-time) и настройка операционки. Вот три базовых задачи.

На первую задачу нужно потратить примерно два месяца и около 450 000 рублей, если повезет. Это для того, чтобы сделать MVP-платформу. Примерно три месяца на то, чтобы реализовать интеграцию с «Перекрестком» и 150 000 рублей. Ну и один месяц и 100 000 рублей на то, чтобы отладить операционку и смоделировать все бизнес-процессы. В итоге примерно три месяца и примерно 700 000 рублей.

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

А как бы выглядел RAT этого сервиса? То есть как бы выглядела проверка самых рискованных предположений этого продукта, а именно проверка гипотезы спроса?

Задача номер один — лендинг, задача номер два — привлечение трафика на лендинг, и третья задача — сбор обратной связи. На первую задачу потратим один день и примерно ноль рублей. На вторую задачу потратим примерно еще один день и тоже ноль рублей. И на третью задачу примерно пять дней потратим на то, чтобы пообщаться с пользователями, собрать некую обратную связь и понять, а почему они выбирали продукт. Шесть дней и ноль рублей. Звучит интересно.

С одной стороны, у нас с вами получается подход RAT (Risk assumption test), на который нам нужно потратить шесть дней и ноль рублей, с другой стороны у нас есть MVP — это примерно три месяца и 700 000 рублей. Выбирая между двумя этими вариантами, кажется, что выбор очевиден: безусловно, выбор в пользу RAT. Но на самом деле всё гораздо проще. Не нужно выбирать. Сначала мы тестируем все наши основные рискованные предположения через RAT, и если большая часть из них подтверждается и мы считаем, что те гипотезы, которые мы проверили, сбылись и наш продукт не умрет, мы уже дальше запускаем MVP. В общем, это последовательный процесс: сначала проверяем гипотезы через RAT, потом запускаем MVP.

MVP моего сервиса выглядел примерно так. Я написал статью на VC.ru с рассказом о своем продукте: рассказал, почему он классный, зачем он нужен, расписал красивую историю. Безусловно, в конце статьи я разместил ссылку на свою посадочную страницу, которую я тоже сделал самостоятельно своими ручками, на которой расписал преимущества продукта. Пришел трафик на лендинг, сконвертировался, я получил какие-то оплаты, какие-то заявки, и тест показался успешным. Дальше я этот продукт продолжил тестировать. Но первая проверка выглядела примерно так.

Что же такое RAT? Это процесс проверки самых рискованных предположений самым быстрым способом в самые короткие сроки. Это что-то, очень похожее на MVP, но еще более упрощенное. Кроме этого, мы тут тестируем не просто все гипотезы, а самые рискованные гипотезы, то есть те, которые с наибольшей вероятностью наш продукт реально убьют.

Базово через RAT можно проверить четыре вещи. Первая — спрос на продукт, то есть будет ли он востребован у клиента. Фактически тут мы проверяем то решение, которое мы и придумали. То есть мы поисследовали рынок, пообщались с пользователями, нашли их проблемы и задачи, и дальше мы для них формулируем решение. И вот когда мы формулируем решение, не факт, что это решение действительно зайдет пользователям, поэтому это нужно проверять, и для этого необязательно делать MVP. Мы можем сделать посадочную страницу, например, в которой расскажем о нашем продукте, о том, зачем он нужен, какая у него ценность, какой результат пользователь получит от взаимодействия с нашим продуктом. Поэтому базово это спрос. Наверное, 90% всех проверок у меня нацелены как раз на то, чтобы протестировать спрос.

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

Еще одна важная штука, которую мы можем проверить при помощи Risk assumption test-а, — это юнит-экономика. Безусловно, одна из самых важных частей нашего продукта, от которой зависит успех нашего продукта, — это юнит-экономика. Если наш продукт не будет зарабатывать и у него будет сильно убыточная юнит-экономика, то окажется, что продукт нет смысла запускать, если даже не видится какой-то перспективы выпрямления этой юнит-экономики.

Основными показателями юнит-экономики, как правило, являются несколько метрик. Первая метрика — это стоимость подключения клиента, вторая — LTV, то есть то, сколько денег нам принесет клиент за всё время взаимодействия с нашим продуктом. Как правило, это две самые важные метрики, которые очень сильно влияют на наш продукт, и даже эти метрики можно проверить с помощью RAT.

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

Всё это звучит здорово, в целом достаточно понятно и кажется, что такой подход работает только в стартапах, когда ты не рискуешь брендом, когда ты можешь делать решения на коленке, когда ты можешь не сильно переживать за пользователя. Но что делать в случае, если у тебя большой продукт, состоявшийся бренд?

Расскажу на одном из примеров, как я это делал у себя в «Альфа-банке». Мы хотели запустить новый продукт, новый нефинансовый сервис. Безусловно, мы посмотрели рынок, пообщались с клиентами и те качественные данные, которые мы получили в результате исследования, нам нужно было подтвердить на какой-то количественной выборке. И для того, чтобы количественную выборку найти и на этой количественной выборке подтвердить нашу основную гипотезу о спросе на продукт, мы запилили вот такой небольшой опросик, где мы вкратце рассказываем про идею и пользователь может поставить либо лайк, либо дизлайк. Всё, два действия. Рассказываем о продукте, пользователь взаимодействует с этой идеей, говорит либо классно, либо нет, и так мы получаем какой-то результат. Это базовая проверка спроса, для того чтобы понять, в правильную ли сторону мы думаем.

Запилили такой опрос, разместили его очень нативно на витрине всех продуктов и на выходе получили результат, что сервис пользователям не нужен. Хотя по всем первичным признакам, по всем результатам качественных исследований казалось, что он классный, что сервис нужно запускать и он действительно будет нужен. Но количественная выборка показала обратное. Вот так мы и проверяли идею нашего продукта внутри крупной корпорации «Альфа-банк».

Безусловно, к RAT есть вопросики. Первый вопрос заключается в том, что типа всё уже проверено. Зачем проверять рискованные предположения? Рискованных предположений не осталось, всё уже проверено за нас. Безусловно, это так, но тут важный нюанс. Когда мы запускаем новый продукт на рынок, мы запускаем не просто клон существующего продукта, а мы запускаем продукт, который будет лучше нашего конкурента. И, как правило, в этой лучшести и кроются риски, то есть мы не всегда уверены, что та лучшесть, которую мы придумали, действительно удовлетворит нашего клиента.

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

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

И третье — не подходит для сложных продуктов. Есть сложившееся мнение, что через RAT очень сложно проверять какие-то очень крутые технологически продукты. На самом деле это тоже не совсем так и есть нюансы.

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

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

Давайте с вами предположим такую идею сервиса: клиент покупает годовой доступ и может заказывать автозапчасти без наценки через нашу платформу у крупных поставщиков. Экономия для клиента — 30% — 50%. То есть мы такая прослойка между розничным клиентом и оптовым поставщиком, но мы не делаем наценку, а продаем пользователю абонемент. Звучит достаточно здраво, экономия для клиента существенная. По каким-то причинам мы эту идею решили взять в работу (этот момент, наверное, не будем обсуждать). Всё, решили и решили, давайте тестировать.

Шаг номер ноль — это исследование. Исследование в любом случае важно проводить, для того чтобы погрузиться в контекст, для того чтобы понять задачи и проблемы своих пользователей, для того чтобы накидать юнит-экономику, смоделировать ее. Заполняем Lean Canvas, проводим исследования, проводим конкурентный анализ — классно, всё готово, идем дальше.

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

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

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

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

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

Гипотеза номер один: люди хотят покупать автозапчасти. Рискованная это гипотеза или нет? Конечно, нет. Это та гипотеза, которую не нужно проверять. Мы знаем, что рынок запчастей большой, сформированный, и это уже не гипотеза — это факт.

Гипотеза номер два: стоимость привлечения клиента будет не больше 1 500 рублей. Рискованная или нет? Да, это рискованная гипотеза, потому что у нас есть бизнес-модель, у нас есть юнит-экономика и мы понимаем, какой предельный показатель стоимости привлечения клиента нам нужен. И наша задача — это проверить. Не факт, что мы получим такую стоимость привлечения клиента. Поэтому да, это рискованная гипотеза, которая может убить наш продукт.

Третье: люди ищут автозапчасти, вбивая VIN-номер. Рискованная или нет? Нет, это не рискованная гипотеза, потому что мы знаем, что это один из альтернативных способов поиска запчастей. Это уже все знают, поэтому это проверять не нужно.

Четвертое: конверсия в покупку у владельцев Land Rover будет выше. Рискованная, конечно, потому что мы далеко не уверены в том, что владельцам Land Rover нужен наш продукт больше, чем кому-либо другому. Мы это предполагаем и это нужно проверить как можно быстрее, потому что потенциально владельцы Land Rover — это наш целевой сегмент, потому что тачки у них ломаются чаще.

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

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

Ценность — это то, что пользователь, купив наш продукт, получит ключевую ценность. В случае с моим кейсом ключевая ценность — это экономия для клиента от 30% до 50%. Наша задача — проверить, действительно ли клиент получит такую экономию, ценность.

И решение лучшести — это примерно то же самое, что и про спрос, но тут ключевая история в том, что мы тестируем формально УТП, какое УТП сработает лучше.

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

Безусловно, гипотезы — это классно и мы можем сгенерить достаточно много рискованных предположений, но какое из этих рискованных предположений нужно брать в первую очередь? Или какое из этих рискованных предположений убьет наш продукт с вероятностью 99%? Лучше давайте мы сразу возьмем эту гипотезу, проверим ее, убьем продукт и пойдем дальше. И для того, чтобы понять, что нужно в первую очередь из этого брать в работу, мы скорим эти гипотезы. Критериев для скоринга есть четыре. Это очень субъективные критерии. Вы можете заполнять эти критерии и оценивать каждую гипотезу либо самостоятельно, либо совместно с командой, каждый по отдельности, выводя что-то среднее.

Базовое — вероятность убить продукт, то есть то, насколько гипотеза рискованная. Тут есть четыре параметра и тут просто ставите субъективную оценку. Кроме этого для нас очень важна сложность проверки, то есть то, насколько сложно будет проверить эту гипотезу, то, какие нам ресурсы нужно будет привлечь. И время проверки и стоимость проверки. Мне кажется, тут тоже всё понятно. Это критерии мои, поэтому их можно менять. Вы можете их конкретизировать, добавлять новые критерии. Но базово я использую такие.

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

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

Шаг номер три — проверка. Это продолжение предыдущего шага, тут мы просто формулируем эксперимент — то, что мы хотим получить, и записываем это куда-то.

Как выглядела моя проверка? Как я вам сказал, базово в топ у меня вышли две гипотезы — гипотеза спроса и гипотеза о том, что я могу получить хорошие цены от поставщиков.

Гипотезу спроса я проверял очень просто. Я сделал посадочную страницу, где рассказал о своем продукте, разместил там какое-то ключевое целевое действие, запустил туда трафик и смотрел, как этот трафик будет работать. Спойлер — люди не конвертировались совсем. Эта гипотеза не сработала, спрос не подтвердился, и дальше я начал думать, а почему спрос мог не подтвердиться. То есть что такое могло случиться, что пользователь не сконвертировался? И так у меня появилось еще одно рискованное предположение, что для того чтобы пользователю сконвертироваться, ему важно увидеть цены на автозапчасти и убедиться в том, что у меня цены действительно низкие и что они действительно без наценки. И поэтому я поресерчил в интернете и нашел конструктор интернет-магазинов автозапчастей. За несколько дней запилил его, повторил тест и спрос не подтвердился, гипотеза провалилась. И спустя где-то полторы недели после начала теста я пришел к выводу, что спроса на этот продукт нет, пользователи не готовы это покупать. Я еще пообщался с теми людьми, которые не купили, и в итоге оказалось, что они не готовы платить за отсроченную выгоду, то есть они не готовы покупать абонемент сейчас, а выгоду получать в течение года. Они не понимали, как работает эта модель. Короче, причин у людей не покупать мой продукт было достаточно много, и классно, что я это понял буквально за полторы недели. Я понял, что спроса на этот продукт нет.

Но тут хочется сказать, что у этого продукта была небольшая предыстория. До того, как я начал его проверять, я его восемь месяцев холил и лелеял: я ходил по инвесторам с этим продуктом, я проходил инкубатор в «Вышке» — в общем, я делал всё для того, чтобы как можно позже эту проверку реализовать. То есть я потратил восемь месяцев на какие-то финмодели, на питчинг инвесторам, на акселерации, на что-то еще, и когда почти привлек инвестиции, я начал проверять, и оказалось, что продукт никому не нужен, и сделал это за полторы недели. А до этого восемь месяцев потратил. Поэтому это очень важная штука, то есть очень важно проверять ваши рискованные предположения, спрос на продукт как можно быстрее и дешевле.

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

Из полезного еще список инструментов, который может быть вам полезен для проверки ваших рискованных предположений как в новых продуктах, так и конкретных фичей. Например, опрос по модели КАНО поможет вам понять, какие фичи у конкурента, например, не востребованы, для того чтобы не пилить их в своем продукте. Либо фальш-кнопки, для того чтобы потестировать спрос на какой-то функционал либо на какой-то новый раздел в вашем текущем продукте. В общем, инструменты собрал здесь, заглядывайте в них. У меня всё, спасибо.