Идет ли речь о физических или об интернет- и мобильных платформах, ранневангелисты имеют общие характеристики (рис. 3.1):
у них есть проблема или потребность;
они осознают наличие проблемы;
они активно ищут решение и намечают сроки, в которые оно должно быть найдено;
проблема так остра, что они на скорую руку «стряпают» промежуточное решение;
у них есть деньги на покупку или возможность быстро мобилизовать средства.
Представьте себе шкалу «остроты проблем потребителей» и определите на ней место ранневангелистов. Будьте уверены, что они будут всегда находиться в верхней части этой шкалы, — ведь они уже искали решение, даже создали его самодельный вариант (будь то программный продукт, разработанный в компании, или устройство, собранное своими руками из вилки, лампочки и пылесоса) и имеют деньги или могут привлечь средства на его покупку. Вы можете доверять их откликам и положиться на них при первых продажах. Они расскажут о продукте другим и распространят весть о том, что мечта стала реальностью. Более того, в перспективе они могут стать членами консультативного совета (более подробно об этом рассказывается в главе 4).
Для начала создайте MVP
Мысль о том, что стартап создает продукт для узкой группы первых потребителей, а не разрабатывает нечто универсальное для массового рынка, чрезвычайно важна. Последствия такой стратегии революционны
Задача создания MVP — получить продукт с базовым набором характеристик.
На первых порах начинающая компания знает о потребителе очень мало. Все, что есть у стартапа, — это предварительное видение проблемы и продукта, который должен ее решить. К сожалению, это видение может оказаться иллюзией. Компания не знает, кем будут ее первые потребители и какой продукт им понадобится. Один из вариантов — приняться за разработку полнофункциональной версии продукта, обладающей всеми параметрами, которые пришли в голову основателям. Но теперь нам известно, что такой подход приводит к напрасным тратам времени, сил и денег, поскольку потребителям не понадобится большая часть характеристик продукта, разработанного без их участия.
Другой путь — повременить с разработкой до тех пор, пока команда по развитию потребителей не найдет клиентов, способных дать ценные отклики. Недостаток такого подхода — риск потерять время зря, поскольку продукта, который является предметом обсуждения, пока не существует.
Третий, более продуктивный подход — разработать продукт с набором базовых характеристик (применяя гибкую разработку и выполняя итерации), перечень которых определяется видением и опытом основателей компании. Это и есть MVP — минимально работоспособный продукт, продукт с базовым функционалом.
Задача выявления потребителей — проверить, как вы поняли волнующую их проблему, и выяснить, является ли предложенное решение достаточно привлекательным, чтобы покупатель приобретал и использовал ваше изобретение с базовым набором характеристик. Большинство пользователей предпочитает готовый продукт, однако у MVP есть прекрасный целевой рынок — ранневангелисты. Сделайте базовую версию продукта такой, чтобы она удовлетворяла их потребности. Если окажется, что предложенный MVP не интересен никому или не обладает нужным набором свойств, выполняйте итерации или развороты, пока не появится достаточное число тех, кто скажет «да».
Чрезвычайно важен сдвиг в сознании, который позволит отказаться от выпуска полнофункциональной первой версии и переключиться на поэтапную разработку MVP с выполнением итераций. Разработчикам хочется создать более универсальный и совершенный продукт. MVP помогает им сосредоточиться на важнейших характеристиках, без которых невозможно обойтись. MVP создается не для того, чтобы собрать пожелания в отношении характеристик и расширить их набор впоследствии. Ваша задача — продемонстрировать MVP потребителю и выяснить, правильно ли вы поняли его проблему, чтобы определить ключевые составляющие решения. Затем вы совершенствуете найденное решение, выполняя итерации. Только в том случае, если потребители для важнейших характеристик MVP не будут найдены, познакомьте группу разработки продукта с дополнительными пожеланиями клиента. В модели развития потребителей пожелания, касающиеся характеристик продукта, появляются в итеративном порядке, скорее как исключение, а не как правило. Это позволяет избавиться от бесконечного списка пожеланий, который нередко задерживает запуск первой версии продукта и сводит с ума группу разработки.