ЖАНРЫ

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

План осуществления продаж

Ну вот, ваша первая сделка заключена, первые потребители сказали «ОК». Но подождите пока открывать шампанское и отмечать первую успешную продажу. Это известно каждому, кто знает, как осуществляются продажи. Время для триумфа пока не пришло. К сожалению, многое может случиться между тем моментом, когда лицо, принимающее решение, дало согласие на покупку, и тем, когда вы получили чек. Задача плана осуществления продаж – записать все, что может случиться до завершения продажи и доставки продукта, и определить, кто будет следить за всем этим. Например:

Кто должен одобрить покупку: финансовый директор, генеральный директор или оба?

Должен ли совет директоров одобрить покупку?

Должны ли мама с папой одобрить покупку?

Нужно ли потребителю получить кредит на финансирование покупки?

Нужно ли сначала установить и привести в рабочее состояние системы/элементы, полученные от других поставщиков?

E. Приготовьтесь продавать: наймите «куратора сделок»

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

Куратор сделок – это не вице-президент по продажам, готовый взяться за построение крупной организации продаж и управление ею. Этот человек обычно является обладателем внушительного списка полезных контактов на рынке, который вы собрались покорять. Хорошие кураторы агрессивны, требуют высокого уровня вознаграждения в случае успеха и не интересуются построением организации продаж. Обычно такие специалисты имеют богатый опыт продаж в стартапах. Им нравится заключать сделки, и они не собираются отдыхать и оставаться в тени.

Команда основателей и куратор сделок составляют ядро команды по развитию потребителей. Их работа заключается в том, чтобы изучать и находить достаточно информации для разработки плана продаж и развития различных каналов. Может, вам захочется пройти очередную петлю верификации потребителей без куратора. Когда вы поймете, что недостаток опыта в продажах сдерживает прогресс, наймите специалиста. Но несмотря на то, что куратор сделок является неотъемлемым элементом процесса верификации потребителей, возглавлять процесс по-прежнему задача основателей и генерального директора. Такой специалист просто незаменим при организации встреч, подталкивании к последующим встречам и заключении сделок. Однако такой специалист ни в коей мере не заменит основателей, которым нужно выходить из офиса и общаться с потребителями напрямую.

F. Приготовьтесь продавать: достигните согласия между руководителями команд в компании

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

график разработки, готовые версии продукта и философия;

вспомогательные материалы для продаж;

роль разработчиков в продажах, установке и постпродажной поддержке продукта.

График разработки, готовые версии продукта и философия

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

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

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

Подобная философия выпуска «нормального» продукта имеет под собой два обоснования. Первое: вне зависимости от того, что говорят потребители, практически невозможно быть на 100 % уверенным, что же действительно важно для них, пока они не получат на руки первую версию продукта. Вы можете поговорить с каждым на этапе выявления потребителей и опросить ранневангелистов, но они и сами могут не осознавать, что же им нужно, пока не начнут пользоваться продуктом. Когда начинается непосредственное использование, вполне может стать очевидным, что какая-то характеристика, которая была названа в числе важных, нужна раз в полгода. А та, которую считали наименее нужной, требуется шесть раз на дню. Второе обоснование философии «нормальности» – это то, что первый продукт предназначен пока ранневангелистам, а не массовому потребителю, а их понимание важности тех или иных характеристик может различаться. Потому-то «нормальная» версия продукта призвана понравиться ранневангелистам, а не массовым потребителям.

Команде разработчиков часто сложно бывает принять концепцию «выпусти продукт, далекий от идеала». А реализовать ее еще труднее. Очень уж тонкая грань между «нормальным» пробным продуктом с минимумом характеристик и непригодным к использованию, который потребители забракуют.

Дополнительные материалы для продаж

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

Поделиться с друзьями: