Четыре шага к озарению. Стратегии создания успешных стартапов

Подобно большинству стартапов, FastOffice знал, как создать продукт и как оценить прогресс, ведущий к выходу продукта на рынок. Чего компании недоставало, так это ориентиров на ранних стадиях развития потребителей, которые бы позволяли оценивать прогресс в понимании потребителей и в поиске рынка для своего продукта. Эти ориентиры можно было бы получить, если бы FastOffice смогла ответить на следующие вопросы:

Смогли ли мы выявить проблему, которую хочет решить потребитель?

Решает ли наш продукт эту проблему?

Если да, имеется ли у нас жизнеспособная и прибыльная бизнес-модель?

Достаточно ли у нас информации, чтобы выйти на рынок и начать продавать?

Ответы на эти вопросы – задача первого этапа в модели развития потребителей, этапа выявления потребителей. Далее в этой главе объясняется, как это сделать.

Философия выявления потребителей

Позвольте мне сформулировать задачу выявления потребителей немного более формально. Стартап начинается с видения, видения нового товара или услуги: каким образом покупатели будут получать их и зачем они станут их покупать. Но изначальные представления основателей о своем рынке и потенциальных потребителях – это, по большей части, лишь гипотезы. В действительности, в день своего основания стартап – это «основанное на вере предприятие». Чтобы видение обратилось в реальность, а вера в факты (и в приносящую доход компанию), стартапу необходимо протестировать свои догадки и гипотезы и понять, какие из них верны. Так что главная цель выявления потребителей сводится к следующему: превратить изначальные гипотезы основателей о бизнес-модели, рынке и потребителях в факты. А поскольку факты находятся вне стен офиса, первое, что должны делать стартаперы, – это выходить к своим потребителям, партнерам и поставщикам. Только когда основатели пройдут этот этап, станет очевидно, обосновано ли их видение или оно всего лишь иллюзия.

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

Полезно перечислить все, что вам не придется делать:

изучать нужды и желания всех потребителей;

составлять список всех характеристик, которые нравятся потребителям, пока они не начали покупать ваш продукт;

вручать разработчикам список характеристик, где учтены все пожелания потребителей;

вручать разработчикам документ с подробным описанием требований маркетингового характера;

проводить фокус-группы и проверять реакцию потребителей на продукт, чтобы понять, будут ли они покупать его.

Что же в таком случае вам придется делать? Вам предстоит разработать продукт для немногих, а не для большинства. Более того, вам придется начать создание продукта, еще не зная, будут ли у него потребители.

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

Разрабатывайте продукт для немногих, а не для большинства

Цель традиционного управления продуктом и маркетинга в существующих компаниях состоит в том, чтобы составить для отдела разработки документ о требованиях рынка (MRD), где сводятся воедино все пожелания потребителя в отношении характеристик продукта. Их приоритетность определяется совместными усилиями тех, кто отвечает за маркетинг, продажи и разработку. Группа маркетинга или управления продуктом организует фокус-группы, анализирует данные о продажах и знакомится с мнением потребителя о новом продукте. В результате желаемые характеристики добавляются в перечень технических требований, на основе которых разработчики создают очередную версию продукта.