Минимально жизнеспособный продукт: строй меньше, учись быстрее

MVP — один из наиболее неправильно понимаемых концепций в стартапах. Вот что это действительно означает, что это не означает и как создать один, который даст вам реальный сигнал.

Термин "MVP" использовался так часто и так свободно, что он почти потерял своё значение. Основатели используют его для описания отполированных v1 запусков, грубых прототипов, целевых страниц и всего между ними. Некоторые используют его как оправдание для отправки чего-то сломанного. Другие используют его как причину продолжать строить вечно ("это ещё не жизнеспособно").

Первоначальное определение — из "Lean Startup" Эрика Риса — точно: MVP — это версия продукта, которая позволяет вам собрать максимальное количество проверенной информации о клиентах с наименьшими усилиями. Это инструмент обучения, а не запуск продукта.

Слово, которое имеет значение: жизнеспособный

Минимальный — не сложная часть. Основатели естественно склонны вычитать функции. Сложная часть — жизнеспособный. Жизнеспособный продукт обеспечивает достаточно ценности, чтобы кто-то действительно его использовал и дал честную обратную связь — или в идеале, заплатил за него.

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

MVP — это тест гипотезы

Лучший способ думать о MVP — это эксперимент с явно сформулированной гипотезой. Прежде чем что-либо строить, запишите:

Если вы не можете чётко сформулировать условие "нет", вы не тестируете гипотезу — вы строите продукт. MVP работает только если вы заранее согласны с тем, как выглядит "нет".

Спектр MVP: от поддельного к функциональному

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

Многие основатели идут прямо к "функциональному MVP", потому что это кажется наиболее законным. Но консьерж MVP — вручную доставлять услугу для 10 пользователей — часто учит вас большему за две недели, чем шесть месяцев строительства. Цель — обучение, не продукт.

Что включить в MVP и что вырезать

Решение по объёму — это где большинство MVP идёт неправильно. Вот структура для включения:

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

Разница между MVP и бета

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

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

Вы можете иметь MVP перед написанием единой строки кода. Вы не можете иметь бета без в значительной степени построенного продукта.

Как узнать, работал ли ваш MVP

Вернитесь к вашей гипотезе. MVP "работал" не потому что люди сказали хорошие вещи, а потому что они выполнили конкретное поведение, которое вы предсказали. Похвалы — не проверка. Обязательства — время, деньги, повторное использование — проверка.

Три сигнала, что ваш MVP проверил гипотезу:

• Пользователи вернулись без подсказки
• По крайней мере один человек заплатил (или обязался платить) без нажима
• Пользователи были сбиты с толку или разочарованы, когда отсутствовала функция — означает, что они планировали на неё полагаться

Три сигнала, что это не:

• Пользователи сказали, что это нравится, но не использовали снова
• Положительная обратная связь была в основном от друзей и семьи
• Вам пришлось обширно объяснять, почему это было полезно прежде чем они поняли