MVP, прототип или проверка концепции: с чего начинать

Основатели часто говорят «MVP», «прототип» и «проверка концепции» (proof of concept) так, будто это три размера одного и того же. Это не так. Каждый из них нужен, чтобы ответить на свой вопрос, и поэтому каждый строится по-своему. Выберите не тот, и вы либо потратите месяцы на то, что не может ответить на ваш вопрос, либо ответите на вопрос, который никто не задавал.

Проще всего различать их так: сначала сформулировать вопрос и позволить ему выбрать инструмент.

Три вопроса, три инструмента

У каждого нового продукта есть три вида риска:

• Технический риск. Можно ли это вообще построить, с нужными данными, интеграциями и производительностью?
• Риск удобства. Поймут ли люди, что это за продукт и как им пользоваться?
• Рыночный риск. Будут ли люди действительно им пользоваться, возвращаться и платить?

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

Проверка концепции: можно ли это сделать

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

У хорошей проверки концепции такие черты:

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

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

Если в вашем продукте нет ничего технически неопределённого (сервис бронирования, маркетплейс, CRM для узкой ниши), этот шаг можно полностью пропустить.

Прототип: поймут ли его люди

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

Детализация прототипов бывает очень разной:

• Бумажные наброски или вайрфреймы, чтобы договориться о структуре и порядке экранов.
• Кликабельные макеты, чтобы проверить сценарий на реальных пользователях в коротких сессиях.
• Фронтенд в коде с фейковыми данными, когда вопрос именно во взаимодействии (сложный редактор, планировщик с перетаскиванием).

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

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

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

MVP: будут ли пользоваться и платить

MVP (minimum viable product, минимально жизнеспособный продукт) означает наименьший реальный продукт, которым реальные пользователи могут пользоваться для реальной задачи. Он хранит реальные данные, работает в продакшене и может принимать деньги, если этого требует модель. Его цель в том, чтобы проверить допущение, которое вернее всего погубит бизнес, обычно о спросе или готовности платить, и проверить его поведением, а не мнениями.

Важны два слова, «наименьший» и «реальный»:

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

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

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

С чего начать

Начинайте с риска, который понимаете хуже всего.

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

Есть два признака того, что вы строите не то. Первый: вы не можете одним предложением сказать, что из этого узнаете. Второй: объём всё растёт, потому что «пользователи будут этого ждать». И то и другое значит, что работа ушла от своего вопроса.

Как три этапа связаны

Когда присутствуют все три риска, этапы обычно идут по порядку, и каждый питает следующий:

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

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

Коротко

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

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