MVP, прототип или proof of concept: что делать первым

Каждый из них проверяет свой риск. В таблице они сравниваются бок о бок.

Proof of concept, или PoC, проверяет, возможно ли что-то технически. Обычно это небольшой кусок кода, который решает одну сложную задачу и игнорирует всё остальное: без дизайна, без аккаунтов, без доводки.

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

Большинству продуктов PoC не нужен. Если идея собирается из проверенных частей вроде аккаунтов, платежей, форм и дашбордов, технический риск низкий, и PoC только откладывает настоящий вопрос.

Код PoC обычно выбрасывают. Его писали, чтобы быстро ответить на один вопрос, а не чтобы на нём держался продукт.

Прототип показывает, как будет работать продукт, ещё до того, как кто-то напишет рабочий код. Это может быть набор набросков или кликабельный реалистичный интерфейс, который ведёт себя почти как настоящий.

Руководство Nielsen Norman Group о прототипах низкой и высокой детализации хорошо объясняет этот выбор. Простые наброски делаются быстрее и вызывают честную критику, а детальные прототипы показывают реалистичное поведение, что важно, когда тестируются конкретные сценарии.

Прототип ещё и лучший инструмент, чтобы договориться внутри команды. AutoIntel, B2B-инструмент для немецкого рынка подержанных автомобилей, начинался как интерактивный прототип на примерах объявлений. Клиент провёл по нему свою команду, и до оценки работ над сбором данных все договорились, какие поля и фильтры действительно важны.

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

Цель MVP в обучении, а не в запуске ради запуска. По формулировке Lean Startup, MVP делают, чтобы «как можно быстрее начать процесс обучения».

MVP измеряет то, чего не может измерить прототип: возвращаются ли люди и платят ли они. В CarPixly, ИИ-фотостудии для автообъявлений, любой может зарегистрироваться и бесплатно изучить студию, а оплата начинается в момент ценности, на рендере. Такая модель ясно показывает, сколько посетителей становятся платящими пользователями.

Большинство MVP разрабатываются за 6–14 недель в зависимости от сложности. Наши статьи о том, сколько времени занимает MVP и сколько стоит MVP для SaaS, дают диапазоны по уровням сложности.

Начинайте с самого рискованного неизвестного. Задайте себе эти вопросы по порядку:

• Есть ли реальный шанс, что это невозможно сделать? Например, продукт зависит от модели ИИ, аппаратного датчика или API, которые вы ещё не проверяли. Делайте proof of concept.
• Неясно, понимают ли люди решение и нужно ли оно им? Делайте прототип и тестируйте его на пользователях.
• Люди понимают решение и хотят его, а открытый вопрос в том, будут ли они пользоваться и платить? Делайте MVP.

Большинство стартапов оказываются на втором вопросе. Технология обычно проверена, а не проверено другое: имеет ли продукт смысл для тех, для кого он создаётся.

Не уверены, какой риск в вашей идее главный? Пришлите короткий бриф, и мы скажем, с какого шага начали бы сами и почему.

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

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

Простой раунд тестирования выглядит так:

• Дайте каждому участнику реалистичную задачу, например «запишитесь на услугу на следующий вторник».
• Наблюдайте, что он делает, не помогая и ничего не объясняя.
• Отмечайте, где человек сомневается, неправильно понимает экран или сдаётся.
• Исправьте самые серьёзные проблемы и протестируйте следующую версию на новых людях.

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

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

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

С proof of concept наоборот. Его код отвечает на один вопрос и обычно переписывается внутри MVP как следует, потому что никогда не предназначался для реальных пользователей.

Каждый шаг должен заканчиваться ясным ответом, а не ощущением. Запишите, что значит «успех», до начала работы, чтобы результат нельзя было потом подогнать под то, на что вы надеялись.

• Proof of concept успешен, когда сложная часть работает на реалистичных данных с той точностью или скоростью, которая нужна продукту. «Работает на трёх тестовых файлах» недостаточно, если пользователи будут присылать тысячи.
• Прототип успешен, когда большинство тестовых пользователей выполняют основную задачу без помощи и своими словами описывают проблему, которую он решает.
• MVP успешен, когда реальные пользователи возвращаются без напоминаний или платят, и делают это достаточно часто, чтобы следующая инвестиция имела смысл.

Если шаг не удался, это тоже полезно. Неудачный proof of concept избавляет от дорогой разработки. Непонятный прототип подсказывает изменить сценарий, пока изменения ещё дёшевы.

Задайте и срок для каждого шага. Прототип, который месяцами продолжают шлифовать, перестаёт быть тестом и превращается в продукт, которым пока никто не может пользоваться.

Иногда да. Если вы уже проверили идею, например через ручную версию сервиса, вы можете знать достаточно, чтобы сразу делать MVP.

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

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

Одни и те же ошибки повторяются снова и снова:

• Называть прототип MVP. Клики по прототипу показывают понимание, а не использование и не оплату. Не путайте одно с другим.
• Доводить proof of concept до продукта. Код, написанный ради ответа на один вопрос, становится хрупкой основой для всего, что строится поверх него.
• Пропускать прототип. Если делать MVP до проверки сценариев, вы платите разработчикам за то, чтобы они обнаружили проблемы дизайна.
• Вкладывать в MVP слишком много. Каждая лишняя функция откладывает момент, когда вы узнаете, работает ли ядро.
• Тестировать на друзьях. Люди, которые к вам хорошо относятся, похвалят идею. Тестируйте на тех, у кого есть эта проблема и нет причин быть вежливыми.

Готовы выбрать первый шаг? Расскажите о своей идее, и мы поможем решить, что нужно сейчас: proof of concept, прототип или MVP.