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