Продвижение SaaS-продуктов
Гаган Бияни, сооснователь таких успешных стартапов, как Udemy, Sprig и Maven, рассказывает, почему не работает популярная стратегия MVP и как предсказать успех стартапа, не написав ни строчки кода.
Содержание
В мире стартапов есть такая догма, что невозможно предсказать, зайдет людям ваш продукт или нет. Поэтому принято действовать по определенному алгоритму: сначала вы проводите исследование клиентов, а потом как можно быстрее запускаете MVP (минимально жизнеспособный продукт) — и надеетесь, что он выстрелит. Но я действую по-другому.
Содержание
На протяжении карьеры мне довелось поработать в четырех стартапах на ранних стадиях их формирования. Это были Udemy, Lyft, Sprig и Maven. Три из них нам удалось вывести на прогнозную годовую выручку (run-rate) более 1 миллиона долларов в первые шесть месяцев с момента запуска.
Совпадение?
Не думаю.
Я уверен, что стремительный успех этих проектов можно было предсказать еще до того, как были написаны первые строчки кода.
Все потому, что мы не шли по стандартному алгоритму: попытаться создать продукт и протестировать его на рынке.
Вместо этого мы тестировали определенные гипотезы о рынке, которые у нас были. Причем каждую конкретную гипотезу мы оценивали отдельно — при помощи минимально жизнеспособных тестов (Minimum Viable Tests, MVT). На основании этих тестов мы могли предсказать, примет ли рынок наш продукт, еще до этапа запуска MVP.
Вы читаете перевод статьи The Minimum Viable Testing Process for Evaluating Startup Ideas от Гагана Бияни (X, Linkedin), сооснователя и действующего CEO Maven, платформы для синхронного группового онлайн-обучения, а в прошлом — основателя таких сервисов как Udemy и Sprig. Источник изображения: https://techcrunch.com/
Есть много разных определений MVP. Я предпочитаю такое: MVP (минимально жизнеспособный продукт) — это ранняя, базовая версия продукта, которая выглядит и работает как упрощенный вариант итогового решения. Что касается MVT (минимально жизнеспособного теста), он и не задумывается как версия итогового продукта. Скорее, MVT — это тест конкретного предположения, которое должно соответствовать действительности, чтобы у бизнеса были шансы на успех.
Создать MVP — это как создать симуляцию машины целиком. Провести MVT — это протестировать, с каким двигателем эффективнее работает трансмиссия: с электрическим или с газовым.
Процесс минимально жизнеспособного тестирования (MVT) может сильно повлиять на то, как будет развиваться ваша компания. Методология MVP подразумевает, что мы разрабатываем минимально жизнеспособную версию продукта, оцениваем реакцию рынка и начинаем медленно доводить MVP до ума, пока продукт не достигнет соответствия рынку (product-market fit). Я уверен, что гораздо эффективнее начать с серии MVT — чтобы сначала сформировать видение продукта, который уже соответствует рынку — и только потом переходить к фазе разработки.
Стратегия MVP — это отсутствие стратегии: вы кидаете разные штуки в стену, пока что-то не прилипнет. Если примените подход MVT, вам потребуется больше времени на формирование стратегии, но дальше вы сможете с уверенностью двигаться вперед. Эта уверенность особенно актуальна в реалиях стартапов: ведь на проверку своего решения у вас уйдет от двух до четырех лет.
Интересуетесь свежими материалами по продвижению SaaS-продуктов?
Подписывайтесь на канал Secret Growth в Telegram
В этой статье я расскажу, как традиционный MVP-подход может сбивать с толку основателей компаний, а также опишу свой трехэтапный фреймворк создания минимально жизнеспособного теста (MVT) и приведу несколько примеров из своего профессионального опыта. Надеюсь, что мои идеи покажутся вам полезными, независимо от того, есть у вас конкретная идея стартапа или вы пока только мечтаете основать свою компанию.
Идея минимально жизнеспособных тестов (MVT) так близка мне, потому что концепция MVP заставляет людей вкладывать много лишних сил в разработку. Я выступал инвестором и консультантом более 30 компаний и даже проводил курс о том, как создавать и оценивать идеи стартапов — и, поверьте, я видел, как основатели компаний совершают массу ошибок еще том на этапе, когда продукт даже не достиг соответствия рынку (product-market fit). Вот несколько примеров ошибок, которые допускают люди в рамках стратегии MVP.
Создатели продуктов любят рассуждать о возможностях: они мечтают, как их продукт выйдет на рынок и изменит мир. Вообще настрой нормальный, но на начальных этапах стоит немного умерить пыл. Новые продукты не покоряют рынок обилием функций. Facebook выстрелил не потому, что люди хотели создавать группы, делать анонсы событий или выкладывать фотки своих собак. Facebook добился успеха благодаря ключевому инсайту: люди хотят взаимодействовать с друзьями и членами семьи в онлайне. Невозможно заложить в продукт 20 инсайтов и добиться успеха — нужно сосредоточиться на одном.
Когда вы создаете MVP, то стараетесь продумать те самые 20 функций, которые могут понравиться людям на рынке. Вы распыляетесь и смещаете фокус с одного единственного инсайта, который действительно важен клиентам. Помните: ясность порождает успех.
Клиенты — кем бы они ни были — понятия не имеют, каким должен быть ваш продукт. Люди (и я, в том числе!) не видят себя со стороны — поэтому не понимают, что им действительно нужно, и как они на самом деле принимают решения. На почве того, как предсказуемо иррационально ведут себя клиенты, возникла целая область исследований — поведенческая экономика. И тем более клиентов не волнует развитие вашей отрасли. Они всегда будут просить “более быстрых лошадей”, хотя на деле их потребности удовлетворит машина. Поэтому, если вы слишком ориентируетесь на то, что говорят клиенты, будьте готовы, что ваш продукт будет лишь очередным улучшением — а не радикальным прорывом.
Сначала нужно обеспечить ценность — а потом создавать компанию. Удивительно, как часто люди начинают не с того конца: они придумывают имя компании, нанимают команду, привлекают инвестиции и дизайнят логотип прежде, чем определиться: как и кому они будут давать ценность. Советую не привязываться к названиям, логотипам и титулам (основатель, CEO и т.п.) — за исключением случаев, когда это необходимо с практической точки зрения. Например, когда я привлекаю инвестиции или ищу сотрудников, мне иногда приходится сопровождать свое имя титулом “CEO” или “сооснователь”. Но я никогда не козыряю этими ярлыками в социуме — как минимум до момента, когда у компании появятся какие-то значимые результаты.
У меня есть правило: никакой мишуры, пока бизнес не выйдет на выручку от 250 тысяч долларов или не наберет 250 тысяч пользователей. Только по достижении подобных результатов вы сможете прочувствовать, что это такое — основать компанию.
Допустим, вы создаете MVP. Вы наметили предполагаемый клиентский путь (user journey) и сузили его до самого минимума, с которым можно запускаться. В большинстве случаев этот минимум — на деле совсем не минимум. В него может входить система авторизации, стек технологий, база данных и иногда даже админский дашборд. Также потребуется продумать пользовательский опыт и добавить какой-то процесс онбординга. Как результат, в MVP будет вложена куча работы. А начинать нужно не с этого. Систему авторизации и онбординг нужно прорабатывать лишь после того, как вы удостоверитесь, что ваша идея будет продаваться. А чтобы в этом удостовериться, достаточно провести минимально жизнеспособный тест.
Создание продукта начинается с пустой командной строки. Как только вы начинаете писать код — начинает копиться ваш технический и продуктовый долг. Я знаю множество стартапов, которые, начиная со второго по четвертый год жизни проекта, половину времени разработки тратят на покрытие этого долга. Я же предлагаю вам провести минимально жизнеспособные тесты — и удалить весь созданный код (а еще лучше, протестировать свои гипотезы вообще без кода!). С таким подходом, когда дело дойдет до проработки долгосрочной версии продукта, вы начнете с чистого листа.
Суть в том, чтобы сначала сосредоточиться на достижении product-market fit, а уже потом — с уверенностью — переходить на стадию разработки.
Если проанализировать весь мой прошлый опыт, я всегда начинал процесс создания своих стартапов с одних и тех же шагов:
По прохождении этих шагов многие начинают создавать первоначальную версию продукта (MVP), чтобы протестировать ее на небольшой группе пользователей. И именно здесь, как я думаю, кроется ошибка. Вместо того чтобы создавать полноценный MVP, я предлагаю для начала пройтись по фреймворку минимально жизнеспособных тестов (MVT):
Повторяйте эти шаги и собирайте информацию, пока не будете достаточно уверены, что самые крупные ваши гипотезы не несут в себе значительных рисков. Если вы подойдете к вопросу серьезно и взвешенно, то, скорее всего, выявите больше одного риска. В этом случае вам потребуется провести целую серию MVT — прежде чем вы будете достаточно уверены в своей идее, чтобы запускать MVP.
И только когда вы протестируете достаточно гипотез и заручитесь достаточной уверенностью в жизнеспособности своего продукта, переходите к следующим шагам:
Далее в статье мы разберем стратегию MVT, и я объясню, как и когда следует использовать минимально жизнеспособные тесты.
Минимально жизнеспособный тест — это тест ключевой гипотезы, то есть того вашего предположения, которое должно соответствовать действительности, иначе у компании нет никаких шансов на успех.
К примеру, в случае с моей компанией Maven, нам нужно было убедиться, что люди видят в групповых синхронных курсах (cohort-based course) в 10 раз больше пользы, чем в индивидуальных асинхронных. (Ниже я расскажу, какие гипотезы мы сформулировали в этом кейсе и как их тестировали. А пока следуйте за моей мыслью, не вдаваясь в детали).
Суть минимально жизнеспособного тестирования (MVT) в том, чтобы сформулировать несколько гипотез о рынке, и придумать тесты только для проверки этих гипотез — не заморачиваясь долгосрочным видением, мнениями клиентов и вопросами создания компании или продукта. Этот метод предполагает, что вы будете предельно минималистичны в своих первоначальных тестах: потому что ваша цель — сэкономить время и максимально отшлифовать свое видение первоначальной версии продукта.
Эта философия подходит всем: как техническим фаундерам, так и нетехническим — и даже руководителям компаний, которые не подходят под определение стартапа. Вот вам один привлекательный аргумент “за” MVT: философия MVT подразумевает, что вы можете создать успешную компанию без технического бэкграунда. На самом деле я почти всегда тестировал свои идеи этим методом, прежде чем привлекать технического сооснователя. И это очень ценно, потому что технические директора и сотрудники всегда в дефиците. Вам будет проще привлечь интересного вам технического специалиста, если вы сможете сказать: “Я уже провел несколько тестов, которые доказывают, что спрос на продукт есть” — вместо: “Я планирую нечто грандиозное!” Инженеры любят данные и доказательства, а не пыль в глаза и воздушные замки.
Стратегия MVT позволяет ближе подобраться к центральному вопросу: Можно ли предсказать успех до запуска? Я уверен, что ответ — да! С правильным подходом можно очень точно предсказать свои шансы на успех и снизить (а то и вообще исключить) вероятность провала.
Ниже я в деталях расскажу, как создаю и провожу минимально жизнеспособные тесты.
Итак, вы прошли первые три шага, описанные выше: вы погрузились в свою индустрию и увидели возможность. Вы подружились со своими целевыми клиентами. Вы думаете так же, как они; вы мечтаете о том же, о чем мечтают они. Вы знаете их проблемы вдоль и поперек. Отлично! Теперь вы придумываете конкретное решение, которое, по вашему мнению, решит их проблему. Как вам узнать, что возможность, которую вы увидели — “та самая”?
Ответ прост: проверить. Этому посвящены шаги 4 и 5, которые я предлагаю пройти, прежде чем создавать MVP. Этим мой подход отличается от других. В рамках следующего пункта, добавим для удобства еще один шаг. Итого мы рассмотрим три шага, из которых складывается процесс минимально жизнеспособного тестирования:
Определитесь, какое обещание вы даете клиентам в рамках своей идеи? Почему оно заинтересует ваших пользователей?
Сконцентрируйтесь на действиях. Обычно ценностное предложение обретает свою форму в процессе кастдева (исследования потенциальных клиентов).
Подробнее о методике и этапах кастдева (customer development) читайте в статье.
Однако помните: клиенты не всегда знают о своих желаниях и потребностях — и далеко не всегда о них рассказывают. А вот их действия стоят тысячи слов. Ищите ценностное предложение, которое отвечает их действиям. Что они уже пытаются сделать, как могут? Как вы можете помочь им сделать эту работу лучше и проще?
Избегайте слишком сложных идей. Возьмем, к примеру, Stripe, AirBnB, Dropbox, Uber. У каждого из этих сервисов до смешного простое ценностное предложение. Само решение может быть хитроумным или неоднозначным, но ценность для клиентов всегда очевидна. Ну кто не захочет такси, которое приезжает по запросу меньше чем за пять минут? Кто откажется заменить одной строчкой кода долгие дни внедрения сложной системы проведения платежей? Найдите ценностное предложение, которое будет простым и очевидным.
Перечислите свои основные риски: почему идея может не сработать? Что может сломать вашу систему?
Самое рискованное предположение — что вы создадите продукт, который никому не нужен. Об этом риске знают все. Девиз одного из самых известных венчурных фондов YCombinator: “Сделай то, что нужно людям”. И все же примерно половина основателей, с которыми мне довелось общаться, не называют предположение “людям это нужно” в числе главных гипотез о своем бизнесе.
Риск провала при реализации (execution risk) — реален. Многие шикарные идеи канули в Лету, потому что просто оказались нереализуемы на практике. Я однажды я видел питч облачного сервиса для хранения данных, который обещал быть в 10 раз дешевле Дропбокса. Если бы идея была реализуема на практике, компанию ждал бы огромный успех. К сожалению, решение оказалось пустышкой. Важно всегда учитывать, насколько задуманное осуществимо.
Маркетинг. Очень часто встречаются ситуации, когда у фаундера есть отличная идея, но он понятия не имеет, как ее продать. Многие фаундеры, которые уже прошли через свой первый опыт запуска проекта, знают: если идея не продаваемая, не стоит тратить на нее время. Маркетинговые риски заставляют трезво взглянуть на ситуацию и спросить себя напрямую: достаточно ли я знаю о своем рынке? Понимаю ли я, как продавать свой продукт на этом рынке, и кто его будет покупать? Представляю ли я себе стратегию выхода на рынок (go-to-market strategy)? Какова вероятность, что это станет самым сложным этапом развития бизнеса? И если такая вероятность есть, нужно обязательно протестировать это через MVT.
Как оценить и повысить спрос на продукт еще до выхода на рынок? Читайте в нашем гайде по продуктовому маркетингу.
Размер рынка. Этот параметр почти невозможно угадать, поэтому люди, как правило, тычут пальцем в небо и указывают какие-то абстрактные цифры. И все же, лучше сомневаться, чем вообще не знать. Вы должны четко понимать, какой размер рынка вас устроит: только в этом случае вы сможете предположить, достаточно ли велик ваш рынок в реальности. Если вы делаете узкий продукт, но уверены, что его можно расширить, добавьте “размер рынка” в список ваших рисков.
Прибыль. Почти все стартапы вначале имеют отрицательную чистую прибыль. И это нормально. Вот только некоторые компании так никогда и не выбираются из минуса. Если вы отдаете свой продукт за треть стоимости его выпуска — это быстрый способ сжечь все деньги и закрыть компанию в ближайшем будущем. Если цена товара составляет 80-90% стоимости его выпуска — это звучит приемлемо. Вам обязательно нужно выяснить, какую цену готовы заплатить клиенты и как она соотносится с вашими расходами на выпуск продукта.
Вам нужно понять, сработает ли ваша идея на практике. Сконцентрируйтесь на “атомной единице” того решения, которое вы планируете продавать. Например, для Google атомная единица — это поисковый запрос. Для Amazon — заказ книги онлайн. Для Coinbase — максимально простой способ купить или продать крипту.
Выберите одно рискованное предположение и протестируйте его прицельно. Вы всегда будете тестировать по 2-3 рискованных предположения за раз, но должно быть одно основное — в противном случае результат может быть неоднозначным.
Разработайте тест под это конкретное предположение. Если ваша самая рискованная гипотеза — это риск провала при реализации (execution risk) — протестируйте саму реализацию (то есть то, как вы намерены поставлять товар или услугу), причем максимально “хакерским” способом. И в этом случае не забывайте про коэффициент рентабельности. Далее можно придумать еще тесты, чтобы еще глубже забуриться в конкретные проблемные области.
Если ваша самая рискованная гипотеза заключается в том, что ваш продукт окажется не нужен людям, незачем спрашивать их напрямую. Лучше сделайте так, чтобы им пришлось заплатить за ваше решение — деньгами или своим временем. Если они окажутся не готовы это сделать — вот вам и ответ. Задайте себе вопрос, почему так произошло, и продолжайте искать идею или формат продукта, который люди оценят по достоинству.
При создании теста, не нужно много сил вкладывать в разработку. Сконцентрируйтесь на гипотезе. Например, в случае с Amazon не нужно разрабатывать систему онлайн-заказа, арендовать склад и налаживать систему доставки, чтобы проверить, хотят ли люди покупать онлайн. Вместо этого нужно выявить самое рискованное предположение, а именно: хотят ли люди покупать книги в интернете? Чтобы проверить это, достаточно просто собрать веб-страничку для людей, которые покупают книги. Это простое решение поможет вам понять, не обманывает ли вас интуиция в отношении вашей идеи.
Если вы соберете сайт с большой базой книг, и клиентам он не зайдет — что ж, вы будете знать, что нужно другое решение. Если вы реализуете форму поиска, в которую нужно вбить конкретную книгу, а клиенты не будут ей пользоваться — это будет показателем, что в вашей сфере бизнеса клиенты предпочитают не искать известное, а исследовать неизведанное. При помощи разных тестов можно получить огромное множество инсайтов, которые в будущем помогут в деталях сформировать ваш финальный продукт.
Ваша “атомная единица” продукта для тестирования должна быть понятной и конкретной. В данном случае, чем более нишевое решение вы будете тестировать — тем лучше. Вам нужно выделить самую суть вашего продукта. Это важно, потому что клиенты редко покупают у компании “ценностное предложение”: они покупают конкретную “единицу” вашего решения. Возьмем, к примеру, Amazon. В 1994 году никто не говорил: “Вот бы был такой большой интернет-магазин, где мы могли бы покупать все на свете!” Возможно, у создателей бизнеса эта идея уже была, но клиенты о ней понятия не имели. Клиенты думали так: “Мне нужно купить книгу X, но я не могу найти ее ни в одном книжном. Где бы мне ее купить?” В этом случае клиенту не принципиально, где он купит нужную книгу: онлайн или офлайн. Так что в качестве теста “атомной единицы” Amazon мог бы запустить хоть горячую линию, куда клиенты звонили бы в поисках нужной книги.
Давайте рассмотрим пару примеров из моей практики.
Итак, наше ценностное предложение достаточно громкое. Как можно за один раз протестировать и модель маркетплейса, и технологический продукт, и новый формат обучения?
Можно было бы собрать MVP и протестировать всё и сразу, но я решил начать с одного риска. Рисков на выбор было очень много: Примут ли люди бизнес-модель распределения доходов для групповых курсов? Увидят ли клиенты ценность в наличии централизованной библиотеки курсов? Но, как я писал выше, тест всегда должен быть заточен под один основной риск. В моем случае, ключевым риском был вопрос прибыли: поставка одного группового синхронного курса в расчете на одного студента обходится в разы дороже, чем запись асинхронного видео-курса. Поэтому в рамках первого минимально жизнеспособного теста (MVT) мне нужно было выяснить соотношение выручки и прибыли для одного курса: Удовлетворит ли клиентов покупка группового синхронного курса по цене значительно выше, чем стоят асинхронные видео-курсы?
Причем мне нужен был не ответ в стиле “да/нет”, а скорее детальный результат теста, который помог бы мне в дальнейшем принимать более обоснованные решения при выводе продукта на рынок. К примеру, в ходе теста я мог бы выяснить, что конкретным группам клиентов синхронные групповые курсы заходят больше, чем остальным. Или, я мог бы узнать, что ценность какого-то конкретного аспекта обучения (допустим, сообщество) выше, чем других (таких, например, как качество контента). В общем, это скорее искусство, чем наука!
При этом целью проекта Maven было создать платформу для создателей групповых синхронных курсов. Однако в рамках первого теста мы решили вообще не концентрироваться на софте. Самым рискованным аспектом был сам формат групповых синхронных курсов, а не платформа, на которой они будут проходить. Этот важный нюанс значительно сузил объем работ по организации первоначального теста.
Решение: Я решил провести один единственный курс. Я выбрал область, в которой хорошо разбирался, и решил провести курс на эту тему. Я нашел партнера — владельца большого смежного бизнеса (это был Сэм Парр из TheHustle) — и предложил ему провести курс совместно. Таким образом, у меня появилась возможность протестировать курс без необходимости запускать с нуля маркетинговую машину. Это был очень узкий тест, и я получил конкретный результат, на который и рассчитывал: с первого потока мы заработали более 150,000 долларов, а рейтинг курса среди студентов составил 9/10.
В ходе теста я узнал много полезной информации, которая определила продукт в его финальном виде. Самой сложной — и самой важной — частью оказалось создать сообщество (в первом потоке мы провалили эту задачу). Вопрос цены не стоял вообще: возможность общаться с преподавателем и заряженная атмосфера групповых занятий оказались весомым бонусом. Поведение студентов сильно разнилось от группы к группе.
Возможно, самый главный вывод, который я сделал для себя, заключался в том, что создание сообщества и проектирование курсов — это своего рода искусство (к которому у меня не оказалось способностей). Именно поэтому я так хотел работать в Уэсом Као — несомненным экспертом в этой области. У меня было еще несколько кандидатов на роль сооснователя Maven, но именно у Уэса были те уникальные способности, которых не было у меня. Но я никак не узнал бы этого, если бы не провел тесты.
Решение: воспользоваться услугами частного повара. Мы нашли повара на сайте объявлений Craigslist и сделали рассылку по друзьям с объявлением, что открываем сервис по доставке еды на один день. Мы предложили им сделать заказ через сайт Eventbrite и разложили на моем обеденном столе карту города, чтобы планировать доставки. В качестве водителей мы привлекли своих друзей и близких — и пару ребят нашли через сервис TaskRabbit. Я отслеживал перемещение водителей, двигая по карте фишки из “Колонизаторов”. Я смсками отправлял водителям маршруты, а клиентам — уведомления. И — вуаля! — через 2 недели мы открыли ресторан.
Целью этого теста было оценить операционную часть. Все удалось: мы очень быстро поняли, что сервис по доставке еды — это, во-первых, осуществимо, а, во-вторых, очень сложно. Мы поняли, что юнит-экономика скорее всего сойдется, хоть и впритык. Заметьте: в ходе этого теста мы не проверили множество других потенциальных гипотез. Мы понятия не имели, понравилась ли клиентам еда (в конце концов, мы ориентировались на друзей и близких). Мы понятия не имели, как выводить продукт на рынок. Мы также не заморачивались с системой заказов, потенциальными алгоритмами доставки и другими вещами. Нам важно было доказать лишь одну вещь: что операционный аспект доставки еды можно было реализовать при помощи распределенного парка машин. Результат мы оценили как успешный: за один день мы доставили более 40 блюд, потратив всего пару недель на подготовку. Но на этом дело не закончилось.
Начиная каждый следующий MVT, вы снова и снова говорите себе: “Итак, я доказал или опроверг один риск. А какие еще риски нужно рассмотреть и протестировать?”
Для Maven мы провели пять разных тестов за девять месяцев — прежде чем, наконец, выпустили первую версию MVP. На этапе MVT мы проверили следующие аспекты бизнеса: (1) как будет выглядеть процесс запуска курса, если мы будем делать это не самостоятельно, а помогать стороннему преподавателю упаковать свои знания? (2) каково наше ценностное предложение для инструкторов, которые придут на платформу преподавать свои курсы? (3) как более продуманно подойти к созданию сообщества? Добыв ответы на все эти вопросы, мы укрепились в уверенности, что наша идея стоящая. Как результат, мы вышли на продажи в 1 миллион долларов за четыре месяца.
Для Sprig мы провели три разных MVT за полгода, и только потом, наконец, запустили MVP. Благодаря минимально жизнеспособным тестам, мы еще до запуска внесли в продукт несколько важных изменений. Этап MVT укрепил нашу уверенность в том, что стоит вложиться в создание кухни и нанять штатного повара. За шесть месяцев мы вышли на продажи в 1 миллион долларов.
Минимально жизнеспособные тесты помогают собрать информацию о рынке, на основании которой становится понятно, что делать дальше. Возможно, следующим логичным этапом будет создание и запуск MVP. А, возможно, вы поймете, что нужно сосредоточиться на проработке какой-то одной части вашего продукта — и сделать ее действительно хорошо. Сейчас я поясню свои мысли на двух примерах:
В случае с Maven, если бы мы придерживались традиционной стратегии MVP, то начали бы создавать продукт под преподавателей и создателей курсов: прикрутили бы конструктор лендингов, настроили бы систему платежей, добавили бы инструмент для создания учебных программ и т.п. Однако, в ходе минимально жизнеспособных тестов мы выяснили, что нам нет нужды проверять, “зайдет” ли продукт преподавателям и авторам курсов. Более того, мы поняли, что он им точно “зайдет” — если мы покажем им возможность заработать на групповых синхронных курсах. Как выяснилось, большинству преподавателей, которым мы питчили свою идею, оказался безразличен сам продукт. Почти все они были довольны теми инструментами для создания курсов, которые были у них на руках.
Но мы также узнали, что преподавателям важны другие аспекты: (1) чтобы студентам нравились их курсы, (2) чтобы число студентов прибывало и (3) пребывание в хорошем окружении (социальное доказательство). Создатели курсов — не проектировщики и не инженеры. Им по сути не важно, какой софт мы создадим; им важно, как наш инструмент поможет им решить актуальные проблемы.
Благодаря этим инсайтам, мы поняли, что нам ни к чему создавать MVP с обширным функционалом для создателей курсов. Лучше сосредоточиться на том, чтобы собрать на платформе крутую тусовку преподов и продемонстрировать им перспективы роста и заработка. Тогда к нам быстро подтянутся и другие преподаватели.
Следующим шагом нам нужно было запустить несколько успешных курсов и объединить их в рамках платформы. Тогда люди увидят, что мы делаем, и захотят стать частью этой экосистемы. На этом этапе у нас все еще не было ни названия, ни сайта, ни онбординга для создаетей курсов. Для привлечения первого стороннего преподавателя (Anthony Pompliano) мы запустили платформу в самом базовом виде. Студенты могли регистрироваться, оплачивать курсы и заходить в учебный портал — а оттуда переходить по ссылкам в смежные сервисы (сообщество было организовано в Slack, видео-лекции мы проводили через Zoom, а приглашения рассылали через Google Calendar).
Вместо того, чтобы отгружать полноценный продукт, мы направили ресурсы на привлечение преподавателей и авторов — и, спустя полгода, у нас уже было более 50 преподов.
У нас до сих пор нет ни системы онбординга для создателей курсов, ни конструктора лендингов. Все это мы прорабатываем сейчас — и планируем выпустить в рамках частной и публичной бета-версии. Мне кажется, что, то над чем мы работаем сейчас — гораздо более полноценный продукт, чем MVP. Мы пропустили этап MVP и после проведения серии минимально жизнеспособных тестов сразу перешли к созданию компании.
С проектом Sprig мы пошли более традиционным путем. После проведения серии MVT, мы поняли, что нужно дать клиентам “пощупать” базовую версию продукта. Нам нужно было протестировать их поведение и проверить гипотезу, что клиенты захотят регулярно заказывать еду через Sprig. Еще одним аргументом в пользу создания полноценного продукта, стала кухня. Организация кухни — это долгий процесс. Когда мы в рамках минимально жизнеспособных тестов запускали кухню на один день — это стоило нам приличных денег. Нам важно было понять, как изменятся расходы, когда мы запустим кухню на постоянку.
Поэтому мы приготовились к публичному запуску: собрали первую версию приложения для iOS, создали очень простую систему маршрутизации и развернули кухню, способную готовить по сто обедов в день. Дальше вы знаете: компания “выстрелила”, и мы за первый год вышли на прогнозную выручку (run-rate) 6 миллионов долларов. Этим стремительным успехом мы во многом обязаны процессу минимально жизнеспособного тестирования (MVT): к моменту запуска, мы уже знали, чего хотят клиенты, и дали им это.
Кто-то спросит: а случалось ли тебе разочароваться в идее после проведения MVT? Случалось — и не раз! Приведу в качестве примера одну свою идею стартапа в сфере путешествий. Я хотел создать сервис для путешественников с экскурсиями от местных жителей.
Я отправился в Юго-Восточную Азию и нашел идеального кандидата на роль гида в Таиланде. Он спланировал для меня и моей девушки идеальную поездку. Мы великолепно провели время! Все было классно — за исключением одной проблемы: гиду эта работа оказалась совсем не в радость. Я видел, сколько сил он потратил в процессе: ему пришлось продумывать все перемещения, плюс постоянно взаимодействовать с нами. Я понял, что для гида игра явно не стоила свеч. Все люди разные, каждый — уникален, плюс у каждого гида тоже свой взгляд на отдых, свое видение интересного и свои особенности характера. Я долго обдумывал эту идею и общался с основателями множества компаний и сервисов в этой области.
На мой взгляд, из этой идеи можно было бы раскрутить отличный бизнес, но (1) лично мне это не приносило бы удовольствия, (2) подбирать гидов под туристов оказалось гораздо сложнее, чем я предполагал и (3) находить гидов среди местных тоже оказалось непростой задачей: на рынке их мало, и непонятно, где их искать. Проще говоря, после проведения первоначальных MVT мне не удалось нащупать здесь путь к успеху — поэтому я распрощался с этой идеей.
Очевидно, что другой человек мог бы, проведя те же тесты, увидеть в идее потенциал. Здесь нет правильного ответа. Цель тестирования — понять, сможете ли именно вы продолжить путь к успеху. И если вы видите путь — то идете по нему. А если понимаете, что это просто не ваше — это тоже окей. Возможно, кто-то сможет основать на этой почве миллиардную компанию — но это не вы. Точно так же, основателем Maven мог бы стать не я — если бы не мои сооснователи Уэс и Шреянс.
Часто бывает, что человек создает компанию, которая ему не по душе — и осознает это слишком поздно, когда в нее уже вложено столько сил! В таких ситуациях неудачный MVT — настоящее спасение.
Интересуетесь свежими материалами по продвижению SaaS-продуктов?
Подписывайтесь на канал Secret Growth в Telegram
Процесс минимально жизнеспособного тестирования — это скорее искусство, чем наука. Люди часто хотят точных ответов на свои вопросы: Как понять, что процесс MVT завершен? Как понять, успешно ли прошел тест? Но здесь вы сами решаете, что считать успехом, а что — провалом. В этом деле важны трезвая голова, решительность и чуточка удачи.
Но стартапы — штука непредсказуемая. Вы можете провести десятки MVT, создать классный MVP — и все равно провалиться. Этому меня научил наш опыт со Sprig: он стремительно взлетел, но к четвертому году сошел на нет. Один из недостатков стратегии MVT заключается в том, что мы не можем предсказать, как будет развиваться рынок, и что сделают конкуренты. В случае со Sprig мы просто не могли предвидеть, насколько конкурентным станет этот бизнес с развитием таких сервисов как Doordash, Postmates и, самое главное, UberEats. В самом начале мы опережали конкурентов: мы нравились клиентам больше, чем другие сервисы с доставкой за 10 долларов и периодом ожидания в районе часа. В долгосрочной же перспективе начал работать сетевой эффект, и эти сервисы стали гораздо быстрее и дешевле. В результате, они “съели” нашу долю рынка.
Однако для меня именно эта рискованная природа стартапов — и есть главный аргумент в пользу процесса MVT. И еще один важный аспект: когда проведете успешный MVT, не попадитесь в ловушку “эффекта беговой дорожки” (The Traction Treadmill). Не нужно ориентироваться на доход, который удалось получить в ходе этапа тестирования. Не нужно брать за основу решение, собранное для тестирования, и начинать планомерно его развивать. Обнулите доходы и расходы — оставьте только инсайты, и на их основании создайте новый продукт, который будет соответствовать рынку.
Вся суть стратегии MVT в том, чтобы обрести уверенность в своем решении. Мы жертвуем краткосрочным ростом ради роста долгосрочного. Мы запускаем минимально жизнеспособные тесты, чтобы сформировать видение продукта — и уже потом создаем продукт под это видение, и корректируем его на основании обратной связи от клиентов.
Цель этого фреймворка — не в том, чтобы застраховаться от провала. Это невозможно. Цель MVT в том, чтобы увеличить ваши шансы на успех. Сомнения и неопределенность будут сопутствовать вам постоянно, но грамотный процесс минимально жизнеспособного тестирования поможет склонить чашу весов в вашу пользу. Удачи вам и хороших экспериментов!
HighTime.agency — любим амбициозные SEO-проекты c большой аналитической проработкой. Продвигаем сайты на рынках России, США, Европы, Латама и APAC.
Команда — 12 Мин читать, 10 декабря 2024
В этой статье мы разберемся, что такое стратегическая сессия, расскажем, зачем и когда целесообразно проводить стратегические сессии для компании, и дадим фреймворк для проведения стратегической сессии самостоятельно.
Маркетинг — 17 Мин читать, 25 ноября 2024
В этой статье мы рассмотрим самые разные стратегии продвижения продуктов: от простых, но недооцененных тактик — и до нестандартных и оригинальных способов продвижения (спойлер: стратегия №9 описывает свежий подход к модели бесплатного триала продукта).
Маркетинг — 16 Мин читать, 15 ноября 2024
Как выбор стратегии GTM поможет успешно выйти на рынок? Почему компании сталкиваются с трудностями на 3 году T2D3? Как решить проблемы? Ответы на эти вопросы Стейн Хендрикс рассказал в своей статье 👇
