12 ошибок при создании MVP (и что делать вместо этого)

Я создал десятки MVP, некоторые из них были запуском брендов в Google, некоторые стартапы привлекли финансирование в размере 3 миллионов долларов, а некоторые инструменты повышения производительности, которые я придумал, были приобретены более крупными компаниями. Вот некоторые из моих с трудом завоеванных знаний о создании продукта с точки зрения программного обеспечения.

1. Не зацикливаться на одной проблеме и демографии
Ты новенький. Ваша цель — найти небольшую группу похожих людей, которые не могут жить без вашего продукта. Им должно нравиться это, решать болевые точки по-новому. Не выходите на широкий рынок, вы не собираетесь конкурировать с Google или любым другим крупным игроком, пытаясь охватить весь их рынок. Будьте гиперспецифичны для определенной демографической группы. Затем создайте для них MLP — минимальный привлекательный продукт. Получите упорных поклонников, а затем расширяйтесь оттуда.

2. Создание всего по индивидуальному заказу
Вам нужно встать на плечи гигантов. Так много программного обеспечения уже создано в сообществе с открытым исходным кодом. Возьмите его бесплатно и повторно примените к своему варианту использования. Если вы беспокоитесь о проблемах с лицензированием и строите как Google, другие опередят вас на рынке. Сначала создайте свою аудиторию с помощью убойного продукта, который крадет из библиотек, сервисов и других проектов столько, сколько вы можете. Когда у вас есть платящие клиенты и венчурные капиталисты, вы можете беспокоиться о создании на заказ.

3. Аутсорсинг в первый раз
Если вы никогда раньше не нанимали разработчика или подрядчика, очень сложно согласовать стимулы и сообщить о направлении продукта. Инженеры общаются буквально на другом языке, поэтому ключевое значение имеет поиск кого-то, кто ориентирован на миссию, а также технически подготовлен. Вы можете найти продакт-менеджера, но есть причина, по которой технический директор оказывает более широкое влияние на их бизнес-ориентацию.

4. Не создавать что-то отполированное и привлекательное
Вы хотите построить как можно меньше. Но это должно вызывать симпатию. Его надо полировать. Если у ваших основных пользовательских путей возникают сбои или даже блокирующие ошибки, вы не можете запустить. То, что вы показываете миру, должно быть чистым и профессиональным. Это легче сделать, когда вы ограничиваете набор функций только наиболее важными. Это не означает, что нужно зацикливаться на каждом цвете или размещении кнопок, но это означает следовать общим принципам UX и проводить приемочное тестирование перед запуском.

5. В ожидании технического соучредителя Equity
Многие компании неопределенно долго ждут технического соучредителя для участия в акционерном капитале. Они отказываются от помощи до тех пор, пока идеальный руководитель программного обеспечения не появится, чтобы работать за обещание будущих доходов. Как начинающему предпринимателю трудно иметь достаточно влияния, чтобы привлечь кого-то с такой родословной. Так много людей, способных выполнять эту работу, зарабатывают в Google более полумиллиона долларов за 20-часовую рабочую неделю. Риск слишком высок для непроверенного генерального директора. Вместо этого вы хотите построить быстрый и грязный прототип и начать набирать обороты: пользовательская поддержка или инвестиции ангелов.

6. Попытка привлечь финансирование без прототипа
«Идеи бесполезны» — это общепринятая мудрость, которая гласит, что исполнение имеет первостепенное значение. Принести идею ангелу или венчурному капиталисту не получится. Даже вайрфреймы и обещания от компаний-партнеров не убеждают. Во-вторых, после платежеспособных клиентов, работающая демонстрация или прототип — это самая важная вещь, которую нужно показать инвестору. Это доказывает, что вы можете создать что-то надежное, и дает лучший вкус для направления продукта. Он может показать простую функцию и даже не быть развернутым, но он реальный, и его можно трогать, с ним можно взаимодействовать. Это мощно.

7. Подготовка к мажорной гамме заранее
MVP должны быть ловкими. Они меняются так быстро, как только вы оттачиваете соответствие продукта рынку. Не создавайте огромный набор тестов, протокол безопасности и надежную серверную часть, рассчитанные на миллион пользователей в первый же день. Все это увеличивает объем кода и усложняет поворот. Это также все замедляет, процесс удлиняется, а время выхода на рынок увеличивается. Лучшее враг хорошего. Не позволяйте конкуренту обойти вас, ускоряя итерации, потому что вы запустили идеальную версию слишком поздно.

8. Сборка для всех платформ
Не создавайте сразу для Android, iOS и Интернета. Мобильный Интернет — отличный выбор для множества новых продуктов. Но если это не подходит для вашего приложения, найдите способы заставить его работать, будь то нативное или гибридное решение. Как и в случае с не масштабированием слишком рано, не думайте, что ваши первоначальные функции станут вашими окончательными. Создавайте великолепные решения для одной платформы и наблюдайте за реакцией, после чего вы сможете разумно расширяться.

9. В ожидании, когда это станет совершенным
Полируйте MVP, но не делайте его своим ребенком. Он должен увидеть свет и быть отвергнутым реальными пользователями в реальном мире. Опять же, ключевым моментом является скорость адаптации продукта к рынку, и вы хотите как можно скорее получить реальную обратную связь от пользователей. Друзья и семья всегда будут давать предвзятые отзывы, даже если они просто по своей природе имеют схожие с вами мировоззрения. Получите это там и изучите.

10. Создание повторяющихся функций конкурентов
Для вашей первой версии не соревнуйтесь ни в чем. Вы хотите быть совершенно уникальным, чтобы найти свою ценность. В будущем, когда у вас будут лояльные клиенты, вы сможете расширять и продавать аналогичные продукты действующим компаниям, но вы не сможете создать лояльных последователей с помощью чего-либо, что уже существует на рынке. Создавайте только уникальные функции, и вы сможете указать клиентам лучшую альтернативу для других нужд. Постройте их позже.

11. Создание нежелательных функций
Не создавайте то, что людям не нужно. Если бы это было так просто. Но вы можете использовать «раскрашенные двери», чтобы увидеть, нужна ли пользователям функция, прежде чем тратить циклы на ее создание. Простой пример — создать страницу оформления заказа для продукта, которого не существует. Когда кто-то нажимает «купить», вы можете перенаправить на сообщение, в котором говорится, что вы записали его контактную информацию, чтобы связаться с ней, когда она будет готова. Это способ провести исследование рынка и привлечь внимание к новой функции, не тратя на это инженерных средств.

12. Слишком много беспокоюсь о выборе технологического стека
Большинство приложений могут быть созданы на нескольких языках, и постепенное улучшение одного по сравнению с другим минимально. Выберите популярный языковой стек, такой как python или node, и приступайте к работе. Слишком много тестируя и зацикливаясь, вы рискуете задержаться и потратить энергию на что-то относительно тривиальное. Убедитесь, что в вашем стеке достаточно ресурсов для найма, которые хорошо в нем разбираются, а также много поддержки сообщества и инструментов с открытым исходным кодом.

БОНУС: не оставаться верным своему видению Если вы переусердствуете с отзывами небольшой группы пользователей, вы рискуете сделать их счастливыми и оттолкнуть выбранную вами демографическую группу. Вы хотите внимательно слушать отзывы, но стремитесь понять проблему, а не принимать решения, предложенные пользователями. Они не знают, как решить свои проблемы, иначе они не обратились бы к вашему продукту. Вы креативный создатель продукта, поэтому вы должны оставаться верными своей демографической группе и строить для рынка, который вы выбрали для своего бизнеса.

Если вам нужны рекомендации по преодолению этих и многих других ловушек, протянуть рукуи я могу помочь вам создать оправданный MVP в рамках бюджета.

Оригинал статьи размещен на