Паттерн действий на ранних стадиях проекта
MVP продукта — это продукт с таким набором фич, который позволяет проверить бизнес-гипотезу. Звучит просто, но я с трудом припомню начинающих стартаперов, которые бы правильно подходили к этой проблеме. Дело в том, что правильно сформулировать бизнес-гипотезу, правильно составить набор фич для ее проверки сложно даже опытным. Комбинация правильной бизнес-гипотезы и правильного набора фич для ее проверки дают проекту огромное преимущество: дальнейшие решения можно принимать не на домыслах основателя, а на реальной аналитике. После успешного эксперимента будет ясно каким будет продукт и бизнес-модель. Девизом должно стать: «Умрем быстро». Чем быстрее идет проверка гипотез — тем быстрее найдете ту самую, успешную, правильную. Чуть фундаментальнее можно почитать у многоуважаемого Морейниса и на wiki. Разберемся в шаблоне действий, который автору кажется правильным перед началом разработки MVP.
Как происходит ошибка
Пойдем от противного и посмотрим как делать не надо. Начинающий стартапер, которому пришла в голову классная идея и он ее уже хорошенько обдумал, не понимает, как сделать первый шаг к реализации продукта, не понимает как привести трафик на сайт, да и вообще за что хвататься. У него в голове есть видение проекта, видение будущего, некоторой идеальной картины, но нет понимания набора шагов, которые надо пройти, чтобы попасть в него. Никто не скажет: «Делай раз, Делай два, Делай три, Проект готов» — невозможно. Сталкиваясь с понятием MVP, он думает: «О, пожалуй стоит начать с ограниченного набора фич, а не делать все, что я задумал сразу, звучит разумно». Отлично! Но как составить этот набор фич, когда ты ни разу ничего такого не делал? Как декомпозировать большую-большую задачу на более мелкие, когда ты ни разу не занимался разработкой? И получается, что вроде бы ясно, что делать, но как именно — нифига не понятно.
Самым простым оказывается смотреть другие продукты: сайты конкурентов, просто сервисы ежедневного использования; и на основе этого опыта набирается мешок обрывочных «хотелок», похожих на кусочки пазла. Думаю, что это ошибка, потому что, ориентируясь на готовый продукт, который уже прошел некий путь, нереально понять каким был его первый MVP. Получается, что это некая ловушка. Разумеется, чаще всего приводят в пример супер-успешные крупные бизнесы, забывая что это лишь верхушка айсберга, забывая посмотреть их длинные таймлайны в Crunchbase. В итоге получается, что фаундер пытается, глядя на фишки Uber или Airbnb, собрать свой первый сайт. Рассмотрим пару кейсов.
Антикейс 1: Товары 👠
Если это первый бизнес предпринимателя, то все получится только в одном случае из ста — если он действительно случайно угадал с нишей. Ошибиться очень легко!
Мы не идиоты, которые тыкнули пяльцем на идею.
Как было сделано
В начале проекта стартапер дал нам (и себе) ложные данные о проделанной подготовительной работе:
- Рассказал, что изучил рынок, знает всех игроков и пообщался с целевой аудиторией
- Нашел и договорился с партнерами, которые готовы быть поставщиками товаров для его маркетплейса
- На словах подтвердил инвестиции и на маркетинг и на продукт
На деле ничего из этого не было сделано:
- Оказалось, что рынок не был проверен ни на готовность поставщиков загружать товары, ни покупателей покупать их в таком формате
- Что еще хуже согласованные на продвижение проекта средства так и не были выделены
Таким образом, вся огромная работа по проектирование сложнейшего бизнес процесса и всех его ответвлений, работа по автоматизации этого бизнес процесса, не просто не пригодилась — она еще и очень мешала при работе с теми немногими клиентами, которые приходили на сайт с бесплатных каналов. В итоге покупатели обрабатывались мимо автоматизированного бизнес-процесса, то есть полностью вручную.
Как надо было сделать
Это очень простой, и очень типичный кейс медленной смерти проекта (окончательно все понятно всем участникам стало за 1,5 года). Как же следовало решать такую задачу?
- Совершенно не факт, что такой проект не нужен рынку, однако постепенное развитие такого продукта дало бы преимущество не только в формировании правильной бизнес модели, но и в органическом формировании аудитории, что крайне важно для любых проектов
- В условиях, когда клиент располагал достаточным ресурсами для запуска добротного MVP следовало сфокусироваться исключительно на публикации новых товаров и формировании сообщества продавцов и уточнении их привычек
Спустя 2 года проект к этому и пришел: администраторы сайта выкладывают товары самостоятельно через админку, а пользовательская часть не используется вообще. Деньги продавцам распределяются не биллингом продукта, а руками основателя. То есть проделано очень много лишней работы по интеграции с банком и службой доставкой, которая либо не пригодится вообще, либо пригодится не скоро. Спрашивается: нафига было так потеть и тратить столько ресурсов?
Выводы
Таким образом, если бы проект развивался постепенно, то:
- Ресурсы (и временные и финансовые были бы сэкономлены) и был бы создан только тот софт, которым бы действительно пользовались: например, только каталог товаров
- Мотивация всех участников проекта не находилась бы в жопе; ожидания рынка не были бы не оправданы
- Органическое коммьюнити было бы сформировано до начала какой бы то ни было разработки
Антикейс 2: Туры 🏕
Когда предприниматель думает как масштабировать уже работающий бизнес — проверка гипотез все равно важна. Перепутать очень легко!
Я хочу сделать Booking для экстремального туризма.
Как было сделано
Предприниматель, который заказывал у нас продукт уже имел сайт, самостоятельно собранный на wix, с которого очень успешно продавал туры от нескольких поставщиков. Ему показалось, что гипотеза проверена и следующим шагом можно делать агрегатор. Каково же было его удивление, когда собрав вместе с нами прекрасный , который копируется всей travel отраслью, добавив туда кучу поставщиков и заведя кучу трафика, его доходы упали?! Оказалось, что рынку не был нужен проект, на котором покупатель может искать себе тур активного отдыха, сравнивая его с другими. Рынку не нужно искать туры на одном ресурсе — оказалось, что с этими вполне справляются поисковые системы.
Как надо было сделать
Этот кейс намного более сложный, чем предыдущий — догадаться о таком было вообще нетривиально. Оглядываясь назад — как следовало бы правильно решать эту задачу?
- Не расширять бизнес по продаже туров от нескольких поставщиков, не «чинить» его
- Сделать форму на typeform или tilda с кучей поисковых параметров тура и Написать: заполните форму и мы найдем вам самый лучший тур! Добавить кейсы из работающего бизнеса и протестировать маркетинговые сообщения для такой страницы. Стоило бы проверить это на одном сайте и на разных.
Выводы
Какие преимущества получил бы фаундер, если бы не бежал впереди паровоза, а медленно спускался с горы:
- Он бы не потратил деньги и время на сервис, который не нужен рынку, и, соответственно, не приносит доход, не масштабируется
- К настоящему моменту уже нашел бы правильную гипотезу
Цели и задачи MVP
Посмотрели как не надо — посмотрим на то как надо. Прежде всего разберемся в целеполагании: что мы делаем и зачем.
Задачей MVP является измерение ключевых показателей будущего бизнеса, которые позволят утверждать, что такой бизнес имеет право на существование. Суть проверки сводится к измерению двух показателей:
- Стоимость привлечения одного клиента (CAC) — это то сколько денег вам надо потратить, чтобы донести до совершенно левого человека, что у вас стоит купить
- Прибыль, которую вы с него получаете (LTV), это то сколько вы заработаете с этого покупателя
Если в рамках одной сделки LTV–CAC>0, то, принимайте поздравления — ваша юнит-экономика бьется! Отдельный сложный вопрос что является сделкой в проекте. С ноги открываете дверь в кабинет инвестора, кладете ногу на ногу, откидываетесь на спинке стула и рассказываете о том, что будет если это масштабировать. Инвестору все равно проверяли ли вы это с помощью программы или руками. Идея в том, чтобы те показатели, что были получены на 100 клиентах сработали на 100 тыс клиентов, то есть ручная обработка должна выглядеть максимально приближенно к тому каким будет продукт. Цель — собрать точную статистику по ста клиентам, а не написать приложение, которое обработает их само. Намного сложнее найти эту самую первую сотню клиентов, чем выполнить вручную их заказы. Лучше вы облажаетесь перед десятком человек, обрабатывая их заявки вручную, чем сделаете отличный никому ненужный продукт.
В конечном итоге результатами MVP должны стать ответы на два вопроса:
- Как привлечь клиента
- Как обрабатывать клиента
Успешный пилот — это наличие конкретных ответов на оба этих вопроса.
О формулировании гипотез перед MVP
Надеюсь, что чуть более ясно стало зачем собственно MVP — можно поговорить о том как.
Снова обратимся к началу заметки: «MVP продукта — это продукт с таким набором фич, который позволяет проверить бизнес-гипотезу.» Думаю, что можно начинать решать эту задачку с любого конца: как с набора фич, а от него переходить к гипотезам, так и с гипотез, а от него переходить к набору фич. Мы пойдем вторым путем. Предложу типологию гипотез, которые нужно сформулировать:
- Проверка потребности: Люди готовы поменять текущий способ решения потребности на предлагаемый новый
- Проверка продукта: Людям будет достаточно для закрытия потребности предлагаемого функционала
- Проверка Бизнес модели: Люди будут готовы за это платить (понятно, что тут надо перебирать способы монетизации)
У каждого проекта набор гипотез на каждый тип будет индивидуальным, но, представляется, что этот паттерн довольно-таки универсален. А чтобы гипотезы было легче формулировать предложу следующее упражнение (назовем его маркетинговым упражнением):
Представьте, что у вас есть тот продукт (сайт/приложение), который вы хотите. В нем полностью работает функционал, но нет никаких промо-материалов вообще: ни одной записи в блоге, ни одного инстаграм поста, ни одного лендинга, ничего
- Что будете делать теперь?
Суть этого упражнения сводится к тому, чтобы на ранних этапах проекта забыть о продуктовых вопросах и думать только маркетинговых и сейлзовых. То есть чтобы понять каким будет MVP надо думать так, как будто он уже готов и ему необходимы маркетинг и sales. Поэтому начинать следует с принятия решения о комбинации того что и кому продается, с формулирования и осознания потребности.
Немного об опросах
Многие в начале пути воодушевлены одобрениями друзей, типа «Всем так нравится моя идея, все хотят увидеть сайт! Надо срочно начинать разработку». К сожалению, люди врут и сами не знают чего хотят. Люди говорят правду, только когда отдают вам свои кровные. Если не отдают — значит им это не так уж нужно.
Опросы врут, кеш фло, конверсия и LTV — нет.
Опрос может быть эффективным инструментом для определения потребностей людей, понимания того как они решают задачу сейчас, какие нюансы есть. То есть опрос может только отвечать на вопросы, касающиеся того как происходит сейчас или как происходило в прошлом. Опрос не может отвечать на вопросы, касающиеся будущего. Так как продукт находится в будущем, то опрос о продукте неприменим. Опрос может подтвердить наличие или отсутствие потребности и может стать дополнительным фактором, подтверждающим правильность формулирования гипотезы, он может направить мысль в нужном направлении; но опрашивать о том каким должен быть продукт и тем более каким должен быть его MVP, точно нельзя.
Ретроспектива кейса 1: Товары 👠
Для абстракции сообщу об этом бизнесе следующие подробности: есть некие специфические товары, которые можно классифицировать на разные категории.
Гипотеза потребности 1️⃣
- ✅ Правильно: Люди испытывают сложности из-за того, что некие специфические товары не продаются онлайн
- ❌ Неправильно: Вообще не думать об этом и не проводить совсем никакого исследования: полевого или кабинетного
- 💬 Комментарий: Еще до стадии когда есть хотя бы идея неплохо бы убедиться, что людей хотя бы немножко беспокоит отсутствие онлайн проекта для покупки неких специфических товаров.
Гипотеза потребности 2️⃣
- ✅ Правильно: Люди будут готовы покупать онлайн некие специфические товары только определенной категории.Задачей гипотезы будет выяснить: если ли какая-то специфика среди категорий и если есть, то с какой категории надо начинать зарабатывать доверие.
- ❌ Неправильно: Люди будут готовы покупать некие специфические товары онлайн.Гипотезу проверить очень трудно — категорий много, опубликовав их все не будет фокуса, не будет ясно что почему получилось или не получилось.
- 💬 Комментарий: Оказалось, что люди готовы покупать некие специфические товары онлайн только определенной категории, но не готовы покупать некие специфические товары другой категории онлайн.
Гипотеза продукта 1️⃣
- ✅ Правильно: Люди будет достаточно странички со списком неких специфических товаров, чтобы принимать решение о покупке.
- ❌ Неправильно: Людям необходима корзина, ЛК, биллинг и интеграция со службой доставки, чтобы они покупали.
- 💬 Комментарий: Нужно упрощать или эмулировать продукт, а не усложнять и разрабатывать продукт.
Гипотеза продукта 2️⃣
- ✅ Правильно: Поставщики будут готовы самостоятельно публиковать на сайте некие специфические товары.
- ❌ Неправильно: Вообще не думать о степени готовности людей выкладывать что-то на новый сайт.
- 💬 Комментарий: Стоило посомневаться, что поставщик будет сам что-то публиковать и вообще исключить фичи для поставщика. Проверить это легко, например, Typeform/ Google form. Оказалось, что чтобы заставить продавца загрузить товары — нужно как следует поработать над спросом.
Следовало собрать несколько сот неких специфических товаров и выложить их на сайт в виде каталога. Самым важным тут было бы найти те категории товаров, которые готовы покупать онлайн. На первой стадии не нужно делать вообще никакие личных кабинетов — дай Бог кто-то хоть что-то закажет. Заказ всегда можно оформлять простой формой обратной связи или фейковой формой оплаты. Доверие здесь надо заслуживать ручной обработкой каждого клиента, а не сайтом.
Ретроспектива кейса 2: Туры 🏕
Кейс с турами намного более сложный, чем с товарами, но паттерн ошибки все равно тот же. Напомню, что в случае туров бизнес очень успешно работал. Переходя от наколеночного решения на wix к крутому продукту, сделанному у нас, мы сами (и мы и заказчик) того не заметили как поменяли бизнес-модель настолько сильно, что из успешного бизнеса сделали бьющийся в нуле. Если для существующего бизнеса гипотеза потребности успешно проверялась так: Люди хотят ездить в экстремальные туры в Шпицберген, то для аггрегатора, который мы начали строить, она звучала совсем иначе: Людям важно иметь одну точку входа для разных экстремальных туров, где они смогут искать их, сравнивать и покупать. Оказалось что нет — не важно, оказалось, что это не представляет для них никакой ценности вообще. Можно проследить некий общий паттерн ошибки между кейсом Туров и Товаров:
- в случае Товаров категорию неких специфических товаров не выбирали вообще и, вывалив на сайт все — не смогли быстро понять почему не покупают
- в случае Туров бизнес работал на некой узкой категории экстремальных туров и добавления новых снизило прибыльность бизнеса
Гипотеза потребности
- ✅ Правильно: Людям важно иметь одну точку входа для разных экстремальных туров, где они смогут искать их, сравнивать и покупать.
- ❌ Неправильно: Думать, что добавление большего количества категорий услуг не нуждается в проверке — ошибка.
- 💬 Комментарий: При смене продукта мы не заметили, как поменяли потребность, которую решаем. Мы думали, что мы делаем апгрейд бизнеса, а оказалось, что мы делаем другой бизнес.
Гипотеза продукта
- ✅ Правильно: Людям будет достаточно страницы с 3мя ключевыми поисковыми фильтрами, которая будет формировать заявку, а не показывать каталог.
- ❌ Неправильно: Было неправильно не тестировать модель агрегатора, а приступать сразу к продукту, полагаю, что расширение ассортимента поможет; оказалось, что это снизило маржинальность бизнеса.
- 💬 Комментарий: Имело смысл следить прибыльность каждого направление и отслеживать где они лучше продаются: на отдельном сайте или с формы (кстати рекомендую посетить курсы finolog.ru, чтобы получше научится управленческому учету).
Выводы
Таким образом, задача MVP — это сформулировать гипотезы и проверить их, а вовсе не делать продукт. После формулирования гипотез потребности нужно придумать ограничения, которые позволят проверить продуктовые гипотезы минимальными ресурсами на разработку или вовсе без разработки сайта/приложения. В ходе работы, над маркетинговым упражнением, что предлагалось выше, станет ясно, что трудозатраты по поиску способов привлечения клиентов не менее сложны, чем поиск способа их обработки.
Упрощение способов привлечения клиентов
Например, если проект на Россию, то попробуйте в удобном для вас городе или районе (если город большой), найти тех, кто готов решать потребность тем способом, что предлагает проект. Способ поиска этих людей — это и есть решение маркетингового упражнения. Это крайне важно, так как целью MVP версии является измерение ключевых показателей будущего бизнеса, которые позволяет утверждать, что такой бизнес имеет право на существование.
Упрощение способов обработки клиентов
Выше много обсуждалось о том зачем MVP и каковы его задачи. Разобрались, что в пилоте важнее искать клиентов, чем писать софт по автоматизации их обработки. Так а каковы же минимальные требования к MVP в части обработки клиентов? Я бы постулировал их так:
- Пилот должен иметь минимальный функционал и лучше бы разработкой пилота не заниматься вовсе
- Разработанный Пилот должен быть максимально похож на готовый продукт так, чтобы при запуске продукта пользователь не заметил разницу (идеальная, невозможная ситуация)
Чтобы имитация ручной обработки была максимально правдоподобной важно расписать последовательность идеального бизнес-процесса и всех его ответвлений. Важна каждая мельчайшая деталь: от того как пользователь зашел на сайт (какие данные ввел при регистрации), до того сколько условных товаров он может положить в условную корзину. Цель этого упражнения — понять какой бизнес-процесс вы на самом деле сможете обеспечить, особенно учитывая, что это только пилот и гипотезы только на стадии проверки. После проектирования идеального бизнес-процесса, надо представить как это будет происходить в реальности, а не на бумаге. Вы найдете нюансы, которые не сможете обеспечить на старте бизнеса. Их и упрощайте. Если какие-то узлы процесса не получится обеспечить, то зачем их автоматизировать?
Заключение
Будет здорово, если в головах читателей останется маркетинговое упражнение:
Представьте, что у вас есть тот продукт (сайт/приложение), который вы хотите. В нем полностью работает функционал, но нет никаких промо-материалов вообще: ни одной записи в блоге, ни одного инстаграм поста, ни одного лендинга, ничего
- Что будете делать теперь?
И немного прочих выводов:
- Сегодня в мире есть какие угодно товары и услуги. Наше время и внимание хотят все — мы получаем тысячи рекламных сообщений в день. Производство не сложно — сложно донести до покупателя ценность;
- Поэтому на ранних этапах фокусируйтесь не на производстве, а на маркетинг+сейлз и проверке гипотез потребности;
- Проверка продуктовых гипотез должна обходиться готовыми решениями, никакой кастомной разработки.
Если у вас есть, что добавить по теме, давайте обсуждать в комментариях!
Спасибо за статью!
Допустим, потихоньку пилится агрегатор товаров как от физических лиц, так и от компаний. Кроме товаров еще перечень сопутствующих услуг. Все это в определенной и специфической сфере.
Конкурентов много, но достойных внимания почти нет.
По поводу физических лиц есть пока сомнения.
Что посоветуете: объехать какое-то количество компаний и получить обратную связь или сначала запустить mvp с минимально достаточным функционалом, чтобы этим компаниям продемонстрировать уже конкретную площадку, а не просто на словах рассказывать, за что им платить?
получить обратную связь. Это вообще то, что должен делать сео все время - иметь обратную связь.
Иначе вы делаете неизвестно что неизвестно для кого
Дмитрий, привет.
Честно говоря прямо так с пары строк трудно давать рекомендации. Напишите нам на ask@wbtech.pro — состыкуемся и попробую выдать мнение.
Спасибо за материал - повторение - мать учения! Почти все это как Вы правильно сказали у есть Морейниса.
Кейс товаров плохо отпечатался в уме , но по турам вот что
Я бы тоже не спешил делать агрегатор туров, а проверял бы комбинации путём перебора с включением более сильных конкурентных преимуществ. И только потом после того как проект вышел в прибыль, создал агрегатор, но как отдельный проект без закрытия успешного.
Петр, оглядываясь назад говорить чуть проще, чем когда находишься в ситуации.
mvp - не пилот. Это минимальный рабочий продукт.
Про то, что лучше вообще не писать, а как то сделать так, чтобы проверить гипотезу без mvp, это бы да. Но обычно не происходит
Я вот тоже думал разделить эти понятия. В ходе написания текста все ж таки решил разделить гипотезы потребности и продуктовые гипотезы и на этом решил ограничить путаницу.