Мы уже рассказывали, почему разработку лучше не начинать без MVP. В этой статье покажем примеры, когда бизнес не стал проверять бизнес-идею, и к чему это привело. Читайте и не делайте так никогда 🙂
Антикейс №1 — интернет-магазин товаров
— Ожидание
— Реальность
— Как надо было сделать
— Проверка гипотезы потребности продукта
— Проверка гипотезы разработки продукта
— Выводы по антикейсу
Антикейс №2 — туры для активного отдыха
— Ожидание
— Реальность
— Проверка гипотезы потребности продукта
— Проверка гипотезы разработки продукта
— Выводы по антикейсу
Антикейс №1 — интернет-магазин товаров
Первый кейс посвящен разработке интернет-магазина специфических товаров, которые можно классифицировать на несколько категорий. Товары — сложный для начинающего предпринимателя бизнес в интернете. Все получится в одном случае из ста — если угадать с нишей. Ошибиться очень легко.
Для предпринимателя было важно сохранить возможность пользователей общаться в формате С2С, создавая свои кабинеты продавца и покупателя для дальнейшего взаимодействия.
Ожидание
В начале проекта заказчик сказал, что уже сделал подготовительную работу по изучению нужности продукта:
- Изучил рынок, знает всех игроков и пообщался с целевой аудиторией.
- Нашел партнеров и договорился с теми, кто готов стать поставщиком товаров для маркетплейса.
- На словах подтвердил инвестиции на маркетинг и на продукт.
Реальность
Оказалось, что рынок не был проверен на готовность поставщиков загружать товары прямо в интерфейсе, а покупатели не заинтересованы покупать их в таком формате. Согласованные на продвижение проекта средства так и не были выделены.
Вся работа по проектированию сложнейшего бизнес-процесса, его автоматизации не просто не пригодилась, а еще и мешала при работе с теми немногими клиентами, которые приходили на сайт с бесплатных каналов.
В итоге покупатели обрабатывались мимо автоматизированного процесса, полностью вручную.
Это очень простой и типичный кейс медленной смерти проекта — окончательно все понятно всем участникам стало за полтора года.
Как же следовало подходить к разработке изначально?
Как надо было сделать
Чтобы проект получился, нужно проверить его нужность, а потом делать MVP. В случае с товарами нужно выдвинуть две гипотезы и проверить их:
- Потребность продукта для целевой аудитории.
- Функционал продукта — чего будет достаточно для использования, а что лишнее.
Проверка гипотезы потребности продукта
Правильно
- Люди испытывают сложности из-за того, что некие специфические товары не продаются онлайн.
- Люди будут готовы покупать онлайн некие специфические товары только определенной категории. Задача гипотезы — выяснить, есть ли специфика среди категорий, и если есть, то с какой категории надо начинать зарабатывать доверие.
Неправильно
- Не проводить совсем никакого исследования: полевого или кабинетного.
- Люди будут готовы покупать некие специфические товары онлайн. Гипотезу проверить очень трудно — категорий много, опубликовав их все, не будет фокуса, не будет ясно, что и почему получилось или не получилось.
Комментарий
Еще до стадии, когда есть идея проекта, неплохо бы убедиться, что людей хотя бы немного беспокоит отсутствие возможности для онлайн-покупки неких специфических товаров. Или готовы ли люди покупать специфические товары онлайн какой-то определенной категории.
Постепенное развитие продукта дало бы преимущество не только в формировании правильной бизнес-модели, но и в органическом формировании аудитории, что крайне важно для любых проектов.
Проверять то, каким должен быть продукт, тоже важно, чтобы не сделать лишний функционал.
Проверка гипотезы разработки продукта
Правильно
- Людям будет достаточно странички со списком товаров, чтобы принимать решение о покупке.
- Поставщики будут готовы самостоятельно публиковать на сайте некие специфические товары.
Неправильно
- Людям необходима корзина, личный кабинет, биллинг и интеграция со службой доставки, чтобы они покупали.
- Вообще не думать о степени готовности поставщиков выкладывать товары на новый сайт.
Комментарий
Нужно упрощать или эмулировать продукт, а не разрабатывать и усложнять. Стоило поставить под сомнение, что поставщик будет сам что-то публиковать и вообще исключить фичи для поставщика. Проверить это легко с помощью Typeform/ Google form для поставщиков.
Оказалось, чтобы заставить продавца загрузить товары, нужно как следует поработать над спросом.
Выводы по антикейсу
В условиях, когда клиент располагал достаточными ресурсами для запуска добротного MVP, следовало сфокусироваться исключительно на публикации новых товаров, формировании сообщества продавцов и уточнении их привычек.
Спустя 2 года проект к этому и пришел: администраторы сайта выкладывают товары самостоятельно через админку, а пользовательская часть не используется вообще. Деньги продавцам распределяются не биллингом продукта, а руками основателя.
Мы проделали очень много лишней работы по интеграции с банком и службой доставки, которая либо не пригодится вообще, либо пригодится не скоро. Следовало собрать несколько сотен товаров и выложить их на сайт в виде каталога. Самое важное — найти те категории товаров, которые готовы покупать онлайн.
На первой стадии не нужно делать вообще никаких личных кабинетов — дай бог кто-то что-то закажет. Заказ всегда можно оформлять простой формой обратной связи или фейковой формой оплаты. Доверие на первом этапе надо заслуживать ручной обработкой каждого клиента, а не сайтом.
Спрашивается: зачем было так потеть и тратить столько ресурсов?
Если бы проект развивался постепенно, то:
- Ресурсы и временные, и финансовые были бы сэкономлены.
- Был создан только тот софт, которым бы действительно пользовались, например, каталог товаров.
- Мотивация всех участников проекта не находилась бы в жопе. Ожидания рынка были бы оправданы.
- Органическое комьюнити было бы сформировано до начала разработки.
Антикейс №2 — туры для активного отдыха
В этом антикейсе есть особенность — мы не делали разработку нового проекта, нужно было масштабировать уже работающий бизнес.
Казалось бы, зачем проверять, нужно ли развитие проекту, но проверка гипотез важна.
Заказчик хотел сделать аналог Booking для туризма, чтобы поставщики могли регистрироваться в личном кабинете сервиса и публиковать свои туры, а покупатели могли их оплачивать в сервисе. Компания же будет получать за это комиссию.
Заказчик считал, что бизнес-идея проверена, и можно делать агрегатор. Каково же было его удивление, когда собрав вместе с нами прекрасный сервис, который копируется всей travel-отраслью, его доходы упали?
Оказалось, что рынку не был нужен был сайт активных туров, чтобы покупать и сравнивать разные туры между собой.
Ожидание
Продуктом был сайт по продаже туров от нескольких поставщиков, самостоятельно собранный на wix.
Реальность
Этот кейс намного более сложный, чем предыдущий — догадаться о таком было нетривиально. Переходя от наколеночного решения на wix к крутому продукту, мы и заказчик не заметили, как поменяли бизнес-модель. Настолько сильно, что из успешного бизнеса сделали бьющийся в нуле.
Проверка гипотезы потребности продукта
Если для существующего бизнеса гипотеза потребности успешно проверялась как «люди хотят ездить в экстремальные туры в Шпицберген», то для агрегатора, который мы начали строить, она звучала совсем иначе:
«Людям важно иметь одну точку входа для разных экстремальных туров, где они смогут искать их, сравнивать и покупать».
Оказалось, что нет — не важно, это не представляет для них никакой ценности вообще.
Правильно
Людям важно иметь одну точку входа для разных экстремальных туров, где они смогут искать их, сравнивать и покупать.
Неправильно
Думать, что добавление большего количества категорий услуг не нуждается в проверке.
Комментарий
При смене продукта мы не заметили, как поменяли изначальную потребность, которую решаем. Мы думали, что делаем апгрейд бизнеса, а оказалось, что делаем другой бизнес.
Проверка гипотезы разработки продукта
Правильно
Людям будет достаточно страницы с тремя ключевыми поисковыми фильтрами, которая будет формировать заявку, а не показывать каталог.
Неправильно
Не тестировать модель агрегатора, а приступать сразу к разработке продукта. Полагая, что расширение ассортимента поможет, заказчик ошибался — оказалось, что это снизило маржинальность бизнеса.
Комментарий
Имело смысл следить за прибыльностью каждого направления и отслеживать, где туры лучше продаются: на отдельном сайте или с формы.
Как стоило проработать бизнес-идею? Не расширять бизнес по продаже туров от нескольких поставщиков, не «чинить» его. Нужно проверять гипотезы готовыми решениями.
Сделать форму на Tilda с разными поисковыми параметрами тура и написать «Заполните форму, и мы найдем вам самый лучший тур!»
Добавить кейсы из работающего бизнеса, протестировать маркетинговые сообщения для такой страницы. Стоило бы проверить это на одном сайте и на разных.
Выводы по антикейсу
Какие преимущества получил бы предприниматель, если бы не бежал впереди паровоза, а медленно спускался с горы:
- Он бы не потратил деньги и время на сервис, который не нужен рынку, и, соответственно, не приносит доход, не масштабируется.
- К настоящему моменту уже нашел бы правильную гипотезу.
Проработка бизнес-идеи важна на любой стадии проекта — перед MVP или в самом расцвете бизнеса. Никогда не знаешь, к чему может привести та или иная идея и решение — все нужно тестировать и проверять.
Чтобы убедиться, что вы все делаете правильно, напишите нам. За 10 лет мы запустили 40 сложных программных продуктов для частных инвесторов, крупных бизнесов и государственных организаций.
Успехов в вашем проекте!
