Читать книгу "Монетизация инноваций. Как успешные компании создают продукт вокруг цены - Георг Таке"

Результаты появились быстро и удивили всех. К 2012 году, всего через два года после выхода на рынок, Guard завоевал более 60 % отрасли бритвенных лезвий в Индии, что в три раза превзошло долю других продуктов Gillette и сравнялось с доминирующей долей рынка у себя дома, в США. Влияние на клиентскую базу Gillette оказалось еще более существенным, учитывая общий потенциальный рынок Индии в 400 млн мужчин по сравнению с 94 млн в США[25].

Это только краткосрочные результаты. Альберто Карвало из P&G отметил, что новые бритвы сумели высвободить место в шкафчиках индийских мужчин для других товаров компании. «Первая задача – привлечь больше потребителей Gillette. Когда им понравится новая бритва, будет легче продать им другие товары», – сказал он[26]. P&G ожидает, что Guard увеличит пожизненную стоимость компании благодаря огромному количеству потребителей в Индии – сегодняшних и будущих.

Почему обсуждение должно состояться как можно раньше: три преимущества

Как мы видели на примере Gillette, крайне важно поговорить с потенциальными клиентами об их готовности платить за ваш продукт, прежде чем создавать его. Это даст вам три важных преимущества.

1. Вы узнаете с самого начала, можно ли монетизировать ваш продукт или нет.

2. Вы сможете приоритизировать характеристики и спроектировать продукт с необходимым набором функций.

3. Вы сможете избежать четырех типов ошибок монетизации.

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

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

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

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

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

Инновационная команда выбрала несколько сотен потенциальных клиентов, чтобы выяснить, сколько они готовы платить. Во-первых, они объяснили концепцию нового продукта и функций, которые собирались разработать. Затем постарались понять, видят ли клиенты какую-либо ценность в этой концепции. Главное, они спросили клиентов, готовы ли те платить. Оказалось, что клиентам понравилась концепция, и они готовы заплатить от $10 до $20 за ежемесячную подписку, как показано на рис. 11.

Рис. 11. Распределение готовности платить

Разговор с клиентами продемонстрировал, что они готовы платить за продукт компании. Менеджеры действовали уже не вслепую. Затем инновационная команда шагнула еще дальше и выяснила, за какие именно функции клиенты хотят платить. Перед разговором с клиентами команда считала, что одна из самых крутых функций – та, которая позволяла покупателям видеть, пользовался ли кто-то из их контактов на Facebook услугами того продавца, который их заинтересовал. Команда считала, что эта функция сыграет важнейшую роль в создании доверия. Они с таким энтузиазмом разрабатывали ее и приоритизировали как основную функцию. Конечно, клиенты захотят заплатить за нее, как и за все остальные функции, не так ли?

Но когда компания проверила, верно ли это, оказалось, что клиенты готовы заплатить только за десять из двадцати пяти функций (рис. 12). Из этих десяти – функция Facebook заняла седьмое место. С точки зрения клиентов, это было дополнительной «приятностью», а не абсолютной необходимостью. Клиенты настолько привыкли доверять мнению третьей стороны (как на других сайтах), что мнение друзей с Facebook мало заботило их.

Генеральный директор решил сосредоточиться на десяти функциях, ценных для клиентов. А остальные пятнадцать? Забудьте о них.

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

Рис. 12. Готовность платить за функции продукта

Анализ готовности платить помог компании избежать нагромождения лишних функций.