Четыре шага к озарению. Стратегии создания успешных стартапов
Шрифт:
Куратор сделок – это не вице-президент по продажам, готовый взяться за построение крупной организации продаж и управление ею. Этот человек обычно является обладателем внушительного списка полезных контактов на рынке, который вы собрались покорять. Хорошие кураторы агрессивны, требуют высокого уровня вознаграждения в случае успеха и не интересуются построением организации продаж. Обычно такие специалисты имеют богатый опыт продаж в стартапах. Им нравится заключать сделки, и они не собираются отдыхать и оставаться в тени.
Команда основателей и куратор сделок составляют ядро команды по развитию потребителей. Их работа заключается в том, чтобы изучать и находить достаточно информации для разработки плана продаж и развития различных каналов. Может, вам захочется пройти очередную петлю верификации потребителей без куратора. Когда вы
F. Приготовьтесь продавать: достигните согласия между руководителями команд в компании
Продажа продукта подразумевает достижение своего рода договоренностей между потребителем и компанией по поводу характеристик продукта и сроков поставки. Прежде чем покинуть стены офиса и отправиться продавать, вам необходимо, чтобы команды по разработке продукта и по развитию потребителей пришли к твердому согласию относительно готовых версий продукта и принятых обязательств. Итак, чрезвычайно важно единогласие руководителей в следующем:
график разработки, готовые версии продукта и философия;
вспомогательные материалы для продаж;
роль разработчиков в продажах, установке и постпродажной поддержке продукта.
График разработки, готовые версии продукта и философия
Продажа первым покупателям – часть процесса верификации потребителей, и команде девелоперов необходимо обозначить этим покупателям-пионерам некие ориентировочные даты выпуска продукта. Команда по развитию потребителей должна быть абсолютно уверена, что к назначенному моменту первых продаж будет готова первая функционирующая версия продукта. Если вы не можете четко определить даты или постоянно переносите сроки, позиции ранневангелистов в своих компаниях (или в случае с потребительскими продуктами среди своих друзей и близких) будут расшатываться, и вы можете вовсе лишиться их поддержки. Ваш продукт рискует получить дурную славу «пустышки» – продукта, про который много сказано, но который так и не вышел в свет. Исключите неприятные «сюрпризы». Взгляните на запланированные даты ключевых вех развития продукта, сравните с реальными и посчитайте среднее, чтобы вычислить «фактор отсрочки». Затем вы приплюсовываете получившуюся цифру к любым датам, которые называют разработчики, – и получаете те сроки, которые можно обещать потребителям.
Еще сложнее, чем гарантировать сроки выпуска первой версии продукта, – это добиться от разработчиков понимания того, зачем им, бьющимся пока еще над первой версией продукта, описывать, как будут выглядеть три последующие. Дружной командой вы уже проходили это и составляли прогнозы на первом шаге этапа выявления потребителей. Теперь же команде по развитию потребителей необходимо знать, является ли до сих пор актуальным тот график развития продукта, который был представлен разработчиками вначале. Обеим командам, занимающимся продуктом и потребителями, нужно убедиться в том, что все изменения, ставшие очевидными во время шагов 3 и 4 на этапе выявления потребителей, учтены в образце продукта, а затем оговорить обновленные характеристики очередной версии продукта.
Командам вместо «взгляда в будущее» надо договориться придерживаться философии «нормальности» – то есть о создании «нормальной» пригодной версии продукта и о сроках. Цель – предоставить ранневангелистам неполную, но «достаточно хорошую» первую версию продукта. Потребители-пионеры помогут вам понять, какой минимальный набор характеристик необходим, чтобы ваш образец мог превратиться в функциональный продукт. Это означает, что разработчикам не надо стремиться выпустить идеальную совершенную первую версию продукта. Их задача – руководствоваться в создании продукта возможностью его дополнений
Подобная философия выпуска «нормального» продукта имеет под собой два обоснования. Первое: вне зависимости от того, что говорят потребители, практически невозможно быть на 100 % уверенным, что же действительно важно для них, пока они не получат на руки первую версию продукта. Вы можете поговорить с каждым на этапе выявления потребителей и опросить ранневангелистов, но они и сами могут не осознавать, что же им нужно, пока не начнут пользоваться продуктом. Когда начинается непосредственное использование, вполне может стать очевидным, что какая-то характеристика, которая была названа в числе важных, нужна раз в полгода. А та, которую считали наименее нужной, требуется шесть раз на дню. Второе обоснование философии «нормальности» – это то, что первый продукт предназначен пока ранневангелистам, а не массовому потребителю, а их понимание важности тех или иных характеристик может различаться. Потому-то «нормальная» версия продукта призвана понравиться ранневангелистам, а не массовым потребителям.
Команде разработчиков часто сложно бывает принять концепцию «выпусти продукт, далекий от идеала». А реализовать ее еще труднее. Очень уж тонкая грань между «нормальным» пробным продуктом с минимумом характеристик и непригодным к использованию, который потребители забракуют.
Дополнительные материалы для продаж
Нет более верной причины раздора в стартапе, чем факт продажи компанией такого варианта продукта, про который разработчики изначально говорили, что они такое создать не смогут. Поэтому очень важно обеим командам согласовать все данные в дополнительных материалах к продажам. Для этого разработчики внимательно изучают и утверждают все веб-страницы, презентации, проспекты, информационные листки и т. д. Это не значит, что разработчики принимают или отвергают дополнительные материалы. Это значит, что они соотносят изложенные в них мысли с практическими возможностями и исключают все, что не может соответствовать реальности.
Роль разработчиков в продажах, установке и постпродажной поддержке продукта
Для компаний, чей продукт уже выпускается, разделение между разработчиками и группами по продажам, инсталляции и сервисному обслуживанию очевидно. В стартапе таких четких границ нет. Не забывайте, что вы договаривались облегчить жизнь разработчиков в двух областях: помочь команде по развитию потребителей найти рынок для продукта в том виде, в котором он задуман, и запрашивать дополнительные характеристики только в том случае, если рынок не может быть найден. Также группа по развитию потребителей оговаривает, что первая версия продукта будет неполной, а ранневангелисты помогут всем понять, какой будет следующая версия. Но важным моментом в модели развития потребителей является и то, что команда стартапа договаривается об активной помощи разработчиков в продажах, инсталляции и поддержке. Это означает, что тот человек в стартапе, который, собственно, обладает техническим видением продукта, и тот, кто это видение реализует, обязуются отвечать на запросы, связанные с продажами. А главные разработчики обещают помощь в подробных ответах на вопросы потребителей. Ничто не заменит прямого непосредственного опыта общения с потребителями, чтобы разработчики могли совершенствовать продукт. Модель развития потребителей предусматривает, что десятая часть процесса развития продукта – это время, проведенное «в поле», продавая, устанавливая и обслуживая произведенный продукт.
Постоянно помните, что идея «неполной первой версии» – это ловкое балансирование по лезвию ножа, особенно в случае с потребительскими рынками. Цель – выпустить продукт на рынок как можно скорее и побыстрее получить обратную связь от потребителей, а не запустить его в оборот настолько широко, чтобы в сознании потребителей версия с минимальным функционалом воспринималась как окончательная.
G. Приготовьтесь продавать: официально сформируйте консультативный совет