Как правильно спланировать создание MVP - Майкл Сибель

Оригинал видео на английском без субтитров

Меня зовут Майкл, и я работаю в Y Combinator (далее – YC). До этого я уже запускал два стартапа в рамках YC, один в 2007 году, другой – в 2012. И сегодня я хочу поговорить с вами о минимально жизнеспособном продукте, или MVP. Мы постоянно ругаем основателей за использование жаргонов, однако у нас есть целый ряд этих дурацких «стартаповских» словечек, и одно из них – MVP.

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

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

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

Так что если вы запускаете продукт для загадочной группы пользователей и понятия не имеете, кто они, задумайтесь немного. Окей. Итак, цель стартапа перед запуском крайне проста. Шаг один: запускайтесь быстро. Изначально этот пункт был традицией YC. Этот совет был актуален 10 лет назад, и продолжает быть таковым сегодня. Если вы вынести одну мысль из этой презентации, то пусть это будет мысль о том, что запускаться надо дико быстро.

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

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

Поэтому они почему-то считают, что если еще не создали полную версию, то получение отзывов на первую кривую версию бессмысленно. Конечно, это не релиз. Подготовка к релизу потребует потребуется три года, 10 млн. долларов и большую команду. Поэтому отзывы на первую версию, мол, бессмысленны. Реальность же такова, что потрясающую идею нужно держать в голове и помнить о ней, но она при этом оставаться очень гибким, потому что может оказаться, что то, что вы хотите создать – не то, чего хотят ваши клиенты.

Поэтому вот что я скажу: четко решайте поставленную задачу, тесно взаимодействуйте с клиентами, а вот к решению подходите гибко. Последний и очень важный момент: изменяйте продукт постепенно, шаг за шагом, с помощью небольших итераций. Я бы хотел провести границу между итерацией и пивотом. Многие основатели придумав продукт, влюбляются в него. И обнаружив, что он не работает для определенной аудитории, они начинают задумываться: "Ладно, а какие еще проблемы мой продукт может решить? Вот, отвертка, она не очень хорошо закручивает все, но, вдруг, думаю, она может сгодиться для чего-нибудь ещё?.

" И потом начинается: "Можно было бы использовать ее в кулинарии или для уборки." Но нет, проблема-то была в том, что мне надо что-то закрутить, пользователь - слесарь, и если ваша отвертка не помогает ему решить его проблему, то не уходите от слесаря и от задачи закручивания. Если надо что-то закрутить, так сделайте же что-нибудь с отверткой, черт возьми! В ней же дело, не так ли? Проблема не в слесаре и не в том, что ему надо что-то вкрутить.

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

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

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

Первое, что может заинтересовать вас в этом MVP, это отсутствие платежей. Когда вы находили жилье на Airbnb, вы платили напрямую хозяину жилья. Стоит ли говорить, что это было чертовой проблемой, но они начали без платежей! Нет карты. Вам известно, что сейчас когда вы ищете жилье на Airbnb, вам видно, где оно находится. А тогда этого не было. Парень, написавший код, работал на полставки.

И? То есть все рассказывают чудесные сказки о том, как все было идеально с самого начала. Airbnb таковым не был! Следующий пример - Twitch. Вот так он выглядел в первый день запуска, не очень-то знакомый вид. Может быть лишь чуть напоминает. В этом блоке было видео, здесь находился чат, не такой, как сегодня, больше ничего. Twitch запустился как Justin.tv, в качестве онлайн реалити-шоу.

с одним каналом, Джастин, и вам предлагалось следить за его жизнью. Если вам не нравилась его жизнь, то оставалось только покинуть сайт. Это все, что там было. Видео было в очень низком разрешении. Было забавно, когда основатель другого проекта спросил меня однажды: "А вам не было странно находиться под видеонаблюдением в своем доме? Вас не смущало, что личные документы и вещи могли видеть чужие люди?" И я такой: "Вы едва ли можете рассмотреть моё лицо, не говоря уже о документах.

" А самое главное – там не было видеоигр. Ни одной, только если мы решали поиграть в них дома. Это были единственные случаи, когда они появлялись в проекте. Этим я хочу сказать, что вы можете запускаться быстро. Если мы рассмотрим Twitch, сейчас он более сложный. Последний пример - Stripe, который сначала не был Stripe, он назывался /dev/payments, поскольку почему бы и нет? Давайте сделаем поистине запоминающееся название.

Вот так выглядел Stripe в момент запуска, никаких банковских сделок. Я не могу сказать, как они именно они обрабатывали платежи, но это происходило "по-стартапски". Практически никакого функционала. И даже круче: если вы хотели воспользоваться Stripe, его основатели приходили в ваш офис, чтобы интегрировать его для вас. Ну не круто ли? Отчасти они делали это, потому что были в отчаянном поиске кого-нибудь, кто воспользовался бы их продуктом, отчасти потому что это был хороший способ найти баги до того, как их найдут пользователи, и устранить их.

Это всего лишь три примера очень простых и быстрых в запуске MVP. И все они – нынешние единороги (с оценкой более $ 1 млрд) Все они начинали с того, что большинство людей назвало бы построенным из говна и палок. Существует всего несколько ситуаций, в которых потребовался бы "тяжёлый" MVP. Я придумал этот термин, когда делал эту презентацию - "тяжёлый (толстый) MVP" и, может, его станут использовать.

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

Возьмем биотехнологии: сложно создать лекарство от рака за несколько недель. Полеты на Луну? Что ж, заполните все эти бланки. Сложно прорубать тоннели в земле и заменить автомобили другим супер- быстрым транспортом за пару недель. Если вы в подобной ситуации, пожалуйста, помните, что ваш MVP может быть запущен с простенького вебсайта, который бы объяснил, чем именно вы занимаетесь.

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

Они видят, как делают релизы крупные компании и думают, что стартапы поступают так же. На самом деле, они смотрят на компании, которые они думают, что являются стартапами. Facebook уже давно не стартап, но основатели видят, что вокруг него много прессы, и разговоров, и бла-бла-бла. Таким образом у них возникает впечатление, что успешная компания при запуске так и выглядит.

Что ж, позвольте вас спросить: многие ли помнят день запуска "Google"? Нет. А как насчет "Facebook"? Ладно. А "Twitter"? Нет. Отлично. И мы видим, в их запусках не были ничего особенного. Если вы верите в сказку о незабываемом запуске отбросьте ее, не такое уж это и волшебство. Самое важное – это привлечь немного клиентов. Чтобы упростить, давайте немного поменяем термины.

Что если "запускаться" будет означать "привлечь каких-нибудь пользователей"? А пресс-релиз, пресс-показ (звучит впечатляюще!), это когда люди пишут о продукте, как это все прекрасно, и вы получаете всю эту шумиху? Давайте отбросим пресс-показ и как можно ближе придвинем привлечение клиентов. На этом этапе это наша цель. Намного сложнее узнавать что-то от пользователей, когда у них нет продукта, с которым бы они поигрались.

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

Наконец, приведу несколько хаков для быстрого создания MVP. Во-первых, определите временные рамки для создания функционала, необходимого для запуска. "Что если я хочу запуститься через три недели? Так-так, тогда все, что есть в спецификации, должно быть построено за три недели". Это упростит вам жизнь, позволит поубирать все те функции, которые вы не сможете сделать за три недели.

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

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

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

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

Что ж, на этом все, у меня есть немного времени, чтобы ответить на вопросы. Вопросы есть? Отлично, вопросов нет. Я общаюсь с пользователями из нескольких сегментов, и, конечно же, один хочет вот это, а другой хочет вон то. И их количество такое незначительное, что непонятно, как... Что... Отличный вопрос! Вы общаетесь с клиентами, и им нужны те вещи, которые вы собираетесь создать, но между ними мало совпадений? Я дам вам некий мета-ответ: никогда не спрашивайте клиентов о деталях.

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

Ответы на эти вопросы мы должны получить сами. Как только заметите, что собеседник начинает говорить про функционал: "Мне вот нравится Microsoft Word, но хоть бы кто-нибудь смог бы сделать что-то, что позволит мне бла-бла-бла", - вам тут же надо вернуть разговор в нужное русло. "Ах, ты хочешь бла-бла-бла? А в чем проблема? Как часто ты сталкиваешься с этим?". И вновь надо вернуться к обсуждению проблемы.

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

Так вот стоит ли мне выпить успокоительного и придерживаться первоначального плана, остановиться и спросить себя: "Ладно, оправдано ли это изменение?" Ах да, простите. Вопрос такой: я застряла в этом порочном круге постоянных доделок MVP и не могу запуститься. Я вижу, что есть много людей, которые также застряли, и существует много проблем в стартапах, которые можно решить просто перестав делать то, что делаешь.

Просто остановитесь. Вам не нужно без конца улучшать MVP. Возможно, вы постоянно его меняете, потому что считаете его особенным. Если бы вы так не думали, вы бы перестали его менять, вносить бесконечные правки. Я не понимаю, сэр. Объясните еще раз. Когда вы считаете MVP особенным, вы думаете, что он должен быть идеальным. Если вы считаете, что он должен быть идеальным, вы долго возитесь с ним.

А если вы решите, что он будет дерьмовым... Если вы подумаете: "Так, я хочу найти рубашку в шкафу, которую бы разрисовал и потом выбросил", – вы не будете тратить время на то, чтобы подогнать эту рубашку, так? Скажем, мы запускаем MVP и ждем отзывов. О каких ключевых моментах мы должны спросить наших [неразборчиво]? Это очень простой вопрос. Что именно вы хотите узнать, когда хотите получить отзыв об MVP? Решает ли он проблему, которую я хотел решить? И все.

Вы можете найти 80 разных способов задать этот вопрос, но если вы четко понимаете задачу, которую решаете, значит и так все понятно... Часто вам даже не приходится спрашивать. Если продукт перед клиентом, вы можете увидеть, использует ли он его, как вы задумывали, или нет. Зачастую вы можете понять это из чисел. Если это проблема, с которой человек сталкивается каждый день, и вы представили клиентам ее решение, вернулись ли они на следующий день? Я не знаю ни одного продукта, который решал бы повседневные проблемы раз и навсегда, и клиент бы больше продуктом не пользовался.

Здесь множество странных нюансов, которые играют важную роль. То ли делает клиент? Решает ли он ту задачу, которую вы думаете, он должен решить? Еще вопросы? На задних рядах? Как долго должен существовать MVP? Допустим он начинает развиваться и что дальше? Вы знаете, чем забавны стартапы? Я не люблю думать о временных рамках, и я не думаю о план-графиках.

А для людей, которые находятся в стадии предзапуска MVP - кто знает? начните, и вы сами разберётесь. Вы решили запустить стартап, и одна из его особенностей это то, что путь из пункта А в пункт Я может быть неясен. Если вы ориентируетесь только по пунктикам, типа "MVP – это пункт Б, я фокусируюсь на В и Г," – Я вам скажу: "Эй, а почему бы для начала не решить саму проблему, которая прямо у вас перед носом?" Например, как вы находите баланс между улучшением MVP для удержания пользователей и попытками найти новых потенциальных пользователей и лидогенерацией в контексте своей проблемы? А после MVP? Работать над ростом или над удержанием клиентов? Люблю этот вопрос, он самый забавный из всех, так как позволяет мне дать на него смешной ответ.

И то, и другое. Да. Вот что происходит: многие основатели понимают, что их стартап-это комплексная проблема, а такие проблемы сложно решать, и они пытаются свести их к решению одной задачи. Поэтому они спрашивают своего тайного советника: "А что важнее - развиваться или держать уровень?" Все равно что спросить, что важнее принять душ или сходить по-большому? Сделайте и то и другое.

Простите, но оба аспекта важны. Как основателю вам приходится жонглировать различными вещами. Так? Ладно. Позвольте поделиться историей о стартапе, основатели которого не общались с конечными пользователями, так как они не хотели говорить о проблеме. Как с этим быть? Уточним: вопрос в том, как общаться с клиентами, если они не хотят говорить о проблеме? А вы не скажете, что за проблема? Диабет второго типа.

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

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

Не важно, кто ее будет читать, он ответит на ваш вопрос. Хорошо, спасибо. Мой вопрос в том, какого дохода или уровня привлекательности необходимо достичь, перед тем как... Я перефразирую вопрос: как узнать, вписывается ли ваш продукт в рынок? Хорошо. Типичный, и при этом верный ответ, не любимый основателями таков: если вы это спрашиваете, значит ваш продукт пока не соответствует рынку.

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

Я в убытке. И на следующей неделе я тоже буду в минусе. Я почти уверен, что мы закроемся, потому что у нас слишком много клиентов". И вот что забавно: когда я это представляю в таком свете, не составляет труда понять, в такой ли вы ситуации находитесь или нет. А самое ужасное, что практически никто не достигает полного соответствия продукта рынку. Практически никто.

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

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

Вы можете провернуть одну забавную вещь. Спросите их: "Эй, а вы знаете кого-нибудь еще с точно такой же проблемой?" Любая проблема, если вернуться на исходную, и вспомнить о представлении, которое было о ней у основателя, может распасться на целый набор подпроблем. Я считаю, что люди лажают со своими MVP из-за того, что они видят своей проект большим, они не готовы презентовать его маленьким.

Им кажется, будто они не удовлетворяют потребности всех потенциальных пользователей, и поэтому каким-то образом не справляются. Есть много вещей, которые должен решить стартап или сам основатель. Решая их, надо держать в голове сразу две вещи. Ведь так? Мечта, видение – большое, а MVP – маленький. Развивайтесь, но не забывайтесь. Мы много говорим в YC об одном и том же: Презентации для вашего инвестора и для вашего клиента – две абсолютно разные вещи. А основатели постоянно хотят слепить их вместе, или избавиться от одной из них, так как намного проще думать об одной задаче.

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

Хорошо, еще один вопрос. Слушаю вас. Если рассматривать фармацевтику, то моими клиентами будут другие ученые или сами пациенты? Кто ваши клиенты в фармацевтике? Я думаю, что вы должны задать этот вопрос себе. Вы основываете компанию, вы знаете, что вы строите, вы знаете проблему, вы её решаете, и вы знаете, кто с ней сталкивается. Я не знаю ничего из этого.

Хорошо. Было здорово поболтать с вами, большое спасибо!