Во многих наших кейсах можно наглядно посмотреть, как менялся проект от первоначальной версии до итоговой реализации. Разработка минимально жизнеспособного продукта (MVP) для нас — обычное дело и стандарт для разработки по SCRUM. На этапе аналитики мы глубоко прорабатываем с клиентом гипотезы, выделяем ключевой функционал, который стоит реализовать в первую очередь и приступаем к работе. Остальные фичи — в следующих спринтах.

MVP особенно актуален и особенно эффективен для стартап-проектов (таких, как BeLingua, например). Но бывает, что у стартаперов происходит сдвиг: они хотят реализовать как можно больше фишек в первой версии своего продукта, не проверяя, а нужно ли это вообще кому-нибудь. Про результаты вы знаете — очень редкий стартап «взлетает», поскольку у пользователей попросту нет в нём потребности.

Есть альтернатива — подход RAT, или Riskiest Assumption Test (проверка наиболее рискованного предположения), призванный протестировать самые рискованные гипотезы и сразу понять: а нужна ли ваша гениальная идея рынку. Если да — работаем дальше, если нет — сорри, доставайте другую из списка огненных идей для стартапа.

Сегодня поговорим о подходе RAT подробнее: как с ним работать и когда он особенно пригодится.

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

Но вообще-то MVP и RAT не так далеки друг от друга, как могло показаться: MVP — это не столько продукт-продукт, сколько возможность проверить, что вы нашли проблему, которую стоит решить. Он и продуктом-то может не быть: его роль отлично сыграет интерактивный прототип или лендинг на Тильде вместо настоящего сайта. Более того, MVP может использоваться для проверки одного или нескольких предположений (по-другому, идей).

Эрик Рис в своей книге «Lean Startup» называет такие предположения гипотезами и выделяет два их типа:

Но что, если для начала проверить самую рискованную гипотезу без запуска MVP?

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

Для начала — собрать всю информацию о будущем продукте. И для этого адепты RAT очень советуют инструмент Lean Canvas (канву бизнес-модели). В его основе — шаблон бизнес-плана Оскара Остервальдера, который Эш Маурья оптимизировал под стартапы. И конечно, эта бизнес-модель вдохновлена методологией Lean Startup (читайте книгу Эрика Риса) и пропитана философией бережливого мышления.

Итак, сама модель:

Сегменты потребителей
Впишите сюда не только тех, кто покупает продукт, но и тех, кто им будет пользоваться (родители покупают игрушку, а ребенок ей играет). Ещё лучше — собрать реальную группу людей, которые будут первыми тестировать продукт и помогут проверить гипотезы.

Проблема
Какую потребность ваш продукт или услуга закрывают? И кто ещё это делает на рынке уже сейчас? Не забудьте, что помимо прямых конкурентов есть вторичные и косвенные (подробнее об этом — в статье о концепции Jobs To Be Done).

Уникальная ценность
По-другому — УТП, или почему клиенты захотят купить именно ваш продукт? В чём его ценность?

Решение проблемы
Пригодятся интервью с потенциальными пользователями и исследования, чтобы подтвердить ваши гипотезы.

Каналы
«Детям мороженое, бабе цветы» — для каждой аудитории ищите свои каналы :)

Потоки прибыли
Если продукт или услуга бесплатны, решите, как будете монетизировать проект.

Структура издержек
От зарплаты работникам и арендной платы до затрат на рекламу и создание сайта.

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

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

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

Обе схемы рабочие — выбирайте, какая нравится больше :) И не забудьте поговорить с экспертами и настоящими клиентами перед заполнением бизнес-моделей, чтобы не быть голословными.

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

Для проверки гипотез пригодятся вопросы:

• Сколько пользователей нужно, чтобы получить прибыль?
• В какие сроки?
• Достаточно ли масштабна проблема, которую вы хотите решить?
• Будут ли клиенты готовы платить за ваш продукт?
• Вы продаете нужным клиентам?
• Сколько бета-пользователей можно получить, прежде чем создавать продукт?

Общее правило: лучшая гипотеза — та, что затрагивает как можно больше пользователей и потенциально принесет больше денег, а её проверка займет минимум времени.

Но если гипотез слишком много (и это нормально), есть метод, чтобы понять, какая из них самая рисковая — её-то и стоит проверить в первую очередь.


Для каждой из гипотез нужно дать две оценки:

Далее перемножьте эти числа для каждой гипотезы, чтобы рассчитать общий риск — вуаля, выбирайте самую рисковую, и вперед — проверять!

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

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

Желательность
Этот аспект сложнее всего проверить, поэтому он часто игнорируется при разработке продукта. Ваш продукт — действительно что-то значимое для достаточного количества людей? И будут ли они пользоваться им так, как вы предполагаете? Вот здесь как раз пригодится MVP, который поможет протестировать «мини-версию» продукта на реальных пользователях.

Как проверять — зависит от конкретной ситуации: это может быть интервью с живыми пользователями (хотя не стоит забывать про субъективизм их ответов), интерактивный прототип, сайт на коленке или что угодно ещё. Вот несколько ярких примеров компаний, которые начинали с минимумом затрат, просто тестируя свою гипотезу.

Собираем обратную связь и анализируем результаты эксперимента. Вариантов развития событий всего два:

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