Комментарии
За что критикуют концепцию MVP, столь любимую стартапами, и почему подход RAT с его самыми рискованными гипотезами даёт больше профита
Самая рискованная гипотеза против минимально жизнеспособного продукта
За что критикуют концепцию MVP, столь любимую стартапами, и почему подход RAT с его самыми рискованными гипотезами даёт больше профита
Во многих наших кейсах можно наглядно посмотреть, как менялся проект от первоначальной версии до итоговой реализации. Разработка минимально жизнеспособного продукта (MVP) для нас — обычное дело и стандарт для разработки по SCRUM. На этапе аналитики мы глубоко прорабатываем с клиентом гипотезы, выделяем ключевой функционал, который стоит реализовать в первую очередь и приступаем к работе. Остальные фичи — в следующих спринтах.
Дмитрий
Аккаунт-менеджер
MVP в настоящее время стал больше нарицательным термином (довольно часто можно встретить вместо него аббревиатуру MPV — сразу создаётся ощущение, что человек когда-то мечтал о Мазде). В сознании многих, любой проект, подразумевающий некую этапность — эмвипи. Ну нет :) Поэтому очень часто происходит подмена понятий, и без танцев с бубном не разобраться: что под MVP имеет в виду конкретный клиент.
MVP особенно актуален и особенно эффективен для стартап-проектов (таких, как BeLingua, например). Но бывает, что у стартаперов происходит сдвиг: они хотят реализовать как можно больше фишек в первой версии своего продукта, не проверяя, а нужно ли это вообще кому-нибудь. Про результаты вы знаете — очень редкий стартап «взлетает», поскольку у пользователей попросту нет в нём потребности.

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

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

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

Эрик Рис в своей книге «Lean Startup» называет такие предположения гипотезами и выделяет два их типа:
1
Основная гипотеза
То, что стоит проверить в первую очередь (про это хорошо написал российский инвестор Аркадий Морейнис).
2
Гипотеза роста
То, что можно сделать для проверки основной гипотезы.
Пример Фейсбук
Основная гипотеза: студентам хочется делиться личной информацией.

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

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

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

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

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

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

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

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

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

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

Для поиска и проверки гипотез также предлагают другую бизнес-модель — KANO, очень напоминающую Lean Canvas. В ней делается акцент на том, действительно ли решаемая проблема — это проблема пользователей, а не очередная хотелка гендиректора.
Обе схемы рабочие — выбирайте, какая нравится больше :) И не забудьте поговорить с экспертами и настоящими клиентами перед заполнением бизнес-моделей, чтобы не быть голословными.
2. Рискованные, но потенциально крутые гипотезы
Гипотезы помогут определить, достаточно ли масштабна проблема, является ли ваш продукт правильным способом ее решения и можете ли вы создать его и продать без потери денег.
Простая формула гипотезы: если [предложение], то [результат]
Для проверки гипотез пригодятся вопросы:

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

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


Для каждой из гипотез нужно дать две оценки:
1
Вероятность, что предположение ошибочно, по шкале от 1 до 5, где 5 — вы вообще не уверены, что идея взлетит, а 1 — уверены почти на 100%, что после запуска всё будет хорошо.
2
Степень влияния предположения на продукт, по шкале от 1 до 10 (на ваш взгляд).
Далее перемножьте эти числа для каждой гипотезы, чтобы рассчитать общий риск — вуаля, выбирайте самую рисковую, и вперед — проверять!
Простой пример
Предположение 1: Если у белок есть ноги, значит им нужны штаны. Вероятность: 5, влияние на продукт (штаны для белок) — 10. Общий риск — 50.

Предположение 2: Если белке холодно зимой, она может согласиться вообще не выходить из дупла, если дать ей запас корма для белок. Вероятность — 3. Влияние на продукт — 10. Общий риск — 30.

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

Желательность
Этот аспект сложнее всего проверить, поэтому он часто игнорируется при разработке продукта. Ваш продукт — действительно что-то значимое для достаточного количества людей? И будут ли они пользоваться им так, как вы предполагаете? Вот здесь как раз пригодится MVP, который поможет протестировать «мини-версию» продукта на реальных пользователях.
4. Проверка
Как проверять — зависит от конкретной ситуации: это может быть интервью с живыми пользователями (хотя не стоит забывать про субъективизм их ответов), интерактивный прототип, сайт на коленке или что угодно ещё. Вот несколько ярких примеров компаний, которые начинали с минимумом затрат, просто тестируя свою гипотезу.
История Airbnb
Все началось с того, что соучредители Брайан Чески, Натан Блечарцизк и Джо Геббиа заметили, что конференции в Сан-Франциско происходят часто, а отели для участников стоят дорого. Тогда они решили купить парочку надувных матрасов, положить их в свободной комнате своей квартиры и сдавать в аренду за 80 долларов за ночь. Быстренько собрали простецкий сайт airbedandbreakfast.com, где УТП стал бонус в виде бесплатного завтрака и общения. Теперь же это крупнейшая сеть для бронирования жилья по всему миру.
Как когда-то выглядела первая версия Airbnb
История Zappos
Всё началось с того, что Ник Свинмерн решил сделать простенький интернет-магазин обуви, пока это ещё не было мейнстримом (от слова «совсем»). Он сходил в ближайший магазин, сделал фотографии нескольких пар обуви и разместил их на своём сайте ShoeSite.com. Когда появились первые заказы, он вернулся в магазин, купил там обувь и отправил её покупателям. А сейчас это крупный е-коммерс проект с 20-летней историей.
История Dropbox
У компании было предположение, что есть большое количество людей с очень специфической проблемой: они работали на разных устройствах и хотели бы легко получать доступ к одним и тем же файлам с разных гаджетов. Тогда основатель Дрю Хьюстон снял короткое видео, где наглядно продемонстрировал синхронизацию файлов на разных устройствах — и за ночь количество пользователей, желающих скачать бета-версию Dropbox, увеличилось с 5 000 до 75 000 человек.
5. Сбор данных и результаты
Собираем обратную связь и анализируем результаты эксперимента. Вариантов развития событий всего два:
1
Гипотеза подтверждается
Можно браться за создание MVP, реального продукта или переходить к гипотезе роста.
2
Гипотеза не прошла проверку
Горечь сожаления и радость от сэкономленных ресурсов. Доставай другую!
Хоронить MVP всё-таки не стоит — он прекрасно уживается с подходом RAT. И на самом деле, концепция проверки самых рискованных гипотез перед созданием продукта годится не только для стартаперов: она также подойдёт для крупных компаний, желающих выйти на новые рынки, запустить новое направление бизнеса или как-то ещё масштабировать своё детище. По-хорошему, проверка гипотез на RAT должна стать частью вашего постоянного процесса развития — поскольку это даёт импульс и неплохо экономит деньги на бессмысленных разработках :)
Владимир
CEO&Founder
Во-первых, потенциальные пользователи — врут. Их обратную связь или идеи о том, что нравится/не нравится, хотелось бы/не хотелось бы — нельзя ни в коем случае использовать без фильтров. Иначе получите продукт-франкенштейн.

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

Во вторых, основатели проектов — галлюцинируют. Подтасовывают факты. Оттягивают момент встречи проекта с рынком.

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