В полном отчаянии мы ввели опцию под названием ChatNow, позволяющую нажать кнопку и найти случайного собеседника в любой точке мира. Единственное, что у вас общего, — вы оба одновременно нажали на эту кнопку. И вдруг клиенты стали говорить: «О, это классно!»

Итак, мы приглашали их в офис, они использовали опцию ChatNow и иногда знакомились с кем-то, кто им нравился. Они говорили: «Ого, это отличный парень, я хочу добавить его в свой список контактов. Где мой список контактов?» И мы говорили: «Вам не нужен новый список контактов — вы можете пользоваться своим обычным списком контактов в AOL». Как вы помните, именно так мы собирались использовать наш сервис и надеялись, что это создаст сетевые эффекты и приведет к вирусному росту. Но клиент смотрел на нас и спрашивал: «Что я должен сделать?» И мы говорили: «Просто сообщите новому знакомому свой ник, чтобы внести его в свой список контактов». Тут он делал большие глаза и заявлял: «Вы что, шутите? Незнакомец в моем списке контактов?» На это мы отвечали: «Да, а иначе вам придется загрузить новый IM-клиент и создать новый список контактов». И человек говорил: «Вы хоть представляете себе, сколько IM-клиентов у меня уже есть?» — «Нет. Один? Или два?» Именно столько IM-клиентов использовал каждый из нас. Но подростки отвечали: «Да вы что! У меня их восемь!» Мы понятия не имели, сколько IM-клиентов принято использовать в их мире. Мы думали, что людям сложно осваивать новое программное обеспечение и они не станут перемещать своих друзей в новый список контактов. Оказалось, что это полная ерунда. Мы пытались рисовать диаграммы и показывать им, чем хороша наша стратегия, но клиенты не понимали, что такое сетевые эффекты и затраты на переключение. А когда мы пытались объяснить, почему они должны вести себя так, как мы хотим, они просто в изумлении качали головами.

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

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

Возможно, вы посочувствуете нам и простите мне мое упрямство. В конце концов, ведь это результаты моего многомесячного труда предстояло выбросить в мусорную корзину. Я круглыми сутками писал программы, чтобы наше IM-дополнение могло взаимодействовать с другими сетями — ведь именно на этом была основана первоначальная стратегия. Когда пришло время сделать крутой вираж и отказаться от нее, почти всю эту работу — тысячи строк кода — пришлось выбросить. Я чувствовал себя так, будто меня предали. Я был приверженцем гибкой методологии разработки программного обеспечения, позволяющей избежать излишних затрат. Тем не менее моя работа оказалась чрезвычайно затратной: я создал продукт, которым клиенты не стали пользоваться. Меня это ужасно угнетало.

Я задавался вопросом: раз уж мой труд оказался пустой тратой времени и сил, компания ничего не потеряла бы, если бы все эти полгода я провел на пляже, потягивая коктейли под зонтиком? Нужен ли я здесь? Может, было бы лучше, если бы я вообще ничего не делал?

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

Какое-то время я продолжал утешать себя тем, что «многому научился». Это облегчило мои страдания, но не надолго. Мне не давал покоя один вопрос: если все это делалось ради того, чтобы больше узнать о клиентах, то почему это заняло так много времени? Оправданы ли те усилия, благодаря которым мы получили важные знания? Могли бы мы сделать это быстрее, если бы я не был так поглощен усовершенствованием продукта, разработкой новых опций и устранением багов?

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

В последующие годы я постепенно находил ответы на этот вопрос. Концепция бережливого производства определяет ценность как создание преимуществ для клиента, а все остальное — затраты. Если речь идет о сфере производства, клиента не волнует, как сделан продукт, — ему нужно, чтобы он как следует работал. Но стартап еще не знает, кто его клиент и что для него ценно. Это одно из проявлений той самой неопределенности, с которой постоянно сталкиваются стартапы. Я понял, что необходимо найти новое определение ценности. И последующие успехи IMVU стали возможны, потому что в те первые месяцы мы выяснили, что же ценно для наших клиентов.

Но все наши действия, не помогавшие нам учиться, приводили к потерям. Так можно ли было учиться, не тратя столько усилий? Конечно, можно.

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