Не равняйтесь на Airbnb и Uber — это ловушка. Как придумать фишки для стартапа

Споры-споры Гуру русской Темной стороны, многоуважаемый (без шуток) Морейнис [Аркадий Морейнис — прим. Rusbase] недавно посвятил отдельный пост рассужению о разнице прототипа и MVP. По его версии, MVP — это лендинг, предлагающий купить продукт, которого на самом деле еще нет. Он призван определить уровень потребности в продукте. Получается, что MVP — это процесс тестирования идеи, а не тестирования продукта. На wiki же этому термину посвящена отдельная страница, где написано, что MVP — в первую очередь все-таки продукт, а не процесс (что логично, ведь последняя буква в термине и означает Product). Как вы поняли, разница трактовок присутствует и серьезная. Не ради академического интереса, а для пользы стартаперов (они и без того много страдают), давайте попробуем разобраться, что же такое этот загадочный MVP. [Мы тоже задавались этим вопросом и выснили это здесь — прим. Rusbase]. Я склоняюсь к классическому определению. Создание и продумывание лендинга, про который пишет Морейнис, разумно, если только на нем честно написано, что сервис в разработке и скоро будет, а вы можете оставить свою почту, если вам интересно. Таким образом, под MVP я буду иметь в виду минимальный набор фич, который позволит первым пользователям действительно воспользоваться первой версией работающего продукта, пройтись по всему бизнес-процессу, а владельцам — изучить поведение и опыт пользователей, понять как развиваться дальше. В таком MVP нет ни одной фичи, которую можно убрать, и ничего не сделано вхолостую — бюджет использован на 100%. В таком MVP ничего не придется переделывать и дальнейшие решения можно принимать не на домыслах, а на реальной аналитике. Стартапер не понимает Стартапер, которому пришла в голову классная идея, не понимает, как сделать первый шаг к реализации, не понимает как поставить задачу программистам, за что хвататься. У него в голове есть видение проекта, видение будущего, некоторой идеальной картины, но нет понимания набора шагов, который надо пройти, чтобы попасть в него. Никто не скажет ему: «Делай раз. Делай два. Делай три. Проект готов!» — это невозможно. Сталкиваясь с понятием MVP, он думает: «О, пожалуй, надо начать с ограниченного набора фич, а не делать все, что я задумал сразу». Отлично! Но как составить этот набор фич, когда ты ни разу ничего такого не делал? Как декомпозировать большую-большую задачу на мелкие, когда ты ни разу не занимался разработкой? Получается, что вроде бы ясно, что надо сделать, но как именно это сделать — непонятно. Самое простое — смотреть на другие продукты. На основе этого опыта набирается мешок обрывочных «хотелок», похожих на кусочки пазла. Но я думаю, это ошибка, потому что, ориентируясь на готовый продукт, который уже прошел свой путь, трудно понять, каким был его первый MVP. Получается, это ловушка. Разумеется, чаще всего приводят в пример крутые сервисы, забывая посмотреть их длинные таймлайны в Кранчбейсе. В итоге получается, что фаундер, глядя на фишки Uber или Airbnb, пытается собрать свой первый сайт. Разумеется, я сейчас утрирую, но проблема стоит именно так: фаундеру, делающему проект в первый раз, очень трудно определить с какого набора фич запускаться. Этим текстом хотелось бы помочь начинающим фаундерам сформулировать для себя такие вопросы. Устраняем фишки Я не буду рассматривать такой критерий, как бюджет. Думаю, и без меня всем ясно: чем меньше фич — тем дешевле. Когда еще нет никакого бизнеса, очень важно расписать последовательность ключевого бизнес-процесса и всех его ответвлений. Важна каждая деталь: от того, как пользователь зашел на сайт (какие данные ввел при регистрации), до того, сколько условных товаров он может положить в условную корзину. Цель этого упражнения — ответить на следующий вопрос: действительно ли вы сможете обеспечить такой бизнес-процесс? Для этого надо представить, как это будет происходить в реальности, поставить такой мысленный эксперимент. Часто на практике всплывают нюансы, которые не позволяют на старте обеспечить какие-то удобные штуки в вашем бизнес-процессе. Если сам бизнес-процесс не получится обеспечить, то зачем его автоматизировать? И получается, что все фичи, связанные с ним можно не делать. Пример 1 Недавно к нам пришел агрегатор поставщиков сложной туристической услуги. Разумеется, что изначально задача звучала как: «Хочу быть booking.com для моей туристической услуги. Хочу, чтобы был личный кабинет поставщика и личный кабинет покупателя. И чтобы поставщики сами могли заносить информацию о себе и бла-бла-бла». В данной ситуации помогло такое упражнение: а что собственно будет в ЛК поставщика? Стали разбираться и выяснилось, что пока нет четкого понимания, что же именно там будет, да и нет столько поставщиков, готовых самостоятельно вбивать данные. В релизе мы ограничились тем, что сделали роль «Поставщик» в админке сервиса и написали инструкцию по ее заполнению. Поставщиков не так много и такой упрощенной автоматизации оказалось более чем достаточно. В релиз проект попалбез личных кабинетов и фаундер сходит с ума от объема задач, и без этого функционала. Пример 2 Делаем маркетплейс с товарами, где поставщики и покупатели товаров — физические лица. Дело дошло до обсуждения корзины, и я предложил не делать ее вообще. Сначала буря эмоций, но мой вопрос: «Как мы сможем обеспечить консолидацию посылки покупателю от разных продавцов?» помог понять, что на старте не получится такое делать из-за сырости процессов доставки. Если включать по-настоящему ненужные фичи в скоуп, то своим наличием они запутывают фаундера, помешают увидеть суть проблем, то есть наносят двойной урон проекту: и потратят лишние деньги на разработку, и усложняют жизнь после этого, так как любой бизнес-процесс надо обслуживать сотрудниками, юридическими аспектами и прочим. Итог: нужно постараться убрать все, что можно убрать, оставив лишь самую суть и работать именно с ней. Добавляем фишки Помимо устранения фич, которыми никто не сможет воспользоваться по разным причинам, стартаперы стремятся добавлять в MVP просто удобные вещи. Они никак не удлиняют ключевой бизнес-процесс, а просто очень удобны. Тут важно понимать, что юзеры будут обращаться к сервису не из-за них. Например, не так давно с одним амбициозным стартапером обсуждали загрузку данных в его сервис. Смысл сервиса сводился к обработке данных, и, конечно, удобство здесь крайне важно. Но проверить гипотезу можно и на каком-то одном способе загрузки, вместо 10 (интеграции с пятью сторонними сервисами, ручной ввод через телеграмм, имейл, фейсбук мессенджер и слак) как того хотел заказчик. Очевидно, что, внедрив какую-то одну интеграцию с популярным сторонним сервисом, бизнес сможет ответить на вопрос, насколько востребована логика, которую планируется продавать и получить фидбек от первых пользователей, то этого будет достаточно. То есть вполне можно в MVP обойтись без таких деталей, оставив их уже для конечного продукта. Есть у этого и обратная сторона Избавляясь от лишних фич в проекте, можно сильно увлечься и упростить проект до чего-то, что и так уже сделано. В погоне за упрощением, целостностью и понятностью продукта легко прийти к какому-то сервису, который уже есть и даже лучше развит. Надо помнить, что итоговый скоуп должен иметь какую-то, пусть небольшую, но ключевую фичу, которая позволяет проекту создавать уникальные сценарии использования. Недавно был такой кейс. Делаем ленту автомобильных деталей, которые заносят поставщики с ЛК. Чтобы не упроститься до Авито, который нам никогда не победить, добавили одну маленькую фичу по учету деталей: в конце дня поставщик деталей получает напоминалку с просьбой указать, какие детали он продал. Фича несложная, но сразу же понятно, куда будет развиваться сервис и чем отличается от других агрегаторов деталей с трафиком. Выводы MVP надо делать, если у вас есть твердое намерение запустить сервис, а не баловаться с лендинг-пейджами, изображая из себя крутого предпринимателя. MVP не нужен, если сам стартапер не совсем уверен, что потребность, которую он хочет решить сервисом существует. Если у него такой уверенности нет, то как он приведет на такой сервис клиентов? Ведь он не знает, что им сказать, а значит ни сам сервис не нужен, ни его MVP. Чтобы распорядиться ресурсами времени и денег рационально, необходимо расписать бизнес-процесс настолько подробно насколько это возможно. Это поможет выявить те звенья, которые потребуют автоматизации. Обязательно надо попробовать от чего-то отказаться. Постараться не смотреть Uber и Airbnb или смотреть на них, открыв в соседней вкладке Кранчбейс, где будет указано, сколько именно сотен миллионов долларов было в них вложено спустя столько-то лет с первого запуска. Так вы получите бизнес-логику будущего сервиса. Затем вам надо понять, какие данные нужны от ваших пользователей, чтобы созданная бизнес-логика смогла работать. Так можно будет составить список возможностей сервиса. Обязательно нужно проверить список на предмет лишних функций: по каждой возможности задайте себе вопрос «Что я потеряю, если уберу эту фичу». Не замахивайтесь сразу на многое — лучше оттестировать проект на спартанском функционале, чем потом вливать время и деньги в то, что не пригодится или не сработает. Если у вас есть что добавить по теме, давайте обсуждать в комментариях! Материалы по теме: MVP — это не прототип. Прототип нельзя продавать, а MVP — можно 14 венчурных фондов, где можно получить деньги Что такое MVP? И когда надо начинать делать реальный продукт? 85 важных уроков, которые я извлек на посту директора компании Эти сигналы говорят о том, что вами манипулируют — подсказка от мастера переговоров 6 признаков того, что у вас хорошее стратегическое видение