Riskiest assumption test: быстрый и дешевый метод тестировать идеи

Бывают идеи, способные убить проект еще на старте. Но не замечая их, компании порой запускают MVP, который в итоге оказывается не нужен потребителю. Избежать такой ситуации можно, используя Riskiest assumption test, или RAT. Эта статья о том, как он работает и как с его помощью удалось протестировать рискованные гипотезы за полторы недели вместо восьми месяцев.

Всем привет! Меня зовут Женя Паршин, я ex-CPO Альфа-Банка и СЕО продуктовой студии по подписке ProductHub. Мне нравится все упрощать, делать процессы быстрее и эффективнее. В какой-то момент я начал оптимизировать свой подход к тестированию гипотез и узнал про Riskiest Assumption Test (RAT) — быстрый тест самых рискованных идей, которые могут убить ваш продукт уже на старте.

Уверен: тестировать идеи нужно быстро и дешево. Только так можно вывести востребованный продукт на рынок в короткие сроки. Однако многие компании проверяют идеи только на стадии разработки MVP, теряя время и деньги.

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

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

Чтобы проверить гипотезы по RAT необходимо:

1. Составить список рискованных гипотез,
2. Оценить их по критериям ниже и выбрать самые важные,
   
3. Протестировать.

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

• Для проверки спроса мы проводим исследование, общаемся с пользователями, узнаем их боли.

• Если гипотеза о том, что продукт нужен аудитории, подтверждается исследованием, то проверяем, как пользователь будет с ним взаимодействовать. Разрабатывать для этого ничего не нужно — достаточно сделать простой лендинг, на котором легко отследить поведение потенциальных покупателей.

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

• Спрос и ценность предложения для аудитории зависят от сегмента, на котором мы фокусируемся. Их много, RAT помогает быстро найти самый мотивированный и платежеспособный сегмент, у которого есть потребность в нашем продукте и повторных покупках.

RAT выясняет, нужен ли продукт пользователю и стоит ли тратить силы на его создание. Результатом станут новые знания о продукте, на базе которых можно строить его первую версию — MVP.

Для закрепления давайте проведем продукт — подписку на сервис по заказу автозапчастей — по всей цепочке RAT.

Идея в том, что сервис — прослойка между клиентом и поставщиком, но вместо наценки на товар мы продаем абонемент и зарабатываем именно на доступе к платформе по нему. Клиент покупает годовую подписку, по которой сможет заказывать автозапчасти у крупных поставщиков напрямую по оптовой цене. Экономия для него составит от 30 до 50%. В данном случае для нас краткосрочная прибыль меньше, долгосрочная — больше.

Я решил проверить гипотезу по RAT, но начал не с первого шага, а с нулевого — исследования. Без него нет смысла запускать процесс.

Шаг 0. Провести исследования

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

Шаг 1. Составить список рискованных гипотез

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

— Что может пойти не так?

— Что может работать не так, как мы думали?

— Из-за чего продукт может не запуститься?

— Что мы ошибочно приняли за истину?

Для моего сервиса по заказу автозапчастей я выделил шесть рискованных гипотез:

Шаг 2. Оценить гипотезы

Этот вопрос важно задавать себе, команде и экспертам рынка. Я сформулировал четыре критерия, по которым оцениваю жизнеспособность идеи:

1. Ее способность убить продукт: если гипотеза подтвердится, продукт перестанет окупаться и его придется закрыть.

2. Количество ресурсов, необходимых для проверки этой гипотезы.

3. Сложность тестирования.

4. Время проверки.

На примере трех моих гипотез разберем, какие из них рискованные, а какие — нет.

1. Люди хотят покупать автозапчасти. Рискованная ли она? Конечно, нет. Это не гипотеза, которую нужно проверять, — это факт.

2. Стоимость привлечения лида будет не больше тысячи рублей. Рискованно? Да. У нас есть бизнес-модель и юнит-экономика, так что мы понимаем, какой предельный показатель привлечения клиента нам нужен.

3. Мы получим хорошие условия от поставщика, чтобы выгодно продавать запчасти клиенту. Рискованная ли она? Конечно. Не факт, что поставщик согласится дать нам как сервису низкие цены. Это нужно проверить.

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

Шаг 3. Проверить предположения

Оценить спрос легко. Я сделал лендинг, на котором рассказал о продукте и разместил форму заявки. Затем запустил трафик и посмотрел, как все работает. Спойлер — никак. Посетители не конвертировались в лиды, и гипотеза о спросе оказалась неверной.

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

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

До тестирования гипотез RAT-методом я восемь месяцев вел переговоры с инвесторами, проходил инкубатор в «Вышке», питчил проект, строил финансовые модели.

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

На RAT ушло полторы недели, что лучше всяких слов доказывает пользу метода. Он позволяет проверить рискованные идеи максимально быстро и дешево, чтобы сохранить время и деньги.

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

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

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

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

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