"Традиционные методы менеджмента теряют эффективность. Планирование и прогнозирование точны только тогда, когда они основаны на долгой, стабильной истории деятельности и только в относительно стабильной окружающей среде. А у стартапов нет ни того, ни другого". Эрик Рис
Книга о том, как создать бизнес и усовершенствовать бизнес-модель. Мы привыкли считать, что процессы и менеджмент - это что-то скучное и унылое, а стартапы - динамичное и увлекательное, где нет места никаким правилам. Однако верно как раз обратное: создание стартапа должно быть подчинено четкой методике, имеющей строго определенные шаги. Основная идея метода "экономичный стартап", разработанного автором, заключается в быстром тестировании идей новых продуктов на реальных потребителях и постоянной корректировке бизнес-модели, с тем чтобы начинать масштабные вложения только тогда, когда идея подтверждена фактами.
Пять принципов Lean стартапа:
1. Предприниматели есть повсюду. Чтобы создать стартап, необязательно трудиться в каком-нибудь гараже. Предпринимателем можно назвать любого, у кого есть стартап: созданное людьми предприятие, цель которого — разработка новых товаров и услуг в условиях чрезвычайной неопределенности. Это значит, что подход «экономичный стартап» можно применять в компаниях любого размера, даже на очень крупных предприятиях, в любом секторе и в любой отрасли.
2. Предпринимательство — это менеджмент. Стартап — это предприятие, а не только продукт. Поэтому ему нужен менеджмент нового типа, специально адаптированный к условиям чрезвычайной неопределенности. Я верю в то, что любой современной компании, развитие которой зависит от инноваций, нужна должность «предприниматель».
3. Подтверждение фактами. Стартапы существуют не только для того, чтобы производить товары, зарабатывать деньги или обслуживать клиентов. Они существуют для того, чтобы учиться строить жизнеспособный бизнес. Чтобы приобретать такие знания, можно использовать научный подход, постоянно проводя эксперименты, которые позволят предпринимателю проверить на практике каждый элемент своего видения.
4. Цикл «создать–оценить–научиться». Главная задача стартапа — превращать идеи в продукты, оценивать реакцию потребителей, а потом принимать решения о том, следует ли совершить вираж или лучше двигаться прежним курсом. Все процессы стартапа должны быть направлены на то, чтобы как можно быстрее получить обратную связь от потребителя.
5. Учет инноваций. Чтобы улучшить результаты стартапа и поддерживать ответственность разработчиков инноваций, нужно сосредоточиться на скучных подробностях: по каким показателям оценивать успех, как установить контрольные точки и как расставлять приоритеты. Для этого нужен новый вид отчетности, предназначенный специально для стартапов — и тех, перед кем они должны отчитываться.
 | Купить книгу | Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели |
Далее можете почитать вольный пересказ книги «The Lean Startup», Eric Ries от Аркадия Морейниса, Главстарт , опубликованный на startupweekend
Почему стартапы умирают?
Команда стартапа создает новый продукт в обстановке полной неопределенности. Никто еще точно не знает, кто же их реальные пользователи и каким на самом деле должен быть продукт. Как и любым бизнесом, веб-проектом нужно управлять. Каждым стартапом кто-то как-то управляет, но большинство проектов погибает. Почему?
Первая проблема – безоговорочное доверие хорошему бизнес-плану, четкой стратегии и обширными маркетинговым исследованиям.
В не такие уж и давние времена бизнес-планы, стратегии и исследования были хорошей заявкой на успех большинства бизнес-начинаний. Искушение внедрить аналогичный подход к планированию работы и в стартапы огромно, но в стартапах такой подход, увы, не работает, так как стартапы существуют в условиях слишком большой неопределенности. Планировать можно что-то имеющее отношение к реальности только в том случае, если основываться на длительной и стабильной бизнес-истории и условия относительно статичного рынка. У стартапов нет истории, и растут они в окружении, которое меняется с необычайной быстротой.
Вторая проблема – отсутствие плана и системы управления.
Когда вы начинаете делать стартап, то на самом деле вы строите бизнес. Любой бизнес нуждается в управлении. Эта простая мысль иногда вводит в ступор начинающих предпринимателей, так как они считают, что управление и стартап – это две несовместимые вещи. Предприниматели противостоят любым попыткам внедрять систему управления с первых дней работы стартапа, боясь, что эта система убьет на корню творчество и породит ненужную бюрократию. Что чаще всего и происходило, когда опытные управленцы пытались запихнуть квадратную логику стартапа в круглую дырку стандартной управленческой модели.
В результате большинство предпринимателей живет со стандартным подходом “на авось”, всеми путями избегая любых форм организации, построения бизнес-процессов и управленческой дисциплины. Но этот подход чаще всего приводит к достижению хаоса, а не успеха.
Но оценивать результаты своей работы надо по-другому. К сожалению, многие стартапы зачастую программируют то, что в итоге оказывается никому не нужным. В таком случае уже не имеет значения, запрограммировали ли мы это за запланированное время и уложились ли при этом в бюджет.
Главная задача стартапа – это понять, что же на самом деле надо программировать – что захотят ваши пользователи и будут ли они за это платить – причем чем быстрее, тем лучше.
Например, для того, чтобы построить космический корабль, надо заранее продумать и предусмотреть множество деталей. Все до мелочей должно быть продумано заранее и сделано с нужным качеством, в нужные сроки. Любая малейшая ошибка может привести к катастрофе запущенной в космос ракеты уже после старта, когда ничего исправить нельзя. Многие стартапы, управляемые традиционными способами, строят космические корабли – пытаются заранее продумать все и ни на шаг не отступать от намеченного плана до того момента, когда целый корабль не сойдет со стапелей.
Другой способ управления мы применяем, когда ведем машину. Связь между управлением машиной и нашими действиями очень короткая: автомобиль мгновенно отзывается на любой поворот руля, смещаясь в ту или другую сторону. Зачастую мы даже не задумываемся о том, что мы делаем – все действия происходят на уровне подсознания. Выбор пути и руление по дороге на работу и домой доведены до автоматизма. Иногда, даже выезжая в другое место, мы задумываемся и с удивлением обнаруживаем себя на дороге к работе. Но если попросить кого-то из нас закрыть глаза и нарисовать точный путь с детальным описанием всех кручений руля и нажатия педалей – скорее всего никто из нас не сможете этого сделать, как в известной притче про сороконожку, которую попросили описать, в каком порядке она переставляет ноги.
Управление стартапам больше похоже на вождение автомобиля, чем на построение космического корабля. Вместо того, чтобы составлять сложнейшие чертежи и планы, нам нужно постоянно подкручивать руль, чтобы приехать туда, куда нам нужно. Даже на работу мы можем умудриться поехать не по той дороге – но мы же не остановимся посреди дороги, а сумеем сделать нужное количество разворотов сворачиваний на другие улицы, чтобы добраться по пункта назначения, пусть и по другой дороге. Этот процесс выруливания в нужную сторону и должен лежать в основе управления стартапом.
Главное – четко понимать, куда мы едем. А ехать мы должны в сторону создания реально работающего бизнеса. Это и есть главная цель. Для достижения этой цели стартап должен выработать стратегию, в которой есть бизнес-модель, план развития продукта, анализ потенциальных партнеров и конкурентов, понимание того, кто же является вашими пользователями. Сам продукт – это овеществленный результат реализации этой стратегии.
Сами продукты периодически попадают под молот оптимизации: мы пополняем или сокращаем список свойств и возможностей продукта. Гораздо реже происходит пересмотр стратегии, так называемый «разворот». Основная же цель либо не меняется вовсе, либо это происходит совсем редко. Самое главное для предпринимателя понимать, как наиболее эффективно достичь конечной цели, меняя продукт и – реже – меняя стратегию.
Какое значение имеет выполнение плана работ и бюджета – понимание того, что все сотрудники были весь день заняты работой и мы потратили очередную порцию денег? Лучше понимать то, насколько мы стали ближе к цели. Или, если мы от нее отдалились, то вовремя отследить этот момент, попытаться вывернуть процесс в нужную сторону, и, самое главное, понять почему мы оказались не там, где хотели.
Оценка и выводы – это сложные вещи, но именно они лежат в основе единственно правильной системы управления стартапом. Стартап развивается в условиях неопределенности, поэтому к цели мы идем методом последовательных приближений, оценивая существующую ситуацию и делая выводы. Эти оценки и выводы должны базироваться не на наших представлениях о жизни, и не на том, что якобы, по их словам, хотят пользователи. Пользователи не узнают, хотят ли они наш продукт, пока мы его им не дадим попробовать. Мы должны основываться на экспериментах и реальных данных, полученных в результате этих экспериментов. Только основываясь на этом, мы можем понять, будет ли наш бизнес жизнеспособным.
Правильная оценка результатов – это не простая констатация факта после выполнения полного цикла планирования и реализации продукта – когда уже в конце пути мы понимаем, что 90% нашего продукта никому не нужно.
Построение самого продукта – это бесконечный цикл проб, успехов и ошибок. Каждую пробу надо уметь совершать как можно быстрее, чтобы как можно быстрее можно было бы получить результат, показывающий, правильным ли путем мы идем. Каждая проба должна быть нацелена только на один потенциальный результат – удовлетворение нужд нашего потребителя.
Ценность нашего продукта состоит не в том количестве свойств, которое мы придумали и реализовали, а в том, насколько полно продукт удовлетворяет потребность наших пользователей, и не сделали мы чего-нибудь такого, что нашим пользователям абсолютно не нужно.
Все читали бизнес-сказки о том, как проекты в одночасье добивались необычайного успеха. Пока нет ничего – об этом еще можно мечтать. Как только у вас появились первые, но как правило маленькие результаты – они убивают напрочь всю надежду на то, что мы окажемся в сказке.
Конечно, может возникнуть соблазн, как можно дольше оттягивать неизбежный момент зарабатывания реальных денег. Продолжать разработку все новых и новых свойств продукта, откладывая его запуск. Начинать с бесплатных, пробных, рекламных акций, откладывая момент сбора реальных денег. Но все эти откладывания могут и приводят к тому, что тратится все больше времени и денег на реализацию плана, который на самом деле ведет в никуда. С другой стороны, плюнуть и выкатить то, что есть и смотреть на то, что обычно бывает – тоже не самый лучший ход.
Можно, конечно, заняться имитацией успеха – можно потратить кучу денег на маркетинг и ПР и наслаждаться цифрами роста нашей аудитории. Это может дать краткосрочный эффект, но основной вопрос все равно остается – находимся ли мы на пути построения стабильно работающего бизнеса? А это можно понять только оценивая эффективность тех вещей, которые лежат в основе самой бизнес-модели стартапа.
Сейчас уже не стоит вопрос о том, можно ли разработать тот или иной продукт – разработать можно уже почти все, что угодно. Более важный вопрос: “А стоит ли вообще это разрабатывать?”. Или, если быть еще более точным, – “Можем ли мы построить стабильно работающий бизнес, основанный на том продукте, который мы хотим разработать?”. А для этого нам нужно оценивать не эффективность одной рекламной кампании, а результативность лежащей в основе продукта бизнес-модели.
Ответ на любой из этих вопросов должен следовать научному подходу – он должен начинаться с формулировки гипотезы: какого результата мы ожидаем от этого конкретного действия? Потом мы ставим производим это действие и собираем результаты. Все очень похоже на научный эксперимент – для того, чтобы подтвердить теорию, мы ставим эксперимент. Результаты эксперимента должны подтвердить или опровергнуть модель, опираясь на которую, мы собираемся строить стабильный бизнес.
Эксперимент – это не выпуск целого большого продукта и наблюдение за тем, что после этого будет происходить. Начинать все следует с того, чтобы разбить нашу большую картину мира на нескольких фрагментов. Два самых первых и важных фрагмента – это гипотеза ценности и гипотеза роста.
Гипотеза ценности – это предположение о том, что разрабатываемый нами продукт дает реальную и ощутимую пользу тому человеку, который будет этот продукт использовать.
Мы, конечно, можем попытаться спросить наших будущих пользователей об этом, но ответы на эти вопросы не дадут нам объективной ценности – они дадут нам только представление о том, что пользователи думают об этом, а эти мысли далеко не всегда совпадают с их реальными действиями. Эксперименты в реальной жизни дадут нам более точный ответ. Например, какой конкретно процент людей захотят загрузить себе наше приложение или зарегистрироваться на нашем сервисе?
Гипотеза роста описывает наши ожидания по поводу того, каким именно образом и сколько людей смогут найти и начать пользоваться нашим сервисом.
Как именно информация о нем будет распространяться среди потенциальных пользователей? Будут ли существующие пользователи активно распространять информацию о нем среди своих знакомых? Может ли она распространяться как вирус или нет?
Каждый из подобных экспериментов может проведен буквально за несколько недель. Это на порядки отличается от времени, традиционно закладываемого на выпуск полнофункционального продукта, только после выпуска которого мы сможем увидеть реальные результаты нашего долгого труда и потраченных денег. План стратегического развития может составляться параллельно проведению этих экспериментов с использованием полученных в их результате информации.
Даже отрицательные результаты могут положительно повлиять на стратегический план, исключая из него заведомо тупиковые пути развития.
Хотя по-человечески надо сначала ответить на четыре простых вопроса:
Наши предположения о том, как это взаимодействие будет происходить, обычно базируется на всего нескольких, но очень принципиальных, допущениях. В первую очередь эти принципиальные допущения касаются того, как будут работать гипотеза ценности и гипотеза роста. Именно эти допущения надо проверять в первую очередь.
Надо раз за разом ставить эксперименты, модифицируя продукт таким образом, чтобы приблизить наблюдаемые значения к изначально планируемым или превзойти их. Как только мы получим нужные значения, значит, механизм, заложенный в бизнес-модель продукта, способен к самовоспроизведению, обеспечивающему стабильный и естественный рост бизнеса.
Как только мы сделали первые принципиальные допущения, наша задача состоит в том, чтобы как можно быстрее перейти к этапу тестирования этих допущений, создав МРП (минимально работающий продукт). МРП – это продукт, обладающий такими свойствами, которые позволят нам за минимальное время и с минимальными усилиями перейти к этапу получения оценок и выводов по результатам тестирования изначальных гипотез.
В этой версии продукта может не хватать кучи свойств, которые могут оказаться необходимыми позже, после подтверждения правильности наших гипотез. С какой-то точки зрения мы, конечно, сделаем лишнюю работу – нам обязательно будет встроить в эту версию продукта средства сбора необходимой статистики, без которых этот шаг попросту бессмысленен. Незачем, например, делать эту минимальную версию для того, чтобы внутренне попытаться оценить юзабельность интерфейса или провести нагрузочное тестирование серверной части. Мы должны обязательно сделать этот продукт доступным для пользователей, чтобы провести эксперимент и оценить его результаты. В каких-то случая может даже потребоваться попробовать продать этот прототип – все зависит от цели эксперимента, который мы ставим.
Гипотеза и оценка – вот то, с чего должна начинаться разработка продукта. Вывод из этого эксперимента – это то, что должно быть дальше. На этом этапе мы должны сделать вывод: делать ли нам крутой «разворот» или продолжать развиваться в том же направлении?
Если мы придем к выводу, что одно из наших принципиальных допущений ложно и не может быть исправлено – это может вести к изменению стратегии развития продукта в целом. Чем раньше мы начнем эксперименты, тем раньше мы получим первые результаты. Чем раньше мы получим первые результаты, тем меньше времени и денег мы потратим, идя не в том направлении. И тем больше денег и времени останется на движение по верному пути.
На этапе составления гипотез и проведения экспериментов важно соблюсти баланс. Нельзя, с одной стороны, реализовывать все, что придет в голову и смотреть, что из этого получится. С другой стороны, нельзя бесконечно теоретизировать у доски и проводить нескончаемые маркетинговые исследования и фокус-группы. Нужно уметь делать минимально работающие продукты, ставить эксперименты и проверять гипотезы, опираясь на поведение реальных пользователей.
Минимально работающий продукт – это не самый малофункциональный продукт, который вы можете себе представить. Это просто название способа, с помощью которого можно максимально быстро и дешево поставить эксперимент для проверки своей гипотезы. И это может даже не являться продуктом в привычном смысле этого слова, потому цель минимально работающего продукта – не решить технические вопросы разработки, а ответить на ключевые вопросы, касающиеся самой сути вашего бизнеса.
Эта маленькая и неказистая вещь – минимальный работающий продукт – может быть простым рекламным объявлением и заглушкой на сайте, предназначенной для сбора предварительных регистраций. Или он может быть действительно работающим прототипом, в котором не реализовано большинство предполагаемых свойств.
Нельзя формальным образом определить, из чего должен состоять минимальный продукт – это зависит от тех принципиальных допущений, которые вы хотите протестировать, и вашего представления о том, как именно они могут быть протестированы. Не надо только переоценивать количество фич, которые вы хотите включать в минимальный продукт. Есть только одно простое правило: если вы сомневаетесь по поводу какого-то из свойств, включать его или не включать, то не включайте, однозначно.
Например, представим себе сервис, у которого есть месячный пробный период перед тем, как его должны купить. Перед тем, как пользователь купит этот продукт он должен, как минимум, подписаться на пробный период. Значит в бизнес-модели продукта есть принципиальное допущение по поводу того, сколько людей, увидевших конкретный объем информации о сервисе (текст рекламного объявления), подпишется на этот сервис. Следовательно, первым делом надо проверить, какой процент людей, получивших предложение о ценности этого продукта (увидевших рекламу с описанием конкретных свойств сервиса), зайдут и подпишутся на пробную версию сервиса. Вот вам и простая проверка гипотезы ценности.
В обычной ситуации это допущение представляет собой одну-единственную ячейку, погребенную внутри огромной экселевской таблицы с расчетом бизнес-модели и помеченную просто как “конверсия в пользователей пробной версии”. Хотя это на самом деле принципиальное допущение. Все подобные принципиальные допущения должны быть вынесены отдельно и выделены жирным шрифтом, красным цветом и 72-м кеглем.
В большинстве случаев подобная статистика начинает собираться только после того, как весь продукт уже разработан и выкачен в бой. А это неправильно, потому что может оказаться достаточным разместить рекламу и поставить заглушку для того, чтобы понять, что значение конверсии не достигает даже десятой части от прогнозируемой величины. А тогда зачем городить весь этот огород, зачем программировать все эти замечательные свойства, которыми никто не воспользуется, потому что сам продукт оказывается никому не нужным? Зачем тратить на это время и деньги?
Даже в случае успешной конверсии можно сделать интересные выводы по поводу тех свойств, описания которых не были включены в текст рекламных объявлений – значит, можно было не тратить время на их программирование для включения в первоую версию продукта, так как нужное количество пользователей пришло, привлеченное ценностью тех свойств, которые были прорекламированы. А каждое дополнительное реализованное свойство – это дополнительно потраченное время и деньги.
Дзен минимального работающего продукта состоит в том, что каждое свойство, реализованное сверх того необходимого минимума, которое требуется для проверки гипотезы – это неоправданная потеря времени и денег, независимо от того, насколько важным оно кажется автору проекта, разработчику или инвестору.
Но он начал с малого. Он начал с проверки гипотезы о том, что пользователи действительно готовы покупать обувь в он-лайне. Он просто обошел местные обувные магазины и попросил разрешения сфотографировать продающуюся в них обувь и разместить их на своем простеньком сайте под обещание того, что если кто-нибудь закажет что-то, то он принесет этот заказ продавцу и тот сможет поставить эту обувь конечному покупателю даже без выплаты Нику комиссионных.
Да, самый главный вопрос был в том, есть ли, и если есть, то какого объема, спрос. Ник, конечно, мог провести и простенький опрос, но в ответ он бы получил только представление о том, что пользователи думают, что им нужно. Построив даже простой сайт, он был вовлечен в реальное общение с пользователями, так как ему пришлось принимать оплату, обеспечивать возврат и сталкиваться с поддержкой покупателей по горячей линии.
Таким образом, Ник смог понять сразу несколько вещей:
Команда основателей состояла из программистов, так как создание такого продукта, несмотря на описанную простоту, требовала наличия очень хорошей технической реализации – нужна была бесшовная интеграция со всеми поддерживаемыми операционными системами. Команда работала над продуктом, но им надо было получить ответ на самый главный вопрос: если они потратят кучу времени и все так замечательно сделают – попробуют ли люди пользоваться этим продуктом? Они верили, что отсутствие такой синхронизации – это проблема, о которой многие пользователи даже и не подозревали.
Но это был не тот вопрос, который можно было задать на фокус-группах: пользователи чаще всего сами не знают, чего хотят, а тем более им было бы очень трудно на пальцах объяснить, как же будет работать DropBox.
Drew Houston понял это самым неприятным для себя способом, столкнувшись с полным непониманием продукта со стороны инвесторов, когда он попробовал поднять от них деньги на его разработку. Раз за разом все новые и новые инвесторы объясняли ему, что рынок уже заполнен похожими продуктами для резервного копирования, никто из них не заработал существенных денег, а проблема на самом деле не такая уж и животрепещущая для потребителей. Дрю раз за разом пытался в ответ сказать им, что вся проблема состоит в принципе работы: насколько незаметно и прозрачно для пользователя должна работать такая синхронизация, чтобы такими продуктами начали пользоваться толпы людей. Но он наталкивался на полное непонимание, так как мало кто понимал, что конкретно Дрю имеет в виду.
Проблема состояла в том, что показать продукт даже в форме прототипа была пока невозможно. Даже разработка прототипа требовала значительной затраты программистских усилий на то, чтобы бесшовно интегрироваться с операционной системой. Плюс к этому для реальной работы требовалось создать серверную часть, которая бы работала надежно и безотказно. Дрю не хотел потратить кучу времени и денег на то, чтобы в результате сделать продукт, который будет никому не нужен, поэтому он решил создать видеоролик.
Видеоролик представлял собой обычную трехминутную демонстрацию того, как будет работать DropBox, он был нацелен на узкую нишу людей, разбирающихся в технологиях и жадных до всего нового. Дрю сам озвучил этот ролик и демонстрировал в ролике перетаскивания и синхронизацию файлов, название и содержание которых содержали мемы, популярные в гиковских кругах. Несмотря на всю простоту такого решения, ролик привлек сотни тысяч человек – буквально в одночасье база регистраций на бета-тестирование продукта выросла с 5 до 75 тысяч человек – и это вселило в команду надежду и уверенность в том, что они делают то, что нужно.
Большинство из нас сейчас используют DropBox, поэтому легко можно понять, насколько популярным стал этот продукт. Хотя минимальная работающая версия его представляла всего лишь видеоролик. Но такой, с помощью которого основателям удалось проверить самое главное допущение, на котором базировалась вся идея дальнейшей его разработки.
Вроде бы несложный на первый взгляд продукт требует очень много скрытой работы: нужно собрать данные о ценах и распродажах в продуктовых магазинах страны, команда профессиональных поваров должна выбрать рецепты блюд, основывающихся на ценах и доступности ингредиентов, а спектр рецептов должен покрыть все кулинарные предпочтения пользователей. Ведение и поддержка баз данных реального наличия и цен продуктов, ведение и пополнение базы рецептов, адаптация под вкусы пользователей – все это хозяйство только для своего создания потребует кучу времени и денег.
Но свою жизнь Food on Table начал с одного-единственного пользователя и одного-единственного продуктового магазина. Как они выбирали, с какого магазина начинать? Никак – пока они не нашли своего первого пользователя. Как они составляли начальную базу рецептов? Никак – пока первый пользователь не начал планирование своего первого еженедельного меню. По сути своей компания начала обслуживание своего первого пользователя без написания единой строчки программного кода, без единого подписанного соглашения о партнерстве ни с одной продуктовой сетью и без единого нанятого профессионального повара.
Основатели сервиса Manuel Rosso и Steve Sanderson сами начали с того, что они начали ходить по местным супермаркетам в поисках своего первого пользователя. Они накидывались на потенциальных потребителей, задавали им стандартные вопросы о том будет ли, по их мнению востребован такой продукт, но в самом конце задавали принципиальный вопрос – не готов ли этот человек подписаться на услуги такого сервиса по такой-то цене прямо сейчас? По большей части случаев их просто посылали далеко, потому что большинство простых людей, встречаемых в супермаркетах, – это не те люди, которые готовы будут отдать деньги за использование сервиса, который еще никто даже и в глаза не видел. Но очевидно, что в конце концов кто-то на это необычное предложение согласился.
Этот первый клиент получил личное обслуживание. Он пользовался сервисом не с помощью сайта, еженедельно его лично посещали основатели проекта, которые до этого изучали и цены и наличие продуктов в ближайшем магазине. Они приносили потребителю пакет с продуктами и список специально подготовленных для него рецептов, а уносили с собой чек на $9.95.
Да, это было неэффективно и не масштабируемо по любым традиционным меркам. Вместо того, чтобы заниматься разработкой и развитием продукта основатели тратили время на то, чтобы удовлетворять потребности одного-единственного пользователя. Вместо того, чтобы продвигать продукт на миллионы потенциальных потребителей, они тратили время на то, чтобы собирать деньги с одного человека. Что хуже всего, на первый взгляд, этот подход не приближал их ни на шаг к созданию чего-то ощутимого. У них не было ни реальной прибыли, ни базы рецептов, ни базы по продуктам и ценам, даже по сути своей не было никакой компании.
Но на самом деле они делали огромный прогресс – каждую неделю они понимали все больше и больше о том, что должно быть в их продукте, чтобы он смог добиться успеха. Каждый новый клиент делал привлечение следующего клиента более простой задачей. Каждый клиент получал личное обслуживание, и это продолжалось до тех пор, когда издержки на личное общение не стали серьезно увеличиваться. Только после этого основатели начали тратить деньги на автоматизацию процесса, они автоматизировали процесс шаг за шагом, на каждом этапе получая возможность обрабатывать все больше и больше клиентов. Так и достигалось масштабирование. Сейчас Food on Table – это сервис, который работает в масштабах целой страны.
Основные задачи на этапе начала работы – это:
Предприниматели и сотрудники стартапов склонны переоценивать результаты своего труда. Мы хотим продолжать делать то, что начато, даже если письмена “Мене, мене, текел, фарес” уже четко виднеются на стенах нашего офиса. Мы все знаем святочные истории о компаниях, которые сумели выбраться из ямы и завоевать весь мир, но до нас не доходят правдивые истории о бесчисленном множестве остальных, кто пытался продолжать выбираться из ямы, но так и не смог это сделать.
Есть один очень простой вопрос, который стоит задавать любому стартапу: “Вы делаете ваш продукт лучше?”. Очевидный и всегда получаемый ответ на этот вопрос: “Да, конечно”. Следующий вопрос, который следует задать: “А как вы понимаете, что продукт становится лучше?” В подавляющем большинстве случаев вы получите не менее очевидный ответ: “За прошедший месяц мы запрограммировали столько-то новых функций, пользователям они нравятся, и общее количество зарегистрированных пользователях увеличилось на столько-то процентов – значит мы на правильном пути”.
Так обычно и производится оценка ситуации: мы убеждаемся в том, что мы выполнили план по разработке, может быть, поговорим с несколькими потребителями, и посмотрим на итоговые цифры по клиентской базе. К сожалению, эти цифры не говорят практически ни о чем.
Единственное, что может говорить о том, в правильном ли направлении движется стартап, – это то, насколько в результате экспериментов оказались близки к плановым показателям принципиальные допущения, которые вы сделали на этапе построения бизнес-модели.
Для этого нужно выполнить три простых шага.
10 долларов в день – каждый день 100 новых пришедших людей. С маркетинговой точки зрения – это совсем маленькие цифры, с точки зрения эксперимента – этого вполне достаточно. Каждый день мы можем вводить какое-то новое свойство, а на следующий день оценивать, как это изменение повлияло на проценты конверсии. Эти изменения могут начинаться с простой переформулировки рекламного объявления для тестирования гипотезы ценности, они могут касаться изменения дизайна или даже внесения нового функционала. Все это можно каждый день оценивать на 100 новых пользователях и смотреть, как изменится их поведение. Только эта статистика может сказать, хорошо мы поработали или нет? Приблизились ли мы к построению бизнеса или еще нет?
Каждый день новые изменения, каждый день 10 долларов, каждый день 100 новых людей – каждый день новый эксперимент и новая оценка. Так можно шаг за шагом приближаться к успеху.
При этом важно понимать, что влияние этих изменений надо оценивать для каждого пользовательского сегмента. Надо по отдельности наблюдать, как сегодняшние внедренные изменения повлияли на завтрашних новых посетителей, и то, как они повлияли на всех предыдущих накопленных клиентов. Ведь в нашей бизнес-модели есть разные принципиальные допущения: одни допущения показывают, с какой динамикой должны прибывать новые пользователи, другие – с какой динамикой они отваливаются от использования сервиса. Для того, чтобы делать правильные выводы, все данные по разным категориям пользователей надо анализировать отдельно, а не заслонять реальность обманчивыми цифрами, тупо суммирующими количество всех клиентов за отчетный период.
Механизм стабильного роста можно охарактеризовать очень просто – новые потребители приходят в результате тех или иных действий существующих потребителей. Возможных вариантов таких действий не так много.
Хорошим примером такого вируса в свое время послужила добавление сообщения “P.S. Get your free e-mail at Hotmail” в каждое сообщение, посылаемое пользователем почтового сервиса HotMail. Добавление всего одной строчки позволило этому сервису за первые шесть месяцев после этого приобрести более миллиона новых пользователей, за следующие пять недель – еще миллион.
Как любое другое принципиальное допущение действие такого механизма имеет четкую количественную оценку, обычно выражаемую в виде коэффициента вирусности. Этот коэффициент определяется как отношение новых пользователей, пришедших в результате распространения вируса, к количеству существующих пользователей сервиса. Чем выше этот коэффициент, тем быстрее будет распространяться продукт. Значение этого коэффициента в 0.1 будет означать, что на десяток существующих пользователей придется один, пришедший в результате вируса. Правда, на этом этапе распространение вируса остановится, так как применение коэффициента будет означать, что на следующем шаге придет всего 0.1 пользователь, то есть никто. Вирус способен работать как механизм роста только в том случае, если значение его коэффициента будет больше 1, и каждый пользователь будет привлекать более одного нового пользователя.
У каждого пользователя есть свой жизненный цикл – период, в течение которого он будет пользоваться сервисом. За это время он заплатит сервису определенное количество денег. Это количество денег – ценность одного пользователя для сервиса. Эти деньги минус расходы на поддержание сервиса и образуют ту потенциальную прибыль, из которой может финансироваться реклама или другие способы привлечения пользователей. Если затраты на привлечение одного пользователя будут превосходить его ценность, то механизм работать не будет.
Такого рода механизмы основываются на высоких коэффициентах удержания существующих пользователей. Вся бизнес-модель базируется на том, что если пользователь начал использовать сервис, то ему придется предпринять существенные усилия, чтобы от него отказаться – например, меняя свой телефонный номер, отказываясь от всей накопленной в сервисе информации или тратя кучу усилий на перенос ее в новый сервис.
Самое принципиальное допущение, которое надо тестировать в этом случае – это коэффициент потери пользователей, то есть отношение количества пользователей, отказывающихся от его использования к объему всей пользовательской базы. Правила роста в этом случае тоже просты – если коэффициент прироста новых пользователей превосходит коэффициент потери, то сервис будет жить даже без особой рекламы и продвижения.
Главстарт – необычный инвестор, поэтому мы готовы начать с того, чтобы дать как можно меньше денег стартапу. Мы начинаем с 20 тысяч долларов за 10% проекта. Не просто дать и забыть – кто выживает, тот выживет – а объяснить вам, как эти деньги можно и нужно с толком потратить, чтобы на выходе получить то, что может вызвать большее доверие у инвесторов и помогать реализовывать это в процессе.
Объясняем мы это обычно на проводимых нами встречах, носящих название Startup Weekend. На них мы стараемся на примерах ваших же идей и проектов помочь вам разработать схему получения первых результатов с минимальными инвестициями. Те, кому удастся это сделать, сможет получить инвестиции от Главстарта чуть ли не во время финальной презентации в воскресенье.
Естественно, что мы готовы продолжать поддержку и инвестировать в проект и после прохождения первого этапа.
Все ваши идеи мы принимаем по адресу idea@glavstart.ru. Пишите. Поможем.
Источники:
e-xecutive.ru
russia.startupweekend.org
Первая проблема – безоговорочное доверие хорошему бизнес-плану, четкой стратегии и обширными маркетинговым исследованиям.
В не такие уж и давние времена бизнес-планы, стратегии и исследования были хорошей заявкой на успех большинства бизнес-начинаний. Искушение внедрить аналогичный подход к планированию работы и в стартапы огромно, но в стартапах такой подход, увы, не работает, так как стартапы существуют в условиях слишком большой неопределенности. Планировать можно что-то имеющее отношение к реальности только в том случае, если основываться на длительной и стабильной бизнес-истории и условия относительно статичного рынка. У стартапов нет истории, и растут они в окружении, которое меняется с необычайной быстротой.
Вторая проблема – отсутствие плана и системы управления.
Когда вы начинаете делать стартап, то на самом деле вы строите бизнес. Любой бизнес нуждается в управлении. Эта простая мысль иногда вводит в ступор начинающих предпринимателей, так как они считают, что управление и стартап – это две несовместимые вещи. Предприниматели противостоят любым попыткам внедрять систему управления с первых дней работы стартапа, боясь, что эта система убьет на корню творчество и породит ненужную бюрократию. Что чаще всего и происходило, когда опытные управленцы пытались запихнуть квадратную логику стартапа в круглую дырку стандартной управленческой модели.
В результате большинство предпринимателей живет со стандартным подходом “на авось”, всеми путями избегая любых форм организации, построения бизнес-процессов и управленческой дисциплины. Но этот подход чаще всего приводит к достижению хаоса, а не успеха.
Как оценивать свою работу?
Большинство людей, работающих в стартапах оценивают свою работу по тому, насколько хорошо и долго они сегодня поработали. Например, если программист сидел 8 часов, не отрываясь от монитора, и программировал – это хороший день. Если же вас отрывали от работы вопросами или, не дай бог, совещаниями – значит вы поработали плохо. Как в этом случае оценить результат? Сгенерил много кода – это хорошо. Обычно так и бывает, потому что строки кода, реализованная новая функция, – это ощутимые вещи, которые программист может увидеть сам и показать другим.Но оценивать результаты своей работы надо по-другому. К сожалению, многие стартапы зачастую программируют то, что в итоге оказывается никому не нужным. В таком случае уже не имеет значения, запрограммировали ли мы это за запланированное время и уложились ли при этом в бюджет.
Главная задача стартапа – это понять, что же на самом деле надо программировать – что захотят ваши пользователи и будут ли они за это платить – причем чем быстрее, тем лучше.
Космический корабль или автомобиль?
Создание стартапа – это построение бизнеса. Строительством нужно управлять. Управлять же можно по-разному.Например, для того, чтобы построить космический корабль, надо заранее продумать и предусмотреть множество деталей. Все до мелочей должно быть продумано заранее и сделано с нужным качеством, в нужные сроки. Любая малейшая ошибка может привести к катастрофе запущенной в космос ракеты уже после старта, когда ничего исправить нельзя. Многие стартапы, управляемые традиционными способами, строят космические корабли – пытаются заранее продумать все и ни на шаг не отступать от намеченного плана до того момента, когда целый корабль не сойдет со стапелей.
Другой способ управления мы применяем, когда ведем машину. Связь между управлением машиной и нашими действиями очень короткая: автомобиль мгновенно отзывается на любой поворот руля, смещаясь в ту или другую сторону. Зачастую мы даже не задумываемся о том, что мы делаем – все действия происходят на уровне подсознания. Выбор пути и руление по дороге на работу и домой доведены до автоматизма. Иногда, даже выезжая в другое место, мы задумываемся и с удивлением обнаруживаем себя на дороге к работе. Но если попросить кого-то из нас закрыть глаза и нарисовать точный путь с детальным описанием всех кручений руля и нажатия педалей – скорее всего никто из нас не сможете этого сделать, как в известной притче про сороконожку, которую попросили описать, в каком порядке она переставляет ноги.
Управление стартапам больше похоже на вождение автомобиля, чем на построение космического корабля. Вместо того, чтобы составлять сложнейшие чертежи и планы, нам нужно постоянно подкручивать руль, чтобы приехать туда, куда нам нужно. Даже на работу мы можем умудриться поехать не по той дороге – но мы же не остановимся посреди дороги, а сумеем сделать нужное количество разворотов сворачиваний на другие улицы, чтобы добраться по пункта назначения, пусть и по другой дороге. Этот процесс выруливания в нужную сторону и должен лежать в основе управления стартапом.
Главное – четко понимать, куда мы едем. А ехать мы должны в сторону создания реально работающего бизнеса. Это и есть главная цель. Для достижения этой цели стартап должен выработать стратегию, в которой есть бизнес-модель, план развития продукта, анализ потенциальных партнеров и конкурентов, понимание того, кто же является вашими пользователями. Сам продукт – это овеществленный результат реализации этой стратегии.
Сами продукты периодически попадают под молот оптимизации: мы пополняем или сокращаем список свойств и возможностей продукта. Гораздо реже происходит пересмотр стратегии, так называемый «разворот». Основная же цель либо не меняется вовсе, либо это происходит совсем редко. Самое главное для предпринимателя понимать, как наиболее эффективно достичь конечной цели, меняя продукт и – реже – меняя стратегию.
Управлять можно только развитием
Традиционный способ оценки прогресса – это оценка того, насколько работа над проектом происходит в рамках заранее намеченного плана, в рамках нужного бюджета и с нужным качеством. Но насколько эффективен этот способ оценки, если мы точно не знаем, нужно ли нашим потребителям то, что мы делаем?Какое значение имеет выполнение плана работ и бюджета – понимание того, что все сотрудники были весь день заняты работой и мы потратили очередную порцию денег? Лучше понимать то, насколько мы стали ближе к цели. Или, если мы от нее отдалились, то вовремя отследить этот момент, попытаться вывернуть процесс в нужную сторону, и, самое главное, понять почему мы оказались не там, где хотели.
Оценка и выводы – это сложные вещи, но именно они лежат в основе единственно правильной системы управления стартапом. Стартап развивается в условиях неопределенности, поэтому к цели мы идем методом последовательных приближений, оценивая существующую ситуацию и делая выводы. Эти оценки и выводы должны базироваться не на наших представлениях о жизни, и не на том, что якобы, по их словам, хотят пользователи. Пользователи не узнают, хотят ли они наш продукт, пока мы его им не дадим попробовать. Мы должны основываться на экспериментах и реальных данных, полученных в результате этих экспериментов. Только основываясь на этом, мы можем понять, будет ли наш бизнес жизнеспособным.
Правильная оценка результатов – это не простая констатация факта после выполнения полного цикла планирования и реализации продукта – когда уже в конце пути мы понимаем, что 90% нашего продукта никому не нужно.
Построение самого продукта – это бесконечный цикл проб, успехов и ошибок. Каждую пробу надо уметь совершать как можно быстрее, чтобы как можно быстрее можно было бы получить результат, показывающий, правильным ли путем мы идем. Каждая проба должна быть нацелена только на один потенциальный результат – удовлетворение нужд нашего потребителя.
Ценность нашего продукта состоит не в том количестве свойств, которое мы придумали и реализовали, а в том, насколько полно продукт удовлетворяет потребность наших пользователей, и не сделали мы чего-нибудь такого, что нашим пользователям абсолютно не нужно.
Очаровательный ноль
Как ни парадоксально звучит, но иногда проще поднять инвестиционные деньги под продукт, у которого нет пользователей, ни доходов. Ноль будоражит воображение и позволяет рисовать себе и инвесторам радужные перспективы, которые мы сможем достигнуть, когда продукт будет запущен.Все читали бизнес-сказки о том, как проекты в одночасье добивались необычайного успеха. Пока нет ничего – об этом еще можно мечтать. Как только у вас появились первые, но как правило маленькие результаты – они убивают напрочь всю надежду на то, что мы окажемся в сказке.
Конечно, может возникнуть соблазн, как можно дольше оттягивать неизбежный момент зарабатывания реальных денег. Продолжать разработку все новых и новых свойств продукта, откладывая его запуск. Начинать с бесплатных, пробных, рекламных акций, откладывая момент сбора реальных денег. Но все эти откладывания могут и приводят к тому, что тратится все больше времени и денег на реализацию плана, который на самом деле ведет в никуда. С другой стороны, плюнуть и выкатить то, что есть и смотреть на то, что обычно бывает – тоже не самый лучший ход.
Можно, конечно, заняться имитацией успеха – можно потратить кучу денег на маркетинг и ПР и наслаждаться цифрами роста нашей аудитории. Это может дать краткосрочный эффект, но основной вопрос все равно остается – находимся ли мы на пути построения стабильно работающего бизнеса? А это можно понять только оценивая эффективность тех вещей, которые лежат в основе самой бизнес-модели стартапа.
Сейчас уже не стоит вопрос о том, можно ли разработать тот или иной продукт – разработать можно уже почти все, что угодно. Более важный вопрос: “А стоит ли вообще это разрабатывать?”. Или, если быть еще более точным, – “Можем ли мы построить стабильно работающий бизнес, основанный на том продукте, который мы хотим разработать?”. А для этого нам нужно оценивать не эффективность одной рекламной кампании, а результативность лежащей в основе продукта бизнес-модели.
Ставим эксперименты на живых людях
Многие стартапы мучают себя вечными вопросами. Какие мнения пользователей мы должны принимать во внимание? И должны ли вообще? Как нам разобраться, какие из кучи «хотелок» по свойствам нашего продукта мы должны реализовывать в первую очередь? Какие свойства критичны для нашего продукта, а какие являются просто улучшениями? Что в продукте мы можем изменить, не рискуя вызвать поток жалоб от наших пользователей, а что не можем? Что лучше улучшить прямо сейчас за счет того, что можно отложить на послезавтра? Что именно нам делать завтра?Ответ на любой из этих вопросов должен следовать научному подходу – он должен начинаться с формулировки гипотезы: какого результата мы ожидаем от этого конкретного действия? Потом мы ставим производим это действие и собираем результаты. Все очень похоже на научный эксперимент – для того, чтобы подтвердить теорию, мы ставим эксперимент. Результаты эксперимента должны подтвердить или опровергнуть модель, опираясь на которую, мы собираемся строить стабильный бизнес.
Эксперимент – это не выпуск целого большого продукта и наблюдение за тем, что после этого будет происходить. Начинать все следует с того, чтобы разбить нашу большую картину мира на нескольких фрагментов. Два самых первых и важных фрагмента – это гипотеза ценности и гипотеза роста.
Гипотеза ценности – это предположение о том, что разрабатываемый нами продукт дает реальную и ощутимую пользу тому человеку, который будет этот продукт использовать.
Мы, конечно, можем попытаться спросить наших будущих пользователей об этом, но ответы на эти вопросы не дадут нам объективной ценности – они дадут нам только представление о том, что пользователи думают об этом, а эти мысли далеко не всегда совпадают с их реальными действиями. Эксперименты в реальной жизни дадут нам более точный ответ. Например, какой конкретно процент людей захотят загрузить себе наше приложение или зарегистрироваться на нашем сервисе?
Гипотеза роста описывает наши ожидания по поводу того, каким именно образом и сколько людей смогут найти и начать пользоваться нашим сервисом.
Как именно информация о нем будет распространяться среди потенциальных пользователей? Будут ли существующие пользователи активно распространять информацию о нем среди своих знакомых? Может ли она распространяться как вирус или нет?
Каждый из подобных экспериментов может проведен буквально за несколько недель. Это на порядки отличается от времени, традиционно закладываемого на выпуск полнофункционального продукта, только после выпуска которого мы сможем увидеть реальные результаты нашего долгого труда и потраченных денег. План стратегического развития может составляться параллельно проведению этих экспериментов с использованием полученных в их результате информации.
Даже отрицательные результаты могут положительно повлиять на стратегический план, исключая из него заведомо тупиковые пути развития.
Продукт как эксперимент
Ставить эксперименты на своем продукте – не означает, что надо создавать сферического коня в вакууме. Каждая новая версия продукта и есть новый эксперимент. В обычной жизни продуктовик говорит: “Я хочу, чтобы в продукте было реализовано это свойство”. В ответ программист говорит: “Я могу это сделать или я могу сделать это таким-то образом за такое-то время”.Хотя по-человечески надо сначала ответить на четыре простых вопроса:
- Осознают ли потенциальные пользователи проблему, которую призван решать наш продукт?
- Если мы предоставим им наше решение, то купят ли они его?
- Купят ли они его именно от нас?
- Можем ли мы это решение запрограммировать?
Минимально работающий продукт
По сути своей, стартап – это машинка по превращению идей в продукты. По мере того, как пользователи взаимодействуют с продуктом, появляются качественные отклики пользователей и количественные данные о том, как используется продукт.Наши предположения о том, как это взаимодействие будет происходить, обычно базируется на всего нескольких, но очень принципиальных, допущениях. В первую очередь эти принципиальные допущения касаются того, как будут работать гипотеза ценности и гипотеза роста. Именно эти допущения надо проверять в первую очередь.
Надо раз за разом ставить эксперименты, модифицируя продукт таким образом, чтобы приблизить наблюдаемые значения к изначально планируемым или превзойти их. Как только мы получим нужные значения, значит, механизм, заложенный в бизнес-модель продукта, способен к самовоспроизведению, обеспечивающему стабильный и естественный рост бизнеса.
Как только мы сделали первые принципиальные допущения, наша задача состоит в том, чтобы как можно быстрее перейти к этапу тестирования этих допущений, создав МРП (минимально работающий продукт). МРП – это продукт, обладающий такими свойствами, которые позволят нам за минимальное время и с минимальными усилиями перейти к этапу получения оценок и выводов по результатам тестирования изначальных гипотез.
В этой версии продукта может не хватать кучи свойств, которые могут оказаться необходимыми позже, после подтверждения правильности наших гипотез. С какой-то точки зрения мы, конечно, сделаем лишнюю работу – нам обязательно будет встроить в эту версию продукта средства сбора необходимой статистики, без которых этот шаг попросту бессмысленен. Незачем, например, делать эту минимальную версию для того, чтобы внутренне попытаться оценить юзабельность интерфейса или провести нагрузочное тестирование серверной части. Мы должны обязательно сделать этот продукт доступным для пользователей, чтобы провести эксперимент и оценить его результаты. В каких-то случая может даже потребоваться попробовать продать этот прототип – все зависит от цели эксперимента, который мы ставим.
Гипотеза и оценка – вот то, с чего должна начинаться разработка продукта. Вывод из этого эксперимента – это то, что должно быть дальше. На этом этапе мы должны сделать вывод: делать ли нам крутой «разворот» или продолжать развиваться в том же направлении?
Если мы придем к выводу, что одно из наших принципиальных допущений ложно и не может быть исправлено – это может вести к изменению стратегии развития продукта в целом. Чем раньше мы начнем эксперименты, тем раньше мы получим первые результаты. Чем раньше мы получим первые результаты, тем меньше времени и денег мы потратим, идя не в том направлении. И тем больше денег и времени останется на движение по верному пути.
На этапе составления гипотез и проведения экспериментов важно соблюсти баланс. Нельзя, с одной стороны, реализовывать все, что придет в голову и смотреть, что из этого получится. С другой стороны, нельзя бесконечно теоретизировать у доски и проводить нескончаемые маркетинговые исследования и фокус-группы. Нужно уметь делать минимально работающие продукты, ставить эксперименты и проверять гипотезы, опираясь на поведение реальных пользователей.
Минимально работающий продукт – это не самый малофункциональный продукт, который вы можете себе представить. Это просто название способа, с помощью которого можно максимально быстро и дешево поставить эксперимент для проверки своей гипотезы. И это может даже не являться продуктом в привычном смысле этого слова, потому цель минимально работающего продукта – не решить технические вопросы разработки, а ответить на ключевые вопросы, касающиеся самой сути вашего бизнеса.
Несовершенство минимализма
Большинство авторов стартапов думают только категориями крутых и красивых продуктов, которые могут изменить жизнь миллионов человек. Это должен быть продукт того уровня, который может завоевать награду на очередном конкурсе стартапов, того уровня, который не стыдно показать девушке на первом свидании: “Вот, смотри, что я делаю”. Простенькая и неказистая штуковина, предназначенная для тестирования в ограниченном кругу энтузиастов, может представляться таким людям недостойной для приложения их усилий вещью.Эта маленькая и неказистая вещь – минимальный работающий продукт – может быть простым рекламным объявлением и заглушкой на сайте, предназначенной для сбора предварительных регистраций. Или он может быть действительно работающим прототипом, в котором не реализовано большинство предполагаемых свойств.
Нельзя формальным образом определить, из чего должен состоять минимальный продукт – это зависит от тех принципиальных допущений, которые вы хотите протестировать, и вашего представления о том, как именно они могут быть протестированы. Не надо только переоценивать количество фич, которые вы хотите включать в минимальный продукт. Есть только одно простое правило: если вы сомневаетесь по поводу какого-то из свойств, включать его или не включать, то не включайте, однозначно.
Например, представим себе сервис, у которого есть месячный пробный период перед тем, как его должны купить. Перед тем, как пользователь купит этот продукт он должен, как минимум, подписаться на пробный период. Значит в бизнес-модели продукта есть принципиальное допущение по поводу того, сколько людей, увидевших конкретный объем информации о сервисе (текст рекламного объявления), подпишется на этот сервис. Следовательно, первым делом надо проверить, какой процент людей, получивших предложение о ценности этого продукта (увидевших рекламу с описанием конкретных свойств сервиса), зайдут и подпишутся на пробную версию сервиса. Вот вам и простая проверка гипотезы ценности.
В обычной ситуации это допущение представляет собой одну-единственную ячейку, погребенную внутри огромной экселевской таблицы с расчетом бизнес-модели и помеченную просто как “конверсия в пользователей пробной версии”. Хотя это на самом деле принципиальное допущение. Все подобные принципиальные допущения должны быть вынесены отдельно и выделены жирным шрифтом, красным цветом и 72-м кеглем.
В большинстве случаев подобная статистика начинает собираться только после того, как весь продукт уже разработан и выкачен в бой. А это неправильно, потому что может оказаться достаточным разместить рекламу и поставить заглушку для того, чтобы понять, что значение конверсии не достигает даже десятой части от прогнозируемой величины. А тогда зачем городить весь этот огород, зачем программировать все эти замечательные свойства, которыми никто не воспользуется, потому что сам продукт оказывается никому не нужным? Зачем тратить на это время и деньги?
Даже в случае успешной конверсии можно сделать интересные выводы по поводу тех свойств, описания которых не были включены в текст рекламных объявлений – значит, можно было не тратить время на их программирование для включения в первоую версию продукта, так как нужное количество пользователей пришло, привлеченное ценностью тех свойств, которые были прорекламированы. А каждое дополнительное реализованное свойство – это дополнительно потраченное время и деньги.
Дзен минимального работающего продукта состоит в том, что каждое свойство, реализованное сверх того необходимого минимума, которое требуется для проверки гипотезы – это неоправданная потеря времени и денег, независимо от того, насколько важным оно кажется автору проекта, разработчику или инвестору.
Пример №1
Zappos – мировой лидер по продаже обуви он-лайн с годовым оборотом, превосходящим миллиард долларов. Основатель Zappos Nick Swinmurn мог начать с того, чтобы привлечь миллионы долларов для построения полнофункционального сайта, сети поставщиков, системы складов и сбытовых партнеров под обещания огромных объемов продаж. Собственно, так и поступали многие лопнувшие гиганты времен краха доткомов.Но он начал с малого. Он начал с проверки гипотезы о том, что пользователи действительно готовы покупать обувь в он-лайне. Он просто обошел местные обувные магазины и попросил разрешения сфотографировать продающуюся в них обувь и разместить их на своем простеньком сайте под обещание того, что если кто-нибудь закажет что-то, то он принесет этот заказ продавцу и тот сможет поставить эту обувь конечному покупателю даже без выплаты Нику комиссионных.
Да, самый главный вопрос был в том, есть ли, и если есть, то какого объема, спрос. Ник, конечно, мог провести и простенький опрос, но в ответ он бы получил только представление о том, что пользователи думают, что им нужно. Построив даже простой сайт, он был вовлечен в реальное общение с пользователями, так как ему пришлось принимать оплату, обеспечивать возврат и сталкиваться с поддержкой покупателей по горячей линии.
Таким образом, Ник смог понять сразу несколько вещей:
- Собрать реальные данные о том, насколько востребован этот сервис, основываясь не на теоретических размышлениях потенциальных пользователей, а на количестве реальных посетителей и сделанных ими заказов.
- Он смог более четко понять потребности реальных покупателей: например, как количественно скидки влияют на продажи.
- Он смог поставить себя в ситуацию, при которой он стал получать ответы на вопросы, которые он бы не смог даже придумать изначально: например, что делать, если покупатель решил вернуть купленную обувь?
Пример №2
DropBox – простейший инструмент для синхронизации. После установки программы на вашем десктопе появляется папка, любой файл перетащенный копируется в облако, а содержимое папки автоматически синхронизуется со всеми вашими компьютерами, телефонами и планшетами.Команда основателей состояла из программистов, так как создание такого продукта, несмотря на описанную простоту, требовала наличия очень хорошей технической реализации – нужна была бесшовная интеграция со всеми поддерживаемыми операционными системами. Команда работала над продуктом, но им надо было получить ответ на самый главный вопрос: если они потратят кучу времени и все так замечательно сделают – попробуют ли люди пользоваться этим продуктом? Они верили, что отсутствие такой синхронизации – это проблема, о которой многие пользователи даже и не подозревали.
Но это был не тот вопрос, который можно было задать на фокус-группах: пользователи чаще всего сами не знают, чего хотят, а тем более им было бы очень трудно на пальцах объяснить, как же будет работать DropBox.
Drew Houston понял это самым неприятным для себя способом, столкнувшись с полным непониманием продукта со стороны инвесторов, когда он попробовал поднять от них деньги на его разработку. Раз за разом все новые и новые инвесторы объясняли ему, что рынок уже заполнен похожими продуктами для резервного копирования, никто из них не заработал существенных денег, а проблема на самом деле не такая уж и животрепещущая для потребителей. Дрю раз за разом пытался в ответ сказать им, что вся проблема состоит в принципе работы: насколько незаметно и прозрачно для пользователя должна работать такая синхронизация, чтобы такими продуктами начали пользоваться толпы людей. Но он наталкивался на полное непонимание, так как мало кто понимал, что конкретно Дрю имеет в виду.
Проблема состояла в том, что показать продукт даже в форме прототипа была пока невозможно. Даже разработка прототипа требовала значительной затраты программистских усилий на то, чтобы бесшовно интегрироваться с операционной системой. Плюс к этому для реальной работы требовалось создать серверную часть, которая бы работала надежно и безотказно. Дрю не хотел потратить кучу времени и денег на то, чтобы в результате сделать продукт, который будет никому не нужен, поэтому он решил создать видеоролик.
Видеоролик представлял собой обычную трехминутную демонстрацию того, как будет работать DropBox, он был нацелен на узкую нишу людей, разбирающихся в технологиях и жадных до всего нового. Дрю сам озвучил этот ролик и демонстрировал в ролике перетаскивания и синхронизацию файлов, название и содержание которых содержали мемы, популярные в гиковских кругах. Несмотря на всю простоту такого решения, ролик привлек сотни тысяч человек – буквально в одночасье база регистраций на бета-тестирование продукта выросла с 5 до 75 тысяч человек – и это вселило в команду надежду и уверенность в том, что они делают то, что нужно.
Большинство из нас сейчас используют DropBox, поэтому легко можно понять, насколько популярным стал этот продукт. Хотя минимальная работающая версия его представляла всего лишь видеоролик. Но такой, с помощью которого основателям удалось проверить самое главное допущение, на котором базировалась вся идея дальнейшей его разработки.
Пример №3
Food on the Table – это сервис, который еженедельно автоматически генерит для вас меню на всю неделю и список покупок, которые необходимо сделать, чтобы приготовить эту еду. Эти меню основываются на кулинарных предпочтениях вас и вашей семьи, а список покупок – на лучших ценах на ингредиенты в ближайших для вас магазинах.Вроде бы несложный на первый взгляд продукт требует очень много скрытой работы: нужно собрать данные о ценах и распродажах в продуктовых магазинах страны, команда профессиональных поваров должна выбрать рецепты блюд, основывающихся на ценах и доступности ингредиентов, а спектр рецептов должен покрыть все кулинарные предпочтения пользователей. Ведение и поддержка баз данных реального наличия и цен продуктов, ведение и пополнение базы рецептов, адаптация под вкусы пользователей – все это хозяйство только для своего создания потребует кучу времени и денег.
Но свою жизнь Food on Table начал с одного-единственного пользователя и одного-единственного продуктового магазина. Как они выбирали, с какого магазина начинать? Никак – пока они не нашли своего первого пользователя. Как они составляли начальную базу рецептов? Никак – пока первый пользователь не начал планирование своего первого еженедельного меню. По сути своей компания начала обслуживание своего первого пользователя без написания единой строчки программного кода, без единого подписанного соглашения о партнерстве ни с одной продуктовой сетью и без единого нанятого профессионального повара.
Основатели сервиса Manuel Rosso и Steve Sanderson сами начали с того, что они начали ходить по местным супермаркетам в поисках своего первого пользователя. Они накидывались на потенциальных потребителей, задавали им стандартные вопросы о том будет ли, по их мнению востребован такой продукт, но в самом конце задавали принципиальный вопрос – не готов ли этот человек подписаться на услуги такого сервиса по такой-то цене прямо сейчас? По большей части случаев их просто посылали далеко, потому что большинство простых людей, встречаемых в супермаркетах, – это не те люди, которые готовы будут отдать деньги за использование сервиса, который еще никто даже и в глаза не видел. Но очевидно, что в конце концов кто-то на это необычное предложение согласился.
Этот первый клиент получил личное обслуживание. Он пользовался сервисом не с помощью сайта, еженедельно его лично посещали основатели проекта, которые до этого изучали и цены и наличие продуктов в ближайшем магазине. Они приносили потребителю пакет с продуктами и список специально подготовленных для него рецептов, а уносили с собой чек на $9.95.
Да, это было неэффективно и не масштабируемо по любым традиционным меркам. Вместо того, чтобы заниматься разработкой и развитием продукта основатели тратили время на то, чтобы удовлетворять потребности одного-единственного пользователя. Вместо того, чтобы продвигать продукт на миллионы потенциальных потребителей, они тратили время на то, чтобы собирать деньги с одного человека. Что хуже всего, на первый взгляд, этот подход не приближал их ни на шаг к созданию чего-то ощутимого. У них не было ни реальной прибыли, ни базы рецептов, ни базы по продуктам и ценам, даже по сути своей не было никакой компании.
Но на самом деле они делали огромный прогресс – каждую неделю они понимали все больше и больше о том, что должно быть в их продукте, чтобы он смог добиться успеха. Каждый новый клиент делал привлечение следующего клиента более простой задачей. Каждый клиент получал личное обслуживание, и это продолжалось до тех пор, когда издержки на личное общение не стали серьезно увеличиваться. Только после этого основатели начали тратить деньги на автоматизацию процесса, они автоматизировали процесс шаг за шагом, на каждом этапе получая возможность обрабатывать все больше и больше клиентов. Так и достигалось масштабирование. Сейчас Food on Table – это сервис, который работает в масштабах целой страны.
Будьте реалистами
У каждого стартапа есть бизнес-план с прогнозами того, сколько клиентов у них будет и сколько денег они будут зарабатывать и тратить через определенное время. Эти прогнозы обычно очень далеки от нового, что мы имеем в первые месяца работы над ним.Основные задачи на этапе начала работы – это:
- Честно оценить текущую ситуацию, невзирая на то, насколько сурова может оказаться правда.
- Запланировать эксперименты, которые могут приблизить реальные цифры к показателям, заложенным в бизнес-плане.
- Быть готовым к принятию решений, основанных на результатах экспериментов, а не собственных фантазиях и надеждах.
Предприниматели и сотрудники стартапов склонны переоценивать результаты своего труда. Мы хотим продолжать делать то, что начато, даже если письмена “Мене, мене, текел, фарес” уже четко виднеются на стенах нашего офиса. Мы все знаем святочные истории о компаниях, которые сумели выбраться из ямы и завоевать весь мир, но до нас не доходят правдивые истории о бесчисленном множестве остальных, кто пытался продолжать выбираться из ямы, но так и не смог это сделать.
Скучные цифры меняющие жизнь
Люди обычно представляют статистику и отчетность как скучнейшую вещь – неизбежное зло, которым надо заниматься, чтобы пережить конец отчетного периода и плановый аудит. Да, стандартная отчетность зачастую служит именно этой цели. Работа стартапа в условиях полной неопределенности плохо ложится в прокрустово ложе стандартных подходов к планированию и управления.Есть один очень простой вопрос, который стоит задавать любому стартапу: “Вы делаете ваш продукт лучше?”. Очевидный и всегда получаемый ответ на этот вопрос: “Да, конечно”. Следующий вопрос, который следует задать: “А как вы понимаете, что продукт становится лучше?” В подавляющем большинстве случаев вы получите не менее очевидный ответ: “За прошедший месяц мы запрограммировали столько-то новых функций, пользователям они нравятся, и общее количество зарегистрированных пользователях увеличилось на столько-то процентов – значит мы на правильном пути”.
Так обычно и производится оценка ситуации: мы убеждаемся в том, что мы выполнили план по разработке, может быть, поговорим с несколькими потребителями, и посмотрим на итоговые цифры по клиентской базе. К сожалению, эти цифры не говорят практически ни о чем.
Единственное, что может говорить о том, в правильном ли направлении движется стартап, – это то, насколько в результате экспериментов оказались близки к плановым показателям принципиальные допущения, которые вы сделали на этапе построения бизнес-модели.
Для этого нужно выполнить три простых шага.
- Понять, где вы находитесь сейчас по отношению к начальным принципиальным допущениям. Для этого нужно выпустить минимальный продукт и собрать необходимую статистику.
- Предпринять все меры для того, чтобы улучшить полученные показатели, если они сильно не дотягивают до начальных допущений.
- По результатам этих попыток сделать вывод – стоит ли дальше двигаться в намеченном направлении или стоит сделать «разворот»?
Начинать можно и с 10 долларов в день
Во многих случаях, для того, чтобы убедиться, что наша модель работает нам нужно оценивать несколько ключевых показателей: количество регистраций пользователей, количество загрузок, количество активных пользователей, количество покупок. Значит эти данные нужно собрать и проанализировать. Если мы возьмем систему контекстной рекламы с минимальной ценой клика в 10 центов и выберем подходящие ключевые слова, чтобы обеспечить клики хотя бы сотни пользователей, то мы сможем анализировать их поведение за 10 долларов в день.10 долларов в день – каждый день 100 новых пришедших людей. С маркетинговой точки зрения – это совсем маленькие цифры, с точки зрения эксперимента – этого вполне достаточно. Каждый день мы можем вводить какое-то новое свойство, а на следующий день оценивать, как это изменение повлияло на проценты конверсии. Эти изменения могут начинаться с простой переформулировки рекламного объявления для тестирования гипотезы ценности, они могут касаться изменения дизайна или даже внесения нового функционала. Все это можно каждый день оценивать на 100 новых пользователях и смотреть, как изменится их поведение. Только эта статистика может сказать, хорошо мы поработали или нет? Приблизились ли мы к построению бизнеса или еще нет?
Каждый день новые изменения, каждый день 10 долларов, каждый день 100 новых людей – каждый день новый эксперимент и новая оценка. Так можно шаг за шагом приближаться к успеху.
При этом важно понимать, что влияние этих изменений надо оценивать для каждого пользовательского сегмента. Надо по отдельности наблюдать, как сегодняшние внедренные изменения повлияли на завтрашних новых посетителей, и то, как они повлияли на всех предыдущих накопленных клиентов. Ведь в нашей бизнес-модели есть разные принципиальные допущения: одни допущения показывают, с какой динамикой должны прибывать новые пользователи, другие – с какой динамикой они отваливаются от использования сервиса. Для того, чтобы делать правильные выводы, все данные по разным категориям пользователей надо анализировать отдельно, а не заслонять реальность обманчивыми цифрами, тупо суммирующими количество всех клиентов за отчетный период.
Вот, новый поворот
Если результаты экспериментов показывают, что принципиальные допущения, сколько мы не бились, так и не нашли подтверждения в реальности – надо не боятся, а пересматривать стратегию развития. Такие развороты требуют мужества, но это вещь, которую необходимо сделать, причем чем раньше, тем лучше. Такие развороты бывают нескольких типов.- Отдельное свойство продукта может стать самостоятельным продуктом. А все остальные свойства оказываются никому не нужными.
- Сам продукт оказывается только частью процесса, который нужно автоматизировать. Надо создать новый продукт, в которым старый продукт станет одним из свойств.
- Оказывается, что продукт востребован, но только другой аудиторией, на которую не планировалось ориентироваться изначально. Сам продукт сохраняется, но происходит перефокусировка, в том числе и маркетинговая, на новую категорию потребителей.
- Оказывается, что у пользователей есть проблема, но вовсе не та, которую мы собирались решать изначально. Целевая аудитория сохраняется, но изменяется свойства продукта, так как он теперь предназначен для решения немного другой проблемы.
- Платформа становится продуктом или наоборот. Часто бывает, что вместо того, чтобы разрабатывать универсальную платформу для создания некой категории приложений, в реальности необходимо создать всего одно максимально нужное потребителю приложение – так платформа становится продуктом. Бывает и обратная ситуация – становится понятно, что вместо одного продукта необходима целая линейка кастомизируемых приложений, что приводит к тому, что продукт становится платформой.
- Замена высокомаржинальной штучной модели продаж на низкомаржинальную и массовую, и наоборот. Это обычно означает смену в приоритетах по объему охвата целевой аудитории – либо узкая платежеспособная, либо широкая, но менее платежеспособная.
- Изменяется понимании того, что является реальной ценностью продукта. Сам продукт сохраняется, но изменяется фокусировка в позиционировании продукта, чаще всего влечет изменение модели монетизации.
- Именуется понимание того, каким способом продукт может расти. Чаще всего вызывает изменение в понимании ценности продукта и, как следствие, способа его монетизации.
- Изменяется понимание того, по каким каналам сбыта продукт должен распространяться. Чаще всего заключается в выборе между использованием прямых продаж, поиском и использованием существующих партнерских сетей или построением собственной дилерской сети.
Рост по правилам
Когда мы говорим про возможные механизмы роста всегда важно разделять механизмы естественного роста стабильного бизнеса и результаты однократных или краткосрочных маркетинговых активностей. Эти рывки смогут вызвать резкие изменения в аудитории и доходах, но не смогут обеспечить длительный и стабильный рост. Если в бизнес-модели не заложен и не протестирован механизм естественного роста, то бизнес рано или поздно загнется.Механизм стабильного роста можно охарактеризовать очень просто – новые потребители приходят в результате тех или иных действий существующих потребителей. Возможных вариантов таких действий не так много.
Сарафанное радио
Удовлетворенный и восторженный пользователь радостно рассказывает о понравившемся ему продукте всем своим друзьям и знакомым. Эти действия очень трудно спрогнозировать, и делать принципиальные допущения по поводу того, что эти действия могут обеспечивать стабильный рост, скорее не стоит.Побочный результат использования продукта
Окружающие видят, какой продукт ты используешь, – это позволяет им либо узнать о существовании этого продукта, либо это может повлиять на их решение о его использовании. Еще один пример плохо прогнозируемых действий, подобные допущения тоже не стоит закладывать в бизнес-модель.Вирус
Распространение информации о продукте от человека к человеку. Хоть этот механизм и похож на сарафанное радио, но между ними есть существенная разница. Она состоит в том, что в случае вируса информация о продукте распространяется в процессе его обычного использования. Пользователи не выступают в качестве добровольных евангелистов, вирус передается вместе с тем, как они используют продукт. Вирус программируем.Хорошим примером такого вируса в свое время послужила добавление сообщения “P.S. Get your free e-mail at Hotmail” в каждое сообщение, посылаемое пользователем почтового сервиса HotMail. Добавление всего одной строчки позволило этому сервису за первые шесть месяцев после этого приобрести более миллиона новых пользователей, за следующие пять недель – еще миллион.
Как любое другое принципиальное допущение действие такого механизма имеет четкую количественную оценку, обычно выражаемую в виде коэффициента вирусности. Этот коэффициент определяется как отношение новых пользователей, пришедших в результате распространения вируса, к количеству существующих пользователей сервиса. Чем выше этот коэффициент, тем быстрее будет распространяться продукт. Значение этого коэффициента в 0.1 будет означать, что на десяток существующих пользователей придется один, пришедший в результате вируса. Правда, на этом этапе распространение вируса остановится, так как применение коэффициента будет означать, что на следующем шаге придет всего 0.1 пользователь, то есть никто. Вирус способен работать как механизм роста только в том случае, если значение его коэффициента будет больше 1, и каждый пользователь будет привлекать более одного нового пользователя.
Рекламная модель
Новые пользователи приходят на размещаемую рекламу. Работает только в том случае, если деньги, которые зарабатываются на пришедших пользователях, позволяют окупать свои расходы и тратиться на привлечение новых пользователей.У каждого пользователя есть свой жизненный цикл – период, в течение которого он будет пользоваться сервисом. За это время он заплатит сервису определенное количество денег. Это количество денег – ценность одного пользователя для сервиса. Эти деньги минус расходы на поддержание сервиса и образуют ту потенциальную прибыль, из которой может финансироваться реклама или другие способы привлечения пользователей. Если затраты на привлечение одного пользователя будут превосходить его ценность, то механизм работать не будет.
Модель подписки
Пользователь подписывается на использование продукта на какой-то срок, по окончанию этого периода происходит автоматическое возобновление подписки, если пользователь от нее явно не откажется.Такого рода механизмы основываются на высоких коэффициентах удержания существующих пользователей. Вся бизнес-модель базируется на том, что если пользователь начал использовать сервис, то ему придется предпринять существенные усилия, чтобы от него отказаться – например, меняя свой телефонный номер, отказываясь от всей накопленной в сервисе информации или тратя кучу усилий на перенос ее в новый сервис.
Самое принципиальное допущение, которое надо тестировать в этом случае – это коэффициент потери пользователей, то есть отношение количества пользователей, отказывающихся от его использования к объему всей пользовательской базы. Правила роста в этом случае тоже просты – если коэффициент прироста новых пользователей превосходит коэффициент потери, то сервис будет жить даже без особой рекламы и продвижения.
Ну и что дальше?
А дальше все очень просто: надо попробовать применить описанный поход к вашему стартапу. Вполне возможно, что для проверки основных гипотез – то есть для самого старта вам потребуется существенно меньшее количество денег и времени, чем вы предполагали изначально. Значит вам потребуется меньше инвестиций, за которые вы сможете отдать существенно меньшую долю. Хотя обычный инвестор, может быть, обычно заинтересован совершенно в обратном.Главстарт – необычный инвестор, поэтому мы готовы начать с того, чтобы дать как можно меньше денег стартапу. Мы начинаем с 20 тысяч долларов за 10% проекта. Не просто дать и забыть – кто выживает, тот выживет – а объяснить вам, как эти деньги можно и нужно с толком потратить, чтобы на выходе получить то, что может вызвать большее доверие у инвесторов и помогать реализовывать это в процессе.
Объясняем мы это обычно на проводимых нами встречах, носящих название Startup Weekend. На них мы стараемся на примерах ваших же идей и проектов помочь вам разработать схему получения первых результатов с минимальными инвестициями. Те, кому удастся это сделать, сможет получить инвестиции от Главстарта чуть ли не во время финальной презентации в воскресенье.
Естественно, что мы готовы продолжать поддержку и инвестировать в проект и после прохождения первого этапа.
Все ваши идеи мы принимаем по адресу idea@glavstart.ru. Пишите. Поможем.
Источники:
e-xecutive.ru
russia.startupweekend.org
0 коммент.:
Отправить комментарий