Что такое MVP (Minimal Viable Product)?

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

В 1999 году калифорниец Ник Свинмерн (Nick Swinmurn) безуспешно потратил много часов, чтобы найти себе пару коричневых ботинок в торговом центре в Сан-Франциско. В одном магазине был нужный ему стиль, но не тот цвет. В другом — нужный цвет, но не тот размер. И так было в каждом магазине в тот день.

Расстроенный, Ник задумался о том, как решить эту проблему самостоятельно. Его идеей стало создать онлайн-магазин, где можно было бы найти обувь любого нужного размера и цвета. Клиентами могли бы стать те люди, кто тоже не нашёл нужной обуви в местных магазинах и стал заказывать её в каталогах. Но Ник не знал, будут ли заказы обуви онлайн.

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

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

Когда появились заказы, Ник всё делал сам: выкупал обувь в магазине и доставлял обувь покупателям как курьер. Каждому заказчику он привозил несколько пар, чтобы он примерил и нашёл именно то, что ему подходит. Если обувь не подходила, Ник её забирал. Доставка была бесплатной.

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

Это забавный кейс, но на самом деле так часто происходит — за каким-нибудь чат-ботом может не быть никакого искусственного интеллекта:

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

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

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

На этапе MVP важно придерживаться графика уровня расходов и неопределенности с риском: