Книга: Как создать продукт, который купят. Метод Lean Customer Development
Назад: Глава 8 Как заниматься развитием потребителей, если они у вас уже есть?
Дальше: Поиск «правильных» потребителей

Адаптация концепции MVP

То, что хорошо для стартапов, может оказаться полезным и вам.
Если вы читаете блоги, посвященные стартапам, практикующим бережливые методы, вы, наверное, знаете о таких приемах, как тот, который применяет директор по маркетингу TripAdvisor Барбара Мессинг. Когда она хочет оценить интерес потребителей к очередному пакету туристических услуг, она помещает на сайт компании соответствующий рекламный баннер. Если посетители сайта не обращают на него внимания, значит, пакет им не нужен и им не стоит заниматься. Если же они кликают по баннеру, выскакивает окно с надписью «Ошибка 404 (страница не найдена)». Если баннер кликает достаточное количество пользователей, TripAdvisor создает новый продукт. Это эффективный и дешевый инструмент оценки потребительского спроса, но если вы не хотите воспользоваться им на своем сайте, знайте: вы не одиноки.

Все должно работать

Добавляя к готовому продукту неработающую функцию, вы делаете его более сложным и менее надежным. Клиенты, ценящие надежность продукта и доверяющие вам, заметив неработающую ссылку или другой сбой, могут подумать: «А в чем еще нельзя полагаться на этот продукт?».
Несколько лет назад я наблюдала за тестированием одного сайта, предоставляющего финансовые услуги, которое сама же только что переделала. Отклики пользователей неожиданно оказались негативными. Один из участников теста с ходу заявил: «Я больше никогда не буду пользоваться этим сайтом».
Почему?
Он указал на нижнюю часть экрана и сказал: «Здесь нет ссылки на политику конфиденциальности».
Этот человек был помешан на конфиденциальности? Я была поражена: «А вы всегда ищете эту ссылку, прежде чем начать пользоваться сайтом?»
Мой собеседник смутился: «Я знаю, что на банковских сайтах внизу должен быть изображен маленький замочек и дана ссылка на политику конфиденциальности, иначе сайтом лучше не пользоваться».
Не подумав о крошечном маркере надежности, я, сама того не ведая, испортила впечатление о продукте. Пока не пришли новые участники теста, я быстро добавила в демоверсию изображение замочка и неработающую ссылку. Реакция клиента мгновенно изменилась: теперь сайт ему нравился.
Даже подготовив блестящую демоверсию, вы можете столкнуться с клиентами, предъявляющими к продукту завышенные требования. Я встречала руководителей компаний, которые приходили в ярость, заметив опечатку в тексте на слайде PowerPoint. Люди, работающие в стартапах, любят повторять: «Если вам не стыдно за первую версию продукта, значит, вы затянули с выходом на рынок». А работники уже известных компаний знают, что если первая версия окажется неудачной, шанс сделать вторую может и не представиться. Не пожалейте нескольких часов на проверку правописания, работоспособности ссылок и качества изображений.

Красивый, но несуществующий продукт

С другой стороны, если демоверсия или опытный образец будут слишком хороши, потребители могут подумать, что у вас уже есть продукт (или вот-вот будет готов). Они могут отложить покупку или апгрейд, решив, что лучше дождаться новой версии. И знаете, что произойдет, если ваша гипотеза не подтвердится и вы откажетесь от разработки продукта или новой версии? Разочарованные клиенты отвернутся от вас.
Сделайте эскизы
Даже если вы недвусмысленно дали понять потребителям, что не представляете им будущие продукты, а всего лишь изучаете потребности клиентов, и не раз повторили, что представленная версия будет сто раз переработана, им все равно будет трудно смириться с тем, что они не получат понравившийся продукт. Так уж устроена человеческая психика. Могу только посоветовать воспользоваться такой программой, как Balsamiq, которая позволяет быстро сделать несколько качественных, хотя и очень простых, рисунков. Эскиз, сделанный в Balsamiq (рис. 8.1), никто не примет за изображение готового продукта.
Возьмите другое доменное имя
Если вам нужно продемонстрировать более реалистичные изображения продукта, вы можете «спрятаться» за другим доменным именем или брендом. Ваш «анонимный» сайт может восприниматься как очень красивый и функциональный – до тех пор, пока его дизайн отличается от вашего фирменного дизайна. И в Yodlee, и в KISSmetrics мы использовали другие домены, чтобы протестировать опытные образцы перед тем, как приступить к созданию готового продукта.

Скорее «работоспособный», чем «минимальный»

Компании, у которых уже есть потребители, должны подходить к созданию MVP несколько иначе, чем стартапы.
Работники Aetna, занимающиеся развитием продукта, используют термин «минимально продаваемый продукт». В Yammer мы делали упор на понятии «работоспособный». Долгоиграющий продукт должен быть несколько шире и сложнее «минимального».

 

У стартапов все иначе
В стартапах MVP – это минимальный продукт, способный вызвать реакцию потребителей, отличную от нейтральной. Это связано с тем, что риски, с которыми сталкиваются компании-новички, отличаются от рисков сложившихся компаний. Как говорит Стив Бланк: «В первый день творения у стартапа нет клиентов. В этот день стартап – предприятие, основанное на вере и строящееся на догадках». Для стартапа первоочередной риск связан с вопросом о том, нужна ли вообще кому-нибудь новая идея. Стартапы должны радоваться даже самому слабому подтверждению интереса к продукту – например, клику по ссылке или посещению вашей страницы.
Вспомним пример TripAdvisor. На сайте помещали баннер. Клиенты могли щелкнуть по нему, а могли и проигнорировать. С одной стороны, отсутствие клика указывало на нейтральную реакцию клиентов, которые не желали узнать о новом продукте. С другой стороны, клик сам по себе мало о чем говорил. Он мог свидетельствовать о природном любопытстве пользователя, о том, что его что-то заинтересовало или что он просто заметил рекламное объявление. Но клик не подтверждал готовность клиента достать кредитную карту и заказать тур (рис. 8.2).

 

Вы знаете, что это кому-то нужно
Если у вас уже есть продукты и потребители, вы уже понизили риск того, что ваш продукт никому не интересен. Вы можете уверенно предположить, что он хотя бы до некоторой степени нужен вашим покупателям. Однако при помощи MVP вы можете узнать больше.
В компании Yammer, которая сегодня вошла в состав Microsoft, мы определяли MVP как «минимальный продукт, необходимый для создания ценностного предложения и сбора информации о соответствующем поведении потребителей». Минимально работоспособная функция позволяет клиентам взаимодействовать с продуктом. Понять, будут ли они вновь обращаться к нам и продукту, можно при помощи аналитических инструментов. Чтобы узнать, что клиенты думают о продукте, мы также использовали качественные методы изучения потребителей. Лучше применять сочетание обоих подходов.
Для Yammer успешный MVP – это продукт, позволяющий сделать следующее заключение: «Эта идея, видимо, стоит того, чтобы вложить в нее средства, и вот почему…» (или: «Идея не стоит того, чтобы в нее инвестировать, и вот почему…»).
Не совсем «минимальный»: клиенты жалуются, но не уходят
С одной стороны, если продукт разочаровывает или раздражает клиентов, значит, он недостаточно хорош. С другой стороны, если потребители жалуются, это хороший признак.
Жалобы потребителей – признак интереса к продукту. Они указывают на то, что потребители достаточно ценят опыт использования продукта, чтобы желать его усовершенствования, позволяющего продолжать работать с ним.
Ищите тех, кому мало «минимума»
Если менеджеры по продукту и дизайнеры начинают задаваться вопросом «А что, если?..» и рассматривать различные варианты использования продукта, они выходят за рамки понятия «минимальный». Вообще говоря, специалистам, не привыкшим практиковать бережливый подход, трудно оставаться в рамках «минимализма». Им больше нравится создавать законченные, полнофункциональные и работающие продукты. Они не очень любят минималистские версии. Впрочем, никто их не любит.
Вот случай, когда можно (с осторожностью) провести границу между «минимальным» и полнофункциональным продуктом. Компания Yammer запускала облегченную версию функции совместного редактирования документов. Прежде чем приступить к разработке полноценной версии, нужно было получить ответы на два вопроса. Нужны ли потребителям эти функции вообще? Будет ли процесс совместного редактирования документов удобным, а сама функция – полезной?
Чтобы получить ответы на эти вопросы, нужно было разработать законченный бизнес-процесс, включающий следующие шаги:
• создание документа;
• редактирование документа;
• приглашение других участников процесса для совместного редактирования документа;
• возможность отличать исправления, сделанные одним участником процесса, от исправлений, сделанных другими участниками;
• сохранение изменений.

 

Первая версия продукта не давала возможности решать многие задачи. Нельзя было отменить исправления, просмотреть историю редактирования или скопировать и переслать документ по электронной почте.
Это была очень неудобная версия. Кому понравится делать исправления, не имея возможности их удалить. Однако мы понимали, что главный риск – это если вообще никто не будет пользоваться функцией совместного редактирования. Никто не захочет редактировать документы, не станет их создавать и посылать по электронной почте. На этом фоне невозможность удалить исправления могла раздражать потребителей только в том случае, если бы они ее заметили, начав работать с программой.
Отсутствующие опции были нужны при работе с полнофункциональной программой, но не для того, чтобы оценить первоначальное ценностное предложение. Мы вложили бы средства в усовершенствование продукта только в том случае, если бы подтвердилось наличие спроса на первую версию.
Стандартные возражения против MVP
Поскольку практика использования MVP получает все более широкое распространение в командах Microsoft, мне приходится выслушивать ряд стандартных возражений против него.
Возражение: Ожидания наших потребителей очень высоки, поэтому мы не имеем права предлагать им MVP.
Ответ: Предлагая потребителям MVP, мы не предлагаем им неполноценный продукт. Дизайн и функции продукта могут быть на самом высоком уровне; просто его можно использовать не во всех случаях. Если наша гипотеза верна, мы предлагаем потребителям некую ценность уже сейчас, а позднее мы ее увеличим. Если же гипотеза неверна, мы можем утешаться тем, что создали никому не нужный, но хотя бы не масштабный продукт. Сейчас, общаясь с работниками Microsoft, я не говорю о создании «минимально работоспособного продукта». Слишком долго объяснять, что «MVP» – не синоним слова «дрянь». То, чем мы занимаемся, я называю «развитием, основанном на предположениях», делая упор не на качество продукта, а на оценку идей.
Возражение: Мы должны задействовать все платформы.
Ответ: Мы разрабатываем функцию только для Android. Если никто не будет ей пользоваться, можно будет только порадоваться тому, что мы не выпустили бесполезные версии для iOS и Windows Phone, MacOS и Windows 8. А если опция окажется востребованной, доработаем ее для других платформ.
Возражение: Мы должны предлагать продукт миллионам пользователей.
Ответ: Сейчас мы испытываем продукт на небольшой группе покупателей. Если доступ к нему получат тысячи человек, нам придется делать высококачественный продукт, соответствующий их запросам. Но разработка полнофункционального продукта без уверенности, что его будут покупать, может оказаться напрасной тратой инженерных ресурсов. Если будет доказано наличие потребительского спроса, мы успеем повысить качество продукта, прежде чем он станет доступным для тысяч.
Возражение: Потребителей не удовлетворит минимальный набор функций.
Ответ: Это не последняя версия. Давайте подумаем о том, как в минимальный срок предложить потребителям максимум ценности. Одни функции используются бóльшим количеством пользователей, чем другие. Одни функции задействуются ежедневно, другие – не чаще чем раз в неделю. Начнем с важнейших, приоритетных функций, чтобы собрать информацию и быстро оценить наши предположения. Если клиенты будут недовольны отсутствием каких-либо функций, их жалобы помогут нам правильно расставить приоритеты и определить порядок работы.
Возражение: Нам придется постоянно менять дизайн.
Ответ: Поддержка постоянного дизайна влечет за собой куда более серьезные риски. Мы долго не будем двигаться вперед или вложим кучу денег в новый полноценный дизайн, который может в итоге негативно повлиять на удобство, а значит, частоту использования продукта. Кроме того, не стоит менять дизайн до разработки новых функций. Если мы убедимся в том, что незначительные изменения сделают продукт более удобным, можно будет говорить о совершенствовании дизайна в целом.
Мой опыт показывает, что такие контраргументы стимулируют дискуссию. Они не гарантируют, что ваша команда, занимающаяся разработкой продукта, успешно ответит на возражения и сможет беспрепятственно создавать MVP. В крупной компании невероятно трудно преодолеть все препоны на пути к внедрению развития потребителей. Но каждый новый успех послужит еще одним свидетельством того, что этот подход позволяет снижать риски и создавать отличные продукты.
Назад: Глава 8 Как заниматься развитием потребителей, если они у вас уже есть?
Дальше: Поиск «правильных» потребителей