Так, команда Mobile Bazaar (внутреннее название для ищущих решение проблемы ценообразования для фермеров), чтобы определить потенциал решения, экспериментировала с несколькими простыми прототипами. Одним прототипом стал аукцион по типу eBay, где фермеры могли предложить свои товары покупателям напрямую. Впрочем, первые тесты виртуального прототипа, проведенные в PowerPoint, дали понять, что эта система будет слишком сложной в установке и использовании для фермеров (большинство из них были плохо образованными и не имели опыта обращения с компьютерами).

При этом команда заметила, что у всех фермеров есть мобильные телефоны и все они умеют отправлять и получать сообщения. Тогда команда протестировала виртуальный прототип, а затем и минимально жизнеспособный продукт решения, позволявший собирать информацию о ценах, которые готовы были заплатить покупатели и посредники, – эта информация в режиме реального времени рассылалась фермерам с помощью текстовых сообщений. Используя эту информацию, фермеры принимали решение, когда и кому они продадут товар. Команда под видом конечного ПО посадила трех своих сотрудников вручную рассылать фермерам сообщения и стала смотреть, как они будут отвечать. Отклик фермеров был весьма положительным. Спустя год у Mobile Bazaar было 180 тыс. подписчиков, а исследования показали, что цены выросли в среднем на 16 %.

Пример Mobile Bazaar демонстрирует не только пользу конкретных прототипов, но и более общий принцип метода инноватора: «Двигайся широко, чтобы двигаться узко». В Intuit применяют этот принцип, выдавая как можно больше решений и называя это «джем решений» (solution-jam), а затем сокращая их количество до шорт-листа тех, что пригодны для создания прототипов. После отбора как минимум трех решений начинается «кодовый джем» (code-jam), цель которого – создание рабочего прототипа программного обеспечения, не идеального, но достаточно хорошего для проверки его на покупателях. Таким образом, за четыре недели Intuit продвигается от болевого штурма к проверенному на покупателях прототипу, то есть неоднократные быстрые эксперименты с покупателями предшествуют поступлению решения в разработку программного обеспечения.

Так или иначе мы будем доказывать, что по-настоящему обрадовать покупателя можно лишь неожиданным пониманием проблемы, не понятой остальными, а затем – превзойденными ожиданиями покупателя. Именно поэтому главная задача этой стадии процесса – создание «минимально отличного продукта», того, что «некомфортно узок» с точки зрения набора характеристик, но замечательно делает свою работу{28}.

Каарен Хэнсон из Intuit настаивает: «Пока вы не поняли, как порадовать покупателя, даже не думайте о бизнес-модели»{29}. Но если вы нашли решение, которого хочет покупатель, готовьтесь начать искать лучший способ передачи своего решения в руки покупателю по цене, которая даст доход, намеченный вашей стратегией. Хотя большинство менеджеров считают, что понимают, как выводить продукт на рынок, многие компании убили свои новые продукты, помещая их в существующую бизнес-модель. Например, менеджеры часто используют для новых продуктов те же каналы дистрибуции, похожие маркетинговые и ценообразовательные стратегии и т. д., что и для уже существующих. Но даже когда инновации кажутся похожими, они часто требуют своей уникальной бизнес-модели. Чтобы должным образом выверить бизнес-модель, нужно раскрывать перед своими покупателями и утверждать с ними свою стратегию выхода на рынок. В ходе этого процесса необходимо определить, как заполучить покупателя и как на него влиять, как устанавливать цену и какие потребуются ресурсы, чтобы вывести ваше решение на рынок.