Почему не нужно делать идеальный продукт

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

Сегодня продолжим эту тему: покажу примеры MVP, расскажу об отличии автоматизированных и ручных MVP и расскажу об инструментах, которые помогут в создании первых.

***

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

Немного о смысле MVP

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

Постоянные читатели рассылки знают, что посадочная страница (или по-русски «лендинг») — не MVP. Посадочная помогает понять, нужен ли продукт кому-нибудь, если продукта ещё не существует. MVP же помогает понять, умеете ли вы предоставлять клиенту ценность, которую пообещали на посадочной. Если проще, то:

• Посадочная помогает подтвердить спрос на ценность.
• Прототип помогает подтвердить возможность эту ценность создать.
• MVP помогает понять, что продавая ценность, можно заработать деньги.

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

MVP бывают двух типов: ручные и автоматизированные. Пойдём по порядку и сосредоточимся на первых.

Ручные MVP

Ручные MVP — это когда ценность оказывается клиенту руками. Не буквально, конечно. [твитнуть] У такого MVP две задачи: максимально быстро понять, в чём именно ценность, и убедиться, что за неё готовы платить.

Предполагается, что MVP нужно тестировать на людях. Так вот, не стоит этого делать на друзьях — положительный вывод может быть ложным. Это то, что Илья Королёв из ФРИИ называет false positive — подтасовка результатов, чтобы получить желаемый вывод. Друзья не подходят по трём причинам:

1. Они доверяют вам.
2. Они могут сказать то, что вы хотите услышать.
3. Они могут заплатить просто чтобы вы отстали.

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

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

Uber

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

Если главная ценность — возможность вызвать машину одним тапом, то элементарно отправляем людям сообщение: «Расшарьте свою геолокацию, я приеду и довезу по стандартному тарифу такси». Дальше ждём заказов, возим клиентов и собираем фидбэк.

А если главная ценность в низких ценах? На этот раз ничего не говорим о геолокации, но делаем акцент на лоукост тарифах.

Но это ещё не всё, MVP не готов. У нас ведь 2-sided market — двусторонний рынок, где помимо привлечения клиентов нужно ещё привлекать водителей, которые будут на вас работать.

Окей, найдите 2-3 водителей и выясните, готовы ли они на вас работать. Но согласия водителей мало — MVP можно считать подтверждённым после 10-15 успешных поездок. Не получилось? Собирайте инсайты и думайте.

Airbnb

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

Теперь фотографируем квартиры, и идём их сдавать представителям разных сегментов. Получилось — кайф. Не получилось — сорри, что-то не так с ценностью. Может стоит сделать профессиональные фотки?

KickCompass

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

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

***

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

Но, увы, не всегда есть возможность сделать ручной MVP. Instagram, Facebook, Dropbox — моя фантазия не находит пути донести ценность без кодинга. Что же, тогда в бой идут автоматизированные MVP.

А нужно ли переходить к автоматизации MVP?

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

Нужно стремиться не скорее начать программировать, а быстрее расти. Ищите самый простой и быстрый способ повлиять на метрики, а не самый прогрессивный и навороченный.

Если узкое место, которое препятствует росту — количество менеджеров по продажам, то идите, и наймите больше менеджеров по продажам. Такая тактика гибче и безопаснее с точки зрения рисков.

Автоматизированные MVP

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

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

• Гибкость — чтобы вносить изменения в продукт быстро, и иметь широкий выбор возможностей.
• Простота — потому что чем меньше навыков должно быть у команды для создания MVP, тем лучше.

Telegram

Бот для мессенджера — программа, которая ведёт диалог с пользователем в чате. Они набирают популярность. Во-первых, формат чата — потрясающе естественный способ взаимодействия клиента с бизнесом. Все умеют чатиться, этому не нужно учить. Например, российский стартап Luka попал в Y Combinator, самый известный акселератор в мире, с таким вот чат-проектом.

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

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

«Социальная сеть для туристов» — окей, используйте Slack.

«Поисковик подарков для мужчин» — напишите бота в Telegram.

«Дейтинг для IT-специалистов» — да без проблем, бот поможет.

Решение не самое гибкое, но простое при наличии разработчика в команде и невероятно удобное с точки зрения сопровождения — никаких апрувов от эппсторов.

Bubble.is

Конструктор интернет-сервисов со слоганом «You don’t need to be an engineer». С этой штуковиной человек без навыков программирования может поднять достаточно сложный сервис. И когда я говорю «сложный», я имею ввиду что-то типа Twitter.

Конечно, это не полностью drag’n’drop решение, но при усердии и желании сделать можно практически любой веб-сервис. Резидент #tceh Кирилл Николаев за новогодние праздники сделал на базе Bubble.is проект Fintere.st, не написав ни строчки кода.

Невероятно гибкая среда и достаточно простая, но есть проблема — при разрастании фич начинаешь немного теряться в интерфейсе.

Directual

Резиденты нашего коворкинга сделали потрясающую штуку, которая может автоматизировать кучу процессов в визуальном редакторе. Она похожа на конструктор, где вы формируете условия по принципу «если, то…».

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

Ну и ещё они умеют работать с big data в реальном времени, выстраивать реакции на базе поведения пользователей и прочее. Да, полностью избавиться от разработки не получится — вам точно понадобится программист в команде, но гибкость сервиса зашкаливает.

***

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

Путь стартапа: посадочная —> прототип —> ручной MVP —> автоматизированный MVP —> продукт. Надеюсь, этот материал стал для вас полезным.