27.04.2022

MVP для MVP. Как без прототипа проверить гипотезу о продукте.

В своей практике я сталкивался с необходимостью проверить гипотезу внутри компании или о новой фиче продукта. Довольно часто у меня появляются различные идеи продуктов или сервисов. Но не всегда рационально сразу прибегать к созданию прототипа (MVP, Minimum Viable Product), затрачивая время и ресурсы. Тем более, проверка той или иной гипотезы не должна занимать больше 4х недель.

Материал ниже является моим переводом статьи на firstround.com за авторством Gagan Biyani. Вот ссылка на оригинал статьи.

Этот материал о том как проверять гипотезы и риски, избегая трат ресурсов на создание прототипов, и как обрести уверенность в том, что вашу идею оценят пользователи, на основании тестов. Материал объемный, так что я разделил его на 2 части.

Часть 1.

Данная статья написана Gagan Biyani, со-основателем и руководителем компании Maven, помогающей мировым экспертам проводить групповые учебные курсы. До прихода в Maven автор был основателем Udemy и Sprig. Больше информации от автора по ссылке.

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

В своей карьере я работал с самой ранней стадии в 4 стартапах: Udemy, Lyft, Sprig и Maven. Три из них подняли около 1м$ на развитие в первые шесть месяцев существования. Я не думаю, что это случайность. Я считаю, что этот ранний успех мог быть предопределен еще до того как напишется первая строка кода.

И всё потому что мы не начинали с создания MVP и тестирования его на рынке.

Вместо этого, мы начинали с тестов определенных гипотез о рынке, на который планировали выходить. Мы оценивали правдивость гипотез индивидуально, используя Minimum Viable Tests (MVT, минимально жизнеспособные тесты). В совокупности эти тесты позволяли нам еще перед тем как запустить и предложить пользователям Minimun Viable Product, MVP (минимально жизнеспособный продукт) предопределить, оценит ли рынок наш продукт.

Есть множество определений MVP. Мое определение такое: MVP – это базовая ранняя версия продукта, которая выглядит и ощущается пользователями как упрощенная версия конечного видения. MVT, напротив, не пытается выглядеть как конечный продукт. Это скорее специфический тест предположения, которое должно сработать чтобы бизнес стал успешным.

Создавая MVP, вы пытаетесь имитировать целую машину. Используя MVT, вы тестируете, будет ли трансмиссия передавать больше мощности с электрическим двигателем или с двигателем внутреннего сгорания.

Процесс работы с MVT имеет большое влияние на то, как создается компания. В MVP методологии, вы создаете MVP, смотрите на то, как он работает, и постепенно проводите его итерации пока не находите product/market fit (соответствие продукта рынку). Мне кажется, вместо этого намного эффективнее было бы запустить несколько MVT, создать видение продукта, который подходит рынку, и после этого перейти к фазе создания.

В MVP методологии нет четкой стратегии: вы просто тестируете идеи, пока одна из них не сработает. В методологии MVT вы тратите время на исследование и разработку стратегии, а создав ее, уверенно двигаетесь вперед. Двигаясь вперед с уверенностью, вы более соответствуете реалиям стартапов: понадобится от 2 до 4 лет, чтобы подтвердить или опровергнуть гипотезу.

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

Доводы против MVP

Мне нравится идея MVT, потому что методология MVP толкает основателей к созданию чего-то лишнего. Как инвестор и консультант около 30 компаний, а также преподаватель курса по созданию и оценке стартапов, я видел как основатели допускали десятки ошибок находясь в фазе pre-product/market fit. Приведу несколько примеров:

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

Создатели продукта любят думать о том, что может произойти: они мечтают о том, как продвижение их продукта на рынок может изменить мир. Это правильный посыл, но важно осознавать свои реальные возможности. Новые продукты успешны не потому что предлагают широкий спектр фич. Facebook* успешен не потому что позволяет людям создавать группы, организовывать мероприятия или постить фото своих собачек в ленту. Facebook* успешен благодаря одному ключевому инсайту: люди хотят быть на связи с друзьями и близкими онлайн. Нельзя иметь 20 инсайтов и быть успешными - необходимо иметь один ключевой инсайт.

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

Второе, основатели слишком сфокусированы на том, что говорят пользователи.

Пользователи не знают, каким должен быть продукт. Это факт, и неважно кто эти пользователи. Люди (включая меня) не могут с абсолютной! честностью оценивать себя со стороны - и поэтому не знают, что хотят и как принимают решения. Все научные материалы о поведенческой экономике были разработаны в виду предопределенной иррациональности покупателей. Более того, пользователям нет дела до будущего индустрии, в которой основатели создают продукты. Они всегда говорят, что хотят просто «лошадь побыстрее», хотя на самом деле им нужен автомобиль. Поэтому полагаясь при построении продукта на пользователей и на то, что они говорят вам, вы неизменно будете внедрять пошаговые изменения вместо того, чтобы создать инновационный продукт.

Третье, основатели слишком увлечены созданием компании, перед тем как нащупать product/market fit.

Создание компании вторично по отношению к созданию ценности. Я удивляюсь, как много людей спешат заказывать мерч кампании, кружки, ручки, придумывать название компании, нанимать команду, искать инвестиции или придумывать логотип компании перед тем как понять, как и кому они будут доносить ценность. За исключением случаев, когда это необходимо, не стоит называть и идентифицировать себя как CEO или основатель. (Иногда для того, чтобы общаться с инвесторами или нанимать специалистов я использую статус CEO или основателя в документах или переписках, но только для перечисленных целях. Я не хочу представляться в соцсетях СЕО, не хочу чувствовать себя им, пока компания не начнет показывать результат).

У меня есть правило: никаких корпоративных плюшек, пока бизнес не достигнет хотя бы 250тыс $ дохода или 250тыс. пользователей. Пока это не произошло, нельзя почувствовать никаких выгод от создания компании. Ты – никто, пока у тебя нет покупателей, которым нужен твой продукт.

Подписывайтесь на качественные статьи
про SMM & digital
Четвертое, слово "продукт" в MVP подразумевает опыт, имеющий определенную форму.

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

И наконец, MVP часто приводят к созданию плохих продуктов.

Создавая продукт, начинаешь с чистого листа. Приступая к написанию кода, создаете и создаете набор фич продукта. Я знаю много стартапов, которые тратят много времени потом на то, чтобы инженеры переделывали то, что было написано ранее. Вместо этого, я предлагаю запустить тест MVT и потом удалить весь код (а лучше не использовать код вообще). Это позволит начать с чистого листа при создании долгосрочного видения продукта.

Смысл в том, чтобы фокусироваться на достижении стадии product/market fit в pre product/market fit стадии, а после этого осознанно двигаться в сторону фазы создания прототипа продукта.

Добавление MVT в процесс создания стартапа:

Если посмотреть на мой опыт в предыдущих компаниях, я всегда начинал с определенных шагов:

  • Погружение в новую индустрию
  • Использование CustDev для определения работ, которые должны быть сделаны по JTBD-методологии и какие продукты они в настоящее время нанимают на эти работы
  • Определение обещания в виде продукта, который можешь создать, чтобы помочь пользователям с их работами по JTBD-методологии
После этих шагов многие начинают создавать первоначальную версию продукта (MVP), чтобы протестировать его на нескольких пользователях. Я думаю, здесь и кроется ключевая ошибка. Вместо создания полноценного MVP, я предлагаю применить MVT-фреймворк:

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

И только проверив достаточно гипотез и почувствовав уверенность в жизнеспособности продукта, можно переходить к следующим шагам:

  • создайте первоначальный продукт, в котором содержатся все инсайты, и тестируйте их на целевой аудитории
  • проводите итерации продукта, пока не достигните product/market fit
  • фиксируйте цифры и анализируйте!
Остальная часть статьи будет посвящена стратегии MVT и объяснениям, как и где ее применять.

Что такое Минимально Жизнеспособный Тест MVT?

MVT – это тестирование основной гипотезы, которая должна быть правильной, иначе у будущего стартапа не будет шансов на успех. Например, в моей текущей компании Maven основная гипотеза заключается в том, что люди находят в десятки раз полезнее прохождение курсов и тренингов в живой группе, вместо персональных, несинхронных онлайн курсов. (Чуть ниже, я объясню, как мы собрали и протестировали эти гипотезы, а пока поверьте на слово)

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

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

Если фокусироваться на MVT вместо MVP, становишься ближе к ключевому вопросу: Можно ли предопределить успех перед запуском продукта? Я считаю, что ответ – да. С правильным подходом можно предопределить шансы на успех и сократить (но не исключить) вероятность провала.

Ниже я опишу механизм того, как создаю и выполняю эти тесты.

Три шага процесса тестирования MVT.

Итак, описанные выше шаги 1-3 уже позади: вы погрузились в новой индустрии и определили возможность. Вы стали лучшими друзьями со своими целевыми покупателями. Вы мечтаете как они, думаете как они. Вы знаете их проблемы изнутри и снаружи. Отлично. Теперь вы генерируете идеи о решении, которое, по вашему мнению, поможет решить их проблему. Как узнать, что этот продукт "тот самый"?

Всё просто: проведите тестирование. Это то, о чем я говорю в 4 и 5 шагах выше. Это то, что отличает мой подход от того, что большинство ожидает увидеть. Следующие шаги детальнее объясняют, что я думаю об этой части процесса:
Найдите свое ценностное предложение. Определите обещание своей идеи. Почему пользователи должны захотеть ваш продукт? Что вы им обещаете?

Фокусируйтесь на действиях.

Это всегда основано на CustDev (исследовании аудитории), но помните, что клиенты не всегда знают и не всегда говорят открыто о своих желаниях и потребностях. Их действия, однако, говорят сами за себя. Найдите ценностное предложение, которое обращается к их действиям: Что на самом деле они пытаются сделать? Как ваш продукт может помочь им достигнуть своих целей лучше, чем они сами думают?

Избегайте слишком сложных идей.

Подумайте о таких компаниях как Stripe, AirBnB, Dropbox, Uber. Каждая из этих компаний имела до смешного простое ценностное предложение. Решение у них могло быть комплексным или противоречивым, но ценность для пользователей всегда была проста. Кто откажется от такси, которое приедет через 5 минут? Кто откажется от одной строчки кода и предпочтет потратить несколько дней на подключение комплексной системы оплаты? Найдите ценностное предложение, которое просто как грабли.
Выпишите все предполагаемые риски. Составьте список основных рисков: почему проект может не сработать? Что ломает систему?

Самое главное среди предполагаемых рисков это создание чего-то, что людям не нужно. Все об этом знают. Это девиз в Y Combinator. Тем не менее, почему-то около половины основателей, с которыми я встречаюсь, не включают в первую тройку предполагаемых рисков своего бизнеса такое понятие как «людям это нужно».

Риск воплощения идеи в реальности. Многие крутые идеи не выживают просто потому, что не могут быть реализованы в реальности. Я помню как слушал питч про облачные технологии хранения данных, которые на 1/10 дешевле чем Dropbox. Если бы это работало, компанию ждал бы огромный успех. К сожалению это был просто концепт, который невозможно реализовать. Важно определить риски, связанные с осуществимостью исполнения вашей идеи.

Маркетинг. У многих основателей есть хорошая идея, но они не знают, как ее продавать. Опытные основатели знают, что не стоит даже заморачиваться идеей, если она непригодна для продажи. Маркетинг-риск заставляет взглянуть правде в глаза: знаешь ли ты достаточно о рынке, чтобы понимать, как это продавать и кто это будет покупать? Есть ли хоть какая-то рабочая (реалистичная) стратегия выхода на рынок, или это самая сложная часть бизнеса (и поэтому ее нужно протестировать в MVT в первую очередь?)

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

Прибыль. Почти все стартапы начинают с перевернутым графиком маржинальности. Это нормально, но некоторые компании никогда не выйдут на положительную маржинальность. Продавая продукт за треть стоимости его реализации это быстрый способ сжечь весь бюджет и закрыть компанию. Продавая продукт за 80-90% о стоимости реализации уже немного лучше. Выясните, какую цену готовы платить потребители по отношению к стоимости реализации и доставки вашего решения.
Тестируйте атомную единицу. Определите, действительно ли ваша идея работает. Фокусируйтесь только на "атомной единице" того, что планируете продавать. Для Google, атомная единица это поисковый запрос. Для Amazon, это заказ книги онлайн. Для Coinbase, это легчайший путь к покупке и продажи крипты.

Выберите предполагаемый риск и тестируйте по одному. Почти всегда получается проверять 2-3 предполагаемых риска за раз, но всегда должно быть основной риск. В противном случае точных результатов не получить.

Разработайте тест для основного предположения. Если самый главный предполагаемый риск – это риск реализации, тестируйте реализацию, пытаясь предлагать конечный товар или сервис потребителю всевозможными хитрыми способами. Также, не забудьте оценивать коэффициент прибыли. Так станет понятно, что будет действительно сложно, а что – легче, чем ожидали. С этого момента можно создавать второй и третий тесты с целью погрузиться в специфику области изучения или зону беспокойства. Если ваш самый главный предполагаемый риск заключается в том, нужен ли людям будет ваш продукт, не спрашивайте их об этом. Заставьте их заплатить за продукт своим временем или деньгами. Если они не заплатят, будьте честны с самим собой и разбирайтесь в причинах, а потом проводите итерации, пока не найдете людей, которые влюбятся в ваше решение.

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

Выберите прозрачную и специфичную атомную единицу. Чем больше ниша, тем в данном случае лучше. Нужно найти наименьшую возможную единицу, до которой можно сжать ваш продукт. Эта единица важна, потому что пользователи редко покупают ценностное предложение компании; они покупают продаваемую специфическую единицу. Возьмем Amazon. В 1994 никто не говорил: "Как я мечтаю о большом интернет магазине, где я могу купить все что захочу." Об этом могли подумывать предприниматели, но не потребители. Вместо этого потребители говорили: "Я заинтересован в покупке книги Х, которую я не могу найти ни в одном книжном магазине. Где я могу ее найти?" В этом случае потребителю неважно, находится ли магазин в интернете или нет! Поэтому атомной единицей для Amazon мог быть даже телефонный сервис, где можно получить помощь в поиске и покупке любой книги.
Подписывайтесь на качественные статьи
про SMM & digital