Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели

В главе 6 мы говорили о том, что минимально рабочий продукт нужно создать так, чтобы в нем не было лишних функций, превышающих потребности ранних последователей. Это запустит механизм роста, который поможет добраться до этой целевой аудитории. Однако, чтобы привлечь клиентов основного рынка, нужны огромные дополнительные усилия. Если у нас есть продукт, популярный среди ранних последователей, теоретически его разработку можно остановить. Рост будет продолжаться до тех пор, пока этот первоначальный рынок не исчерпает себя. Затем он замедлится или даже полностью остановится. Проблема в том, что такое замедление может длиться месяцами или даже годами. Вспомните: в главе 8 мы говорили о том, что с IMVU именно так и случилось — и именно по этой причине.

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

Та же проблема возникает у крупных компаний. Их прошлые успехи были основаны на точно настроенном механизме роста. Если он замедляется или перестает работать, а у компании нет новых инновационных проектов, способных обеспечить новые источники роста, возникает кризисная ситуация.

И это может произойти с компанией любого размера. Поэтому нужно одновременно настраивать механизм роста и развивать новые источники роста на тот случай, когда этот механизм перестанет работать. О том, как это сделать, мы поговорим в главе 12. Но для того, чтобы компания смогла действовать таким образом, нужно создать организационную структуру, культуру и дисциплину, которые способны справляться с быстрыми и зачастую неожиданными изменениями. Я называю это адаптивной организацией, и это — тема главы 11.

Глава 11 Адаптация

Когда я был техническим директором компании IMVU, мне казалось, что, за редкими исключениями, я хорошо выполняю свои обязанности. Я создал гибкую организацию, и мы успешно экспериментировали с методами, которые потом были включены в систему «экономичный стартап». Но несколько раз возникали ситуации, когда я вдруг понимал, что не справляюсь с работой. Для человека, ориентированного на результат, это очень неприятно. Хуже всего было то, что я не получал никакой обратной связи. А если бы получил, она могла бы быть примерно такой:

«Дорогой Эрик!

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

Всего наилучшего!»

Каждый раз в такой ситуации я начинал ломать голову над тем, что делать. Я знал, что компания растет и нам нужны дополнительные процессы и системы, которые позволяли бы координировать операции при каждом «скачке» в увеличении размера. Ведь я так часто видел стартапы, потерявшие гибкость и погрязшие в бюрократии из-за неуемного стремления к «профессионализму».

IMVU не могла себе позволить обойтись вообще без всяких систем, и вы тоже не можете себе этого позволить. Стартап всегда очень уязвим. Мне уже приходилось сталкиваться с ситуацией, когда компания создала избыточную архитектуру в попытках предотвратить любые проблемы, какие только могут возникнуть, и это мешало ей создавать продукты. Я видел компании, у которых возникали огромные технические трудности как раз в тот момент, когда популярность продукта была на пике. Для руководителя отдела это катастрофа, потому что все считают, что причина всех бед — в плохой работе какого-то отдела. т. е., его отдела. У компании возникли проблемы — и это ваша вина.