[БЕЗ_ЗВУКА] Здравствуйте, в прошлом видео мы определили, что разработка продукта начинается с определения основной проблемы, которую должен решить этот продукт. Сегодня мы узнаем, как понять, что пора приступать к разработке, как определить MVP в стартапе, как не упустить одно из ключевых конкурентных преимуществ. Рассмотрим чек-лист на десять вопросов, на которые должны быть ответы у каждого основателя стартапа. Ответы нужно обсудить со всеми участниками команды, чтобы понять, стоит ли браться за разработку или же проект не перспективен. Первое: удалось ли найти проблему, за которую найдутся желающие заплатить? Второе: кто ваши покупатели, их портрет. Например, покупатели приложения по обучению чтению на IPad — бизнес-мамы либо русские американки с детьми от четырех до семи лет. Как поймете, что то, что вы делаете, успешное предприятие? Какие метрики, за какой срок должны достичь? Сколько максимум денег сможете заработать, если все пойдет хорошо? Кто ваши конкуренты: прямые и косвенные? Чем ваш продукт лучше и для кого? Что-то, кроме цены, если вдруг только ее хотели предложить? Точно ли рынок готов к вашему решению? Что будете делать, чтобы достигнуть успеха? Кому писать, куда ходить, что постить? Сейчас в первую очередь нужно следить, чтобы все получилось. И, самое главное, стоит ли браться за разработку или нужно еще исследовать потребности рынка? Если на все пункты есть ответы и на десятый вопрос ответ команды — «Беремся», чтобы не вышло как на картинке, нужно сформулировать и выписать на плакате цель вашего продукта. Дальше нужно понять, что в итоге должен уметь продукт для достижения этой цели и с чего стоит начинать. Начинать стоит с создания прототипов и получения обратной связи по ним. Однако здесь обычно проблем не бывает. Поэтому перейдем к MVP. Из предыдущих уроков вы уже знаете, что в переводе MVP — это минимальный жизнеспособный продукт. При создании транспортного средства необязательно начинать с машины, чтобы проверить, что все люди хотят передвигаться быстрее, чем пешком. Можно начать со скейта. MVP — хорошая концепция, если вы хотите проверить гипотезу, посмотреть на реакцию аудитории, быть гибким и не тратить много сил и денег. Процесс создания любого стартапа состоит в небольших итерациях, регулярном получении обратной связи и совершенствовании. В зависимости от того, кто ваша аудитория, в качестве минимальной версии для проверки можно использовать сайт или страницу в соцсетях с приемом предзаказов. Например, мне понравилась идея продукта по вывозу мусора для его дальнейшей переработки. Ребята сделали сайт, в котором можно было указать, какой мусор сдаешь и в каком объеме. После оформления заказа они написали, что сейчас не умеют собирать все представленные варианты, только какой-то один тип. Таким образом они проверили спрос, собрали контакты и когда реализуют выбранные опции, смогут связаться с клиентами и предложить свои услуги. Подумайте, как может выглядеть такая проверка спроса в вашем случае. Протестируйте разные ценностные предложения, чтобы определить, на что оклик у аудитории выше. Когда вы собрали достаточное количество предзаказов для какого-то продукта и подтвердили предполагаемый спрос, нужно делать MVP, в котором слово «жизнеспособный» указывает на то, что продукт в таком минимальном исполнении будет жить и клиенты будут им пользоваться, а не сдавать обратно. При этом, в зависимости от проблемы, которую вы решаете, MVP может иметь разное выражение минимальности. Например, вы решаете проблему гибели персонала и потери оборудования при его транспортировке в условиях вечной мерзлоты. Вашим решением является дрон, который может работать с грузами в требуемых условиях. С одной стороны, клиенту неважно, насколько красивой будет ваша разработка и насколько сложно ей будет управлять. С другой стороны, критичной в данном вопросе является надежность устройства. Клиент вряд ли заплатит, пока не убедится, что его оборудование не достигнет целей в условиях вечного холода. Тут минимальной историей может являться страшно сложно настраиваемый дрон, но надежно сваренный и переносящий успешно хотя бы легкие грузы через ветра и морозы. Другая история: вы решаете проблему долгого переноса письменной информации или напечатанных документов в электронный вид. Вашим решением является система, сортирующая документы, анализирующая информацию в них и трансформирующая в структурированный компьютерный файл. При этом клиенту совершенно неважно, как вы все это реализуете. Для него важно быстро и по приемлемой цене получить свой результат. Поэтому в качестве MVP можно посадить множество студентов, которые будут оцифровывать необходимые документы. Hardware — это физические инженерные решения, гораздо более сложные для последующего подтверждения гипотез, чем Soft (особенно), если они для сегмента B2B (от бизнеса для бизнеса). Поэтому тут особенно важно, чтобы возможный заработок стоил этих усилий. При этом главное не усложнять MVP еще больше самим. Например, вы хотите решить проблему длинных очередей в Китае за счет создания устройства быстрой диагностики заболеваний. Не надо делать устройство для анализа всех болезней. Пока вы его разработаете, конкуренты уже захватят рынок. Выберите болезни наиболее часто встречающиеся по симптомам местного населения и попробуйте воспроизвести устройство для обнаружения именно ее. Либо же болезнь, метод диагностики которой является самым неприятным для пациента, чтобы пациенты шли в клиники именно с вашим решением, которое более быстрое и безболезненное для них. В случае с MVP в софтовых командах, занимающихся разработкой программного обеспечения, хранятся свои проблемы. Часто хочется натыкать в приложение много фич, или по-другому, много функций. Например, в приложение по тренировкам добавить экран с онлайн-заказом спортивной одежды и возможность переписываться с другими участниками. Мысли фаундера: это обязательное условие для MVP, так как в этом случае мое приложение будет выгодно отличаться от конкурентов. Оно будет больше пользы приносить пользователям, и они будут активнее его использовать, иначе никто ко мне не придет. Это не так. Очень мало, не только стартапов, но и компаний думают не о новых фичах, а о Core UX Features — основные характеристики, основанные на поведении пользователя. Допустимо сделать приложение, чтобы оно выглядело так же, как у конкурента. В принципе, копировать — это нормально, но только если ты просто скопируешь, то ты всегда будешь вторичен. А если ты скопируешь и улучшишь Core UX Features, то твоим приложением будут пользоваться. На картинке представлены такие характеристики, как функциональность, надежность, практичность, удобство, доставление удовольствия от использования и значимость. Как достигать этих уровней, можете почитать по ссылке в дополнительных материалах к курсу. Так, например, пришел на рынок Telegram, в тот самый рынок, где есть WhatsApp. И Telegram, как вы понимаете, не думал о конкурентных преимуществах. Он делал то же самое, только он сделал все лучше. И Telegram просто взял и забрал у Whatsapp огромный кусок в 15 % пользователей. Каждый аспект, каждая деталь в Telegram сделана намного лучше, чем в Whatsapp. Файлы быстрее грузятся, в дополнение к смайликам есть более информативные и смешные стикеры, чистота дизайна, отсутствие ненужных кнопок на верхней панели и многое другое. Почему Telegram не добавляет новые фичи или добавляет их очень осторожно? Потому что добавление каждой новой фичи разрушает UX. Чтобы визуализировать, какие действия совершают ваши клиенты, и создать наглядный план разработки UX-решения, можно использовать карту пользовательских историй User story map. Как это сделать, мы рассмотрим в следующем видео. Подведем итог. Прежде чем перейти к разработке, ответьте на все вопросы из чек-листа, а то вдруг у вашей идеи нет нужного потенциала на рынке или вы его никак не сможете захватить. Чтобы определить MVP, на котором проверить гипотезу спроса, где-то достаточно страницы с его описанием и кнопкой для предзаказа. При разработке физического MVP его жизнеспособность определяется, решает ли он самую острую потребность клиента, либо же является незначительно более удобным, чем конкуренты. А минимальность — пренебрежение всем, чем можно пренебречь. При создании MVP и тем более продукта, больше внимания стоит уделить удобству его использования, нежели добавлению новых характеристик. И чем удобнее и логичнее вещь, тем больше она нравится. [ЗВУК]
