Бывают идеи, способные убить проект еще на старте. Но не замечая их, компании порой тратят деньги и время на запуск MPV, который в итоге оказывается не нужен потребителю. Сэкономить ресурсы и быстрее проверять гипотезы можно, используя Riskiest assumption test, или RAT.
Евгений Паршин, ex-CPO Альфа-Банка и СЕО продуктовой студии по подписке ProductHub, рассказал о том, что такое RAT и как его использовать, а также как с его помощью удалось протестировать рискованные гипотезы за полторы недели вместо восьми месяцев. Статья сделана на основе доклада Евгения с ProductSense’21 Moscow.
Мне нравится все упрощать, делать процессы быстрее и эффективнее. В какой-то момент я начал оптимизировать свой подход к тестированию гипотез и узнал про Riskiest Assumption Test (RAT) — быстрый тест самых рискованных идей, которые могут убить ваш продукт уже на старте.
MVP — более-менее что-то разработанное, какой-то продукт. И на уровне идеологии.
Мы пишем о менеджменте продуктов и развитии в телеграм-каналах ProductSense и Продуктовое мышление.
Что такое RAT и чем он хорош
Уверен: тестировать идеи нужно быстро и дешево. Только так можно вывести востребованный продукт на рынок в короткие сроки. Однако многие компании проверяют идеи только на стадии разработки MVP, теряя время и деньги.
RAT — это подход, который помогает избежать такого сценария. Он позволяет проверить на прочность самые рискованные гипотезы о продукте или отдельной его функции максимально быстро и дешево. Расскажу, как это работает.
У нас есть бизнес-идея. Исходя из нее, мы выделяем рискованные гипотезы — это предположения, из-за которых с высокой долей вероятности ваш продукт не сможет выжить или не будет востребован. Например, не сойдется юнит-экономика проекта или не получится выстроить операционную часть. Затем мы оцениваем эти гипотезы по степени значимости, выводим в топ самые опасные и тестируем их.
Чтобы проверить гипотезы по RAT, необходимо пройти такой путь:
- Составить список рискованных гипотез.
- Оценить их по критериям (я даю их ниже) и выбрать самые важные.
- Протестировать.
С помощью RAT можно проверить четыре важные вещи: спрос на продукт, его ценность для пользователя, юнит-экономику и правильность выбранного сегмента.
- Для проверки спроса мы проводим исследование, общаемся с пользователями, узнаем их боли.
- Если гипотеза о том, что продукт нужен аудитории, подтверждается исследованием, то проверяем, как пользователь будет с ним взаимодействовать. Разрабатывать для этого ничего не нужно — достаточно сделать простой лендинг, на котором легко отследить поведение потенциальных покупателей.
- С помощью RAT также можно проверить одну из самых важных частей нашего продукта — юнит-экономику. Главные ее показатели — стоимость привлечения клиента и LTV, то есть количество денег, которое приносит клиент за все время взаимодействия с продуктом.
- Спрос и ценность предложения для аудитории зависят от сегмента, на котором мы фокусируемся. Их много, RAT помогает быстро найти самый мотивированный и платежеспособный сегмент, у которого есть потребность в нашем продукте и повторных покупках.
RAT помогает выяснить, нужен ли продукт пользователю и стоит ли тратить силы на его создание. Результатом станут новые знания о продукте, на базе которых можно строить его первую версию — MVP.
Восемь месяцев vs полторы недели
Для закрепления давайте проведем продукт — подписку на сервис по заказу автозапчастей — по всей цепочке RAT.
Идея в том, что сервис — прослойка между клиентом и поставщиком, но вместо наценки на товар мы продаем абонемент. Клиент покупает годовую подписку, по которой сможет заказывать автозапчасти у крупных поставщиков напрямую по оптовой цене. Экономия для него составит от 30 до 50%. Сервис зарабатывает на доступе к платформе по абонементу.
Я решил проверить гипотезу по RAT, но начал не с первого шага, а с нулевого — исследования. Без него нет смысла запускать процесс.
Шаг 0. Провести исследования
Важно сделать это в самом начале, чтобы понять контекст, боли и потребности своих пользователей, а также смоделировать юнит-экономику. Самый простой вариант — провести конкурентный анализ, заполнить Lean Canvas и идти дальше. Вот что получилось у меня.
Шаг 1. Составить список рискованных гипотез
Чаще всего именно из исследования рождаются предположения, которые мы включаем в список рискованных гипотез. От этого списка будем отталкиваться в дальнейшем. Как правило, мы находим рискованные гипотезы через исследования, брейнштормы с командой, либо через самостоятельные рассуждения. Попробуйте задать к своему заполненному Lean Canvas следующие вопросы:
— Что может пойти не так?
— Что может работать не так, как мы думали?
— Из-за чего продукт может не запуститься?
— Что мы ошибочно приняли за истину?
Для сервиса по заказу автозапчастей я выделил шесть рискованных гипотез:
Шаг 2. Оценить гипотезы
Нужно понимать, что может убить продукт.
Этот вопрос важно задавать себе, команде и экспертам рынка. Я сформулировал четыре критерия, по которым оцениваю жизнеспособность идеи:
- Ее способность убить продукт: если гипотеза подтвердится, продукт перестанет окупаться и его придется закрыть.
- Количество ресурсов, необходимых для проверки этой гипотезы.
- Сложность тестирования.
- Время проверки.
На примере трех гипотез разберем, какие из них рискованные, а какие нет.
- Люди хотят покупать автозапчасти. Рискованная ли она? Конечно, нет. Это не гипотеза, которую нужно проверять, — это факт.
- Стоимость привлечения лида будет не больше тысячи рублей. Рискованно? Да. У нас есть бизнес-модель и юнит-экономика, так что мы понимаем, какой предельный показатель привлечения клиента нам нужен.
- Мы получим хорошие условия от поставщика, чтобы выгодно продавать запчасти клиенту. Рискованная ли она? Конечно. Не факт, что поставщик согласится дать нам как сервису низкие цены. Это нужно проверить.
По результатам моей оценки в топ вышли вторая и третья гипотезы, поскольку у них высокие риски и критичность влияния на продукт. Теперь наша задача — проверить их на практике, потому что неверные выводы смертельны для проекта. Помните, что до запуска мы ориентируемся лишь на прогноз юнит-экономики — реальные показатели станут известны только после запуска.
Шаг 3. Проверить предположения
Оценить спрос легко. Я сделал лендинг, на котором рассказал о продукте и разместил форму заявки. Затем запустил трафик и посмотрел, как все работает. Спойлер — никак. Посетители не конвертировались в лиды, и гипотеза о спросе оказалась неверной.
На этом этапе появилась еще одна гипотеза. Допустим, клиент, прежде чем оформлять подписку, хочет увидеть, сколько стоят запчасти. Чтобы проверить это утверждение, я за пару дней сделал в конструкторе интернет-магазин с видимыми ценами.
Спустя неделю спроса так и не было, и гипотеза была опровергнута. Чтобы узнать, почему так произошло, я пообщался с людьми, которые не хотели покупать подписку. Оказалось, что они не видят выгоды: им кажется странным тратить деньги сейчас, чтобы сэкономить в будущем.
Результат проверки
До тестирования гипотез RAT-методом я восемь месяцев вел переговоры с инвесторами, проходил инкубатор в «Вышке», питчил проект, строил финансовые модели.
Когда я почти получил инвестиции, я решил быстро проверить спрос, прежде чем брать деньги. Проверка по RAT вышла интуитивной, о методе я тогда не знал.
Так я пришел к выводу: не стоит тратить много времени на идеи.
На RAT ушло полторы недели, что лучше всяких слов доказывает пользу метода. Он позволяет проверить рискованные идеи максимально быстро и дешево, чтобы сохранить время и деньги.
RAT эффективно использовать перед запуском MVP. Сначала мы тестируем основные рискованные гипотезы, и если проверка показывает, что продукт нужен пользователям именно в таком виде, начинаем разрабатывать MVP. С моей точки зрения, тратить время и деньги на его запуск имеет смысл, только когда есть уверенность, что юнит-экономика сойдется.
Мифы о RAT
Существует два мифа об этом методе тестирования идей. Первый гласит, что RAT не нужен, если нет рискованных гипотез. Второй — что он не подходит для проверки сложных IT-продуктов. Отвечу на оба утверждения.
- Чаще всего вам может казаться, что рискованных гипотез нет, потому что все идеи уже проверили до вас. Но даже если это правда, мы не знаем, на каких данных и выборках проводили исследования. Поэтому, чтобы получить релевантные выводы, нужно сделать собственные тесты.
- Хоть и кажется, что нельзя быстро и дешево проверить сложный продукт, все же это реально. Например, есть искусственный интеллект, который определяет правильность бега у спортсменов и дает рекомендации по его улучшению — в этом кейсе AI заменяет тренера, спортсмен может быть не привязан к его расписанию и не платит за тренировки. В данном случае тестировать нужно не само решение, а результат, который приносит технология, — автоматизированный процесс, который экономит деньги на людях. Клиент покупает решение своей задачи, а не классный искусственный интеллект.
Если продукт улучшает жизнь человека, нужно продать это улучшение.
***
Ребята из ProductHub помогают компаниям улучшать продукты — с их кейсами можно познакомиться в блоге.
