Текст книги "MVP. Как выводить на рынок товары и услуги, которые нравятся покупателям"

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

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

Рисунок 6.2. Приблизительная оценка показателя рентабельности инвестиций

Как только вы закончите с фрагментацией, оценкой трудозатрат и расстановкой приоритетов, у вас появится возможность представить полученные результаты в простой табличной форме. В такой таблице (см. Рисунок 6.3) будут перечислены все преимущества вашего ценностного предложения, и напротив каждого из них указаны соответствующие функции в виде блоков, расставленных в приоритетном порядке.

На Рисунке 6.3 я изобразил основные фрагменты (блоки) функций для каждого преимущества. Они выстроены в порядке убывания приоритета, слева направо. Чтобы не вписывать в эти блоки названия фрагментов функций, я применил буквенно-цифровое обозначение. Так вам будет легче мысленно заменить их на фрагменты функций, относящиеся именно к вашему продукту. Обозначение «M1A» расшифровывается как «функциональный блок A для преимущества “Мастхэв 1”»; «P2B» означает «функциональный блок B для “Преимущества производительности 2”»; а «F2C» означает «функциональный блок C для “Фишки 2”». Вы можете заполнить аналогичную таблицу, используя соответствующие метки для преимуществ и фрагментов функций, относящихся к вашему продукту.

Рисунок 6.3. Лист функциональных блоков, расставленных по приоритету для каждого преимущества

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

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

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

Фрагменты функций, которые, как вы считаете, должны входить в состав кандидата в MVP, далее следует внести в крайний левый ряд блоков, который можно озаглавить «v1» (версия 1), как показано на Рисунке 6.4. При этом оставшиеся блоки будут отодвинуты вправо. В продолжение этого процесса вы можете создать предварительную дорожную карту продукта, добавив столбцы для каждой последующей версии продукта. В эти столбцы вы будете вносить те фрагменты функций, которые планируете добавить при выпуске соответствующих версий.

Поскольку вы собираетесь стать лучшим на рынке по показателю «Преимущество производительности 3», функционал вашего кандидата в MVP должен включать в себя соответствующий блок функций с наивысшим приоритетом – P3A. Поскольку вы также планируете убедить пользователей в уникальности своего продукта при помощи «Фишки 2», соответствующий функциональный блок – F2A – также должен присутствовать в составе функционала вашего кандидата в MVP. И, конечно, он должен включать в себя все обязательные функции («Мастхэв»).

Рисунок 6.4. Определение функциональных блоков, входящих в разные версии кандидата в MVP

Следующую версию своего продукта – v1.1 – вы планируете дополнить функциональными блоками P3B и F2B для усиления «Преимущества производительности 3» и «Фишки 2», соответственно. В версии v1.2 вы планируете решить проблему «Преимущества производительности 1» с помощью добавления приоритетного блока функций P1A.

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

На Рисунке 6.4 для каждого из преимуществ кандидата в MVP в версии v1 я представил только по одному функциональному блоку. Однако на практике может оказаться, что для обеспечения соответствующего преимущества вам понадобится разработать не один, а два или три фрагмента функций. Это будет зависеть от конкретной ситуации, а также от того, насколько малы ваши фрагменты функций. Тем не менее, принцип их выбора остается прежним: приоритет должен быть отдан фрагментам функций, которые – для каждого из преимуществ – располагаются левее в составленном вами листе функциональных блоков (см. Рисунок 6.3).

Теперь давайте сделаем шаг назад и немного поразмыслим. Вы уже проделали большую работу на пути создания бережливого продукта. В вашем распоряжении имеются:

1. Сформированные гипотезы о целевых потребителях.

2. Сформированные гипотезы об их недостаточно удовлетворенных потребностях.

3. Сформулированное ценностное предложение, которое вы планируете реализовать, чтобы ваш продукт отличался от аналогов и превосходил их.

4. Сформированный перечень идей функций, которые, по вашему мнению, смогут удовлетворить потребности пользователей. Кроме того, эти идеи разбиты на достаточно мелкие фрагменты для удобства их разработки.

5. Оценка приоритетов всех фрагментов функций, полученная на основе показателя рентабельности инвестиций.

6. Перечень отобранных функций для кандидата в MVP, которые, как вы считаете, представляют для пользователей наибольшую ценность.

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

Глава 7
Создание прототипа MVP (шаг 5)

После того как вы определили набор функций для своего кандидата в MVP, вам захочется протестировать его на пользователях. Чтобы это сделать, необходимо будет создать пользовательский опыт (UX), который вы сможете показать клиентам. Напомню, что это является верхним уровнем пирамиды соответствия продукта рынку.

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

Ведутся оживленные дебаты по поводу того, что следует понимать под термином MVP. Некоторые яростно доказывают, что лендинговая страница сама по себе уже является MVP. Другие утверждают, что это далеко не так, настаивая, что MVP должен быть реальным работающим продуктом или, по крайней мере, интерактивным прототипом. Способ, которым я разрешаю эту дихотомию, заключается в осознании того, что и то и другое является методом тестирования гипотез, лежащих в основе MVP. Использование термина «MVP-тест» позволяет прекратить эти дискуссии. Данный термин более точно описывает суть и оставляет возможность закрепить термин «MVP» за реальными продуктами.

Многие неверно истолковывают термин «минимально жизнеспособный продукт», делая слишком значительный акцент на слове «минимально». Они используют это как предлог для создания неполноценного MVP, который обладает слишком малой функциональностью, чтобы считать его жизнеспособным. Другие ссылаются на слово «минимально», чтобы оправдать некачественный пользовательский интерфейс или ошибки в коде. Несмотря на то что MVP по определению является ограниченным по представленному в нем функционалу относительно всего объема ценностного предложения, то, что вы предоставляете на суд пользователей, должно быть выше определенной планки, чтобы иметь потребительскую ценность.

Рисунок 7.1. Внутреннее строение MVP

Диаграмма на Рисунке 7.1 иллюстрирует разницу между неправильным и правильным способами интерпретации MVP. Я адаптировал этот рисунок по образцу, созданному талантливым UX-дизайнером Юсси Пасаненом из Volkside (http://volkside.com).

Подобно моей иерархии потребностей веб-пользователей (см. Рисунок 4.2), на этом рисунке различные аспекты продукта представлены в виде слоев пирамиды. В данном случае для описания атрибутов продукта используется пирамида из четырех иерархических уровней: функциональность, надежность, удобство [использования] и восхитительность. Пирамида слева иллюстрирует ошибочное представление о том, что MVP представляет собой всего лишь продукт с ограниченной функциональностью, а надежностью, удобством использования и функциями, вызывающими восхищение пользователя, при его создании можно пренебречь. Правая пирамида показывает, что, хотя MVP и обладает ограниченной функциональностью, он должен быть «полноценным» в том смысле, что в нем находят свое отражение атрибуты, расположенные на всех трех более высоких уровнях.

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

Несмотря на то что термин «MVP-тест» обеспечивает удобное обобщение всех различных видов подобных тестов, между ними имеются ключевые различия. Существует два основных способа их классификации.

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

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

Когда при помощи повторяемого тестирования прототипа кандидата в MVP вы достигнете точки, в которой почувствуете, что с достаточной долей уверенности подтвердили соответствие продукта рынку, можно будет приступить к этапу создания реального MVP.

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

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

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

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

На Рисунке 7.2 представлена матрица, содержащая сводную информацию о классификации различных MVP-тестов на основе сравнения продуктовых тестов с маркетинговыми и качественных тестов с количественными. В каждой из четырех ячеек матрицы я перечислил соответствующие ей MVP-тесты. Далее я коротко опишу каждый из четырех видов тестов, представленных на рисунке.

Рисунок 7.2. Классификация MVP-тестов

Давайте начнем с качественных маркетинговых тестов, размещенных в верхней левой ячейке матрицы. Очевидно, что существует множество различных способов продвижения продуктов на рынке. Вместо составления длинного списка соответствующих тестов я объединил их все под одним наименованием – «Маркетинговые материалы». Тесты, относящиеся к данному типу, включают в себя демонстрацию потребителям маркетинговых материалов и получение соответствующей обратной связи. Маркетинговые материалы включают в себя все, что вы хотели бы представить своему пользователю: целевую страницу, видеоролики, рекламу, электронные письма и так далее. Цель таких тестов – понять, насколько убедительным для пользователей является представленный им маркетинговый материал и почему. Таким образом, вы получаете обратную связь не о самом продукте, а, скорее, о том способе, которым вы доносите информацию о нем.

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

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