Итерации и развороты на пути к соответствию рынку
В предыдущей главе я объяснял, как проводить тестирование с участием пользователей для определения того, насколько ваш MVP соответствует рынку. Далее я расскажу о том, что следует делать после завершения каждого этапа тестирования. Бережливое производство представляет собой процесс обучения и быстрых итераций, направленных на улучшение продукта. Это означает, что вы используете информацию, полученную в ходе обратной связи с пользователями, для уточнения базовых гипотез и совершенствования MVP, чтобы затем вновь протестировать его на пользователях. Естественно, что вы хотели бы переходить от одного раунда пользовательского тестирования к следующему как можно быстрее и видеть, что с каждым переходом ваш продукт становится все более соответствующим рынку. Из этой главы вы узнаете, как это сделать.
Цикл: «Создание – Измерение – Обучение»
Эрик Рис в своей книге «Бережливый стартап»[19] (Lean Startup – является зарегистрированной торговой маркой Эрика Риса) обсуждает концепцию итеративного обучения. Описанный им цикл «Создание – Измерение – Обучение» помог многим людям понять важность применения итерационных методов совершенствования и обучения. Но, основываясь на своих наблюдениях за тем, как некоторые люди понимают и пытаются применять данную концепцию на практике, я вижу необходимость в обсуждении некоторых нюансов этой темы.
Важно уточнить, что термин «Создание» в контексте рассматриваемого цикла, вовсе не означает, что на этом этапе вы действительно должны создать полноценный продукт. Вполне подойдет и набор интерактивных вайрфреймов, которые вы можете протестировать на пользователях. Вообще под «созданием» здесь подразумевается просто получение чего-то, что вы можете протестировать. Это может быть как реальный продукт, так и проектные артефакты. «Спроектировать нечто для проведения тестирования» – так, на мой взгляд, выглядит более точная формулировка, поэтому я предпочитаю применять для описания этого шага термин «Проектирование» вместо «Создание». Задача состоит в том, чтобы получить то, что позволит вам проверить свои гипотезы с наименьшими затратами ресурсов.
«Измерение», как правило, подразумевает применение числовых данных, но имейте в виду, что в данном случае «мера» не обязательно должна иметь количественное выражение. Многие люди склонны использовать в качестве аргументов числовые показатели. Я согласен, что наличие таких данных весьма полезно, но A/B-тестирование – не единственный способ проверки гипотез или получения ценной информации. Все, что вы узнаете, наблюдая за пользователями, подпадает под понятие «Измерение». Сюда же – несмотря на отсутствие статистической измеримости – относятся и результаты, полученные в ходе качественного тестирования. Ключевым моментом является то, что на этом шаге цикла вы проверяете свои гипотезы на потребителях. Следовательно, термин «Тестирование» был бы более точным для его обозначения.
Шаг «Обучение» вызывает особый интерес. На самом деле, на этом этапе происходят две вещи. Во-первых, вы узнаете что-то новое из результатов каждого теста. Во-вторых, вы используете полученные знания для модификации гипотез, на которых и был построен проведенный вами тест. Чтобы стало понятнее, разделите процесс «Обучение» на два отдельных этапа: «Изучение [результатов тестирования]» и «Выдвижение гипотезы». Если вдуматься, весь этот цикл начинается не с «Создания», а с выдвижения первоначальных гипотез. Иначе как вы смогли бы принять решение о том, что именно вы хотите создать?
Цикл: Гипотеза – Проектирование – Тестирование – Обучение
По вышеуказанным причинам я использую модифицированную версию цикла Создание – Измерение – Обучение, который в моей интерпретации выглядит так: Гипотеза – Проектирование – Тестирование – Обучение (см. Рисунок 10.1).
Рисунок 10.1. Цикл: Гипотеза – Проектирование – Тестирование – Обучение
Проходя по шагам этого цикла, вы переходите из пространства проблем в пространство решений и обратно. Вы начинаете с выдвижения «Гипотезы», формулируя свои предположения о проблемном пространстве. На этапе «Проектирование» вы определяете наилучший способ проверки ваших гипотез. Создание на основе гипотез проектного артефакта или продукта переносит вас из пространства проблем в пространство решений. На этапе «Тестирование» вы показываете свой продукт или артефакт потребителям и проводите наблюдения, которые обеспечивают вас информацией, необходимой для выполнения следующего шага – «Обучения». Вы завершаете цикл, используя знания, полученные на этапе обучения, для пересмотра и улучшения своих гипотез. Пересмотренные гипотезы становятся основой для осуществления следующей итерации цикла. Подведем итог: вы тестируете и совершенствуете свое понимание проблемного пространства, показывая пользователям продукт или проектный артефакт в пространстве решений, и получаете от них обратную связь.
Чем быстрее вы пройдете обучение, тем раньше сможете обеспечить дополнительную потребительскую ценность и достичь соответствия продукта рынку. Но обучение – это всего лишь один из этапов процесса. Чтобы получить дополнительные знания, вам придется снова пройти весь цикл. Если представить его в виде поля для игры «Монополия», то шаг цикла под названием «Обучение» будет соответствовать полю «Старт», которое вы проходите на каждом круге. В игре вы зарабатываете за прохождение этого поля 200$; в процессе разработки бережливого продукта вы получаете новые знания, подтвержденные результатами тестирования. Прохождение этапов «Обучение» и выдвижения «Гипотезы», как правило, не занимает много времени, поэтому скорость прохождения полного цикла обычно зависит от того, насколько быстро вы сможете выполнять «Проектирование» и «Тестирование».
По мере того как вы будете подтверждать или опровергать свои гипотезы и формировать новые, необходимо обращаться к пирамиде соответствия продукта рынку, вновь приведенной на Рисунке 10.2. Для каждой гипотезы вы должны определить, какому слою пирамиды она соответствует. Любой слой пирамиды основывается на гипотезах, сформированных на уровне, расположенном непосредственно под ним. Вносить изменения на уровнях, находящихся вблизи вершины пирамиды, не так уж сложно, в то время как пересмотр гипотез, лежащих вблизи ее основания, может иметь критические последствия для всех верхних слоев. Например, изменение UX-дизайна страницы с целью сделать ее более удобной для использования можно считать незначительным. Но давайте предположим, что ваше ценностное предложение основывалось на гипотезе о неважности некого потребительского преимущества, однако тестирование на пользователях показало, что на самом деле это не так. Теперь вам придется вносить изменения в свое ценностное предложение, что, в свою очередь, повлияет на набор функций MVP и UX-дизайн продукта. Вот почему необходимо в первую очередь сосредоточиться на решении проблем, возникающих на самом низком уровне, обрабатывая ту информацию, которую вы получаете в ходе пользовательского тестирования. Как только вы убедитесь в том, что все проблемы устранены, можно будет перенаправить усилия на решение задач, относящихся к следующему, более высокому уровню.
Рисунок 10.2. Пирамида соответствия продукта рынку
Итеративное пользовательское тестирование
Как я уже указывал в главе 9, каждый пользовательский тест предоставляет ценную информацию о вашем MVP. По завершении каждого раунда тестирования полезно обсудить его результаты с командой разработчиков, чтобы поделиться наблюдениями и обобщить полученные знания. Я рекомендую использовать таблицы (подобные Таблице 9.1) для фиксации ключевых результатов, полученных в каждом раунде пользовательского тестирования.
Подводя итоги, вы можете получить сводные данные по всем участникам, чтобы понять, сколько из них (в процентном отношении) дали одинаковые, положительные или отрицательные, отзывы. Это должно помочь определить приоритетность внесения необходимых изменений в MVP. Если все или большинство пользователей указали на наличие одной и той же проблемы, ее решение должно быть более приоритетным. Если же какой-то другой недочет был отмечен всего одним или двумя пользователями, его можно отправить в конец очереди на исправление. Кроме этого, необходимо определить, каким вопросам вы планируете уделить особое внимание во время следующего раунда тестирования.
Раунд первый
Давайте вернемся к примеру, который был представлен в главе 9. Для начала мы обобщим результаты первого раунда тестирования с участием пяти пользователей в одном столбце Таблицы 10.1. Вы можете заметить, что я удалил из результатов положительные отзывы. Это сделано для упрощения. Итак, по результатам первого раунда тестирования мы выявили четыре проблемы:
1. 80 % пользователей пожаловались на отсутствие функции Y;
2. 60 % пользователей не нашли ссылку «Зарегистрироваться»;
3. У 60 % пользователей возникли трудности с регистрацией;.
4. 40 % пользователей не поняли наш слоган.
Давайте рассмотрим каждую из них более подробно. Тот факт, что функция Y отсутствует, является проблемой формирования функционала MVP. В данном случае эта функция входила в наш расширенный список. Мы сочли ее ценной, но планировали создать позже и не посчитали нужным включить ее в MVP. Теперь, когда в результате тестирования мы выяснили, что пользователи ожидали увидеть ее в составе тестируемой версии продукта, принято решение о ее добавлении. Наш коллега уже работает над созданием дизайна для функции Y, и по готовности, мы добавим его в проектные артефакты.
Таблица 10.1 Отслеживание результатов нескольких раундов пользовательского тестирования
Тот факт, что пользователи не нашли ссылку «Зарегистрироваться», является проблемой визуального дизайна. Чтобы ее исправить, наш визуальный дизайнер перенесет ссылку на более видное место, увеличит ее размер и отобразит в виде кнопки, используя при этом цвет, который будет хорошо заметен на экране.
Трудности с регистрацией относятся к проблемам дизайна интерактивности. Для устранения данной проблемы решено изменить процесс регистрации с учетом мнений пользователей.
Тот факт, что многие участники тестирования не поняли наш слоган, является проблемой целевого месседжа. Оказывается, используемая формулировка не смогла донести смысл, который мы в нее вкладывали. В результате слоган не смог эффективно отразить отличительные преимущества нашего продукта. Для исправления ситуации мы проводим мозговой штурм, чтобы придумать новые варианты. Наиболее предпочтительная версия будет вынесена на суд пользователей во втором раунде тестирования. Все произведенные обновления обязательно отражаются в проектных артефактах.
Раунд второй
Теперь, когда четыре проблемы, выявленные в первом раунде, устранены, мы можем вновь провести тестирование нашего продукта на пользователях. Полученные результаты фиксируем в столбце «Раунд 2» Таблицы 10.1. Мы видим, что после добавления функции Y никто из новых пользователей не пожаловался на ее отсутствие, что, конечно же, свидетельствует о значительном прогрессе в этом направлении. Еще одним серьезным достижением является тот факт, что все пять участников второго раунда тестирования на этот раз обнаружили ссылку «Зарегистрироваться».
Однако 40 % пользователей вновь сочли процесс регистрации слишком сложным, несмотря на то что мы его переработали. Такое случается. Переделка продукта на основе пользовательских отзывов не всегда получается идеальной с первого раза. В ходе проведения второго раунда тестирования пользователи уже не сталкивались с некоторыми специфическими трудностями, относящимися к сфере UX, однако одно из наших исправлений сработало не так хорошо, как мы ожидали. Кроме того, мы заметили незначительные проблемы с некоторыми новыми элементами дизайна. Учитывая полученные результаты, мы решили провести совещание с участием всех членов команды, чтобы обсудить проблемы, с которыми пользователи все еще сталкиваются при регистрации, провести мозговой штурм для выработки возможных решений и определить лучшие из них. В итоге мы разработали новую версию процедуры регистрации, которая, по нашему мнению, стала более простой, и включили ее в состав обновленных проектных артефактов.
Нас порадовал тот факт, что у пользователей не возникло никаких проблем с пониманием нашего нового слогана, как это было во время первого раунда тестирования. Всегда приятно видеть, как проблема, имевшая высокий процент нареканий, обнуляется уже в следующем раунде тестирования после внесенных исправлений. Обычно это означает, что решение оказалось настолько удачным, что можно спокойно переключиться на другие задачи.
Случается, что после устранения одних ошибок, в обновленной версии MVP обнаруживаются новые. Показательный пример: участники второго раунда тестирования были довольны тем, что у нашего MVP появилась функция Y, но 80 % из них указали, что эту функцию сложно использовать. После подробного обсуждения проблемы юзабилити, с которой, по нашим наблюдениям, столкнулись пользователи, мы разработали ряд улучшений для этой функции и соответствующим образом обновили проектные артефакты.
Для нас стал сюрпризом тот факт, что 80 % участников тестирования выразили желание, чтобы функция Y работала совместно с функцией X, тогда как мы считали, что она должна быть автономной. Тщательный анализ показал, что представление пользователей о том, как должны работать эти две функции, имеет глубокий смысл и делает их более полезными. В итоге мы переработали обе функции и обновили проектные артефакты.
При правильном подходе каждое повторение цикла должно приводить к уменьшению масштаба и количества проблем. В данном случае между первым и вторым раундами тестирования мы успешно решили три проблемы: отсутствия функции Y, плохо видимой ссылки «Зарегистрироваться» и неудачного слогана. Мы попытались, но пока безуспешно, решить проблему с процедурой регистрации. И наконец, мы обнаружили две новые проблемы: функция Y сложна в использовании, и она должна работать совместно с функцией X.
Помимо этого, повторение цикла должно приводить к улучшению общих рейтинговых оценок. В данном случае мы видим, что рейтинг ценности продукта увеличился с 7 до 8 – скорее всего, благодаря добавлению функции Y. А оценка простоты использования повысилась с 5 до 6 баллов, вероятно, в результате переноса ссылки «Зарегистрироваться» и частичного улучшения процесса регистрации.
Раунд третий
После обновления проектных артефактов на основе информации, полученной по результатам второго раунда тестирования, мы готовы к проведению третьего раунда. По его окончании мы получили данные, приведенные в столбце «Раунд 3» в Таблице 10.1. Как видите, в этот раз пользователи уже не жаловались на то, что функции X и Y не работают совместно, поэтому нашу цель на этом направлении можно считать достигнутой. Все участники тестирования справились с процедурой регистрации. Таким образом, пусть и со второй попытки, но нам удалось решить и эту проблему. Несмотря на переработку функции Y, 40 % пользователей по-прежнему считают ее сложной в использовании. Конечно, это меньше, чем предыдущие 80 %, но нам все еще предстоит поработать над этой важной функцией.
В результате всех проделанных усовершенствований продукта рейтинг его полезности повысился до 9, а рейтинг простоты использования – до 7 баллов. Из этого следует, что мы добились значительного прогресса с момента создания своего первого MVP. Мы больше не получаем серьезной критики в отношении недостающего функционала. Наши месседжи стали гораздо более доходчивыми. В основном отзывы пользователей теперь говорят о необходимости улучшения UX-дизайна, как это обычно и происходит на ранних этапах разработки продукта.
Я упростил данный пример, включив в него лишь небольшое количество основных элементов обратной связи. На самом деле при проведении тестирования на пользователях мы получаем большое количество незначительных замечаний. Конечно, мы можем и должны внедрять улучшения, направленные на решение и таких проблем. С каждым прохождением цикла «Гипотеза – Проектирование – Тестирование – Обучение» степень соответствия нашего продукта рынку должна повышаться.
Раунд четвертый
На данном этапе мы продолжаем улучшать функцию Y, чтобы упростить ее использование, после чего проводим четвертый раунд тестирования. В столбце «Раунд 4» Таблицы 10.1 можно увидеть, что на этот раз никто из участников не пожаловался на то, что функцию Y трудно использовать. Кроме того, не было обнаружено никаких новых серьезных проблем. Рейтинг ценности продукта остался на том же высоком уровне, а рейтинг простоты использования повысился до 9 баллов.
Все это говорит о том, что уровень проработки нашего MVP является достаточно хорошим для перехода к следующему шагу процесса разработки продукта. Если в ходе тестирования использовались высокоточные артефакты (например, интерактивные макеты, созданные в InVision), мы бы приступили теперь к непосредственному созданию продукта. Если же тестирование проводилось на низкоточных артефактах (например, на интерактивных вайрфреймах), то следующим шагом стал бы переход к интерактивным макетам. В некоторых случаях, при наличии уверенности в высоком качестве визуального дизайна и отсутствии рисков пропустить какие-либо недочеты, этап высокоточного проектирования может быть опущен. Это возможно, например, в том случае, когда вы добавляете новый функционал в существующий продукт, и у нас уже имеется протестированный и легко применимый визуальный дизайн.
Не существует какого-либо жесткого правила, указывающего, в какой именно момент ваш проект можно будет считать «достаточно протестированным». Безусловно, существует риск продолжения тестирования уже после того, как оно потеряет свою ценность. И наоборот, вы можете запустить кодирование продукта, не доведя его предварительную проверку до нужной степени готовности, что в дальнейшем может привести к необходимости болезненных переделок на уровне проектирования и кодирования. Таким образом, речь идет о необходимости нахождения правильного баланса. Так или иначе, в определенный момент ваш «птенец» должен будет покинуть гнездо; то есть нужно будет прекратить тестирование артефактов проектирования и создать непосредственно MVP. Это захватывающий переход. Он в значительной степени приближает вас к созданию реальной потребительской ценности в виде живого продукта, а также позволяет выйти на следующий уровень тестирования.
Тестирование с использованием артефактов проектирования полезно для проверки гипотез и обеспечения соответствия продукта требованиям рынка. Тестирование с использованием живого продукта является еще более полезным. Когда вы тестируете артефакты, пользователи рассказывают вам, что бы они сделали, если бы имели дело с рабочим продуктом. Но то, что пользователи говорят о своих возможных действиях, может существенно отличаться от того, что они действительно будут делать. Кроме того, живой продукт отличается своей максимально возможной достоверностью. В низкоточных артефактах могут отсутствовать некоторые детали, которые имеются в реальном продукте. Помимо этого, в процессе программного кодирования могут быть допущены некоторые отклонения от проектных артефактов.
После создания реального продукта весьма полезно провести еще один раунд тестирования, чтобы понять, где вы находитесь на этот момент. Результатом должно стать подтверждение или повышение степени соответствия продукта рынку по сравнению с оценками, полученными на последнем этапе тестирования с использованием проектных артефактов. Если этого не происходит, необходимо будет повторять цикл «Гипотеза – Проектирование – Тестирование – Обучение» уже с живым продуктом до достижения требуемых результатов. Многие компании используют на этом этапе закрытое бета-тестирование, когда с продуктом может ознакомиться лишь ограниченное число клиентов. Это происходит до тех пор, пока ваше детище не будет полностью готово к выходу в свет.
Идти напролом или свернуть?
Необходимо отметить, что выше я «нарисовал» довольно радужную картину. Да, там было сказано, что придется проделать большой объем кропотливой работы, пройти через несколько этапов итераций. Но в конце этого пути вас неизбежно будет ожидать главный приз – соответствие продукта рынку. К сожалению, многие команды разработчиков имеют совсем иной опыт. При проведении тестирования своего продукта на пользователях они не получают восторженных отзывов. Они проводят итерации, но не добиваются прогресса. В результате возникает тупиковая ситуация: разработчики чувствуют, что уперлись в глухую стену.
На пути, который я описал, что-то может пойти совсем не так, как ожидалось. Одна или несколько ваших гипотез могут оказаться неверными. Или, даже если гипотезы верны, результаты проектирования, создания или маркетинга продукта могут оказаться недостаточно хорошими. Если вы обнаруживаете, что проводимые итерации не приводят к видимому прогрессу, я рекомендую сделать паузу и отступить на шаг назад. Проведите со своей командой мозговой штурм, чтобы понять, что лежит в основе возникших проблем. Сопоставьте каждую проблему с конкретным слоем пирамиды соответствия продукта рынку, представленной на Рисунке 10.2. В результате вы можете обнаружить, что выполняете итерации на более высоком уровне, чем тот, где находится истинная причина проблем. Например, если ваша гипотеза о целевом клиенте неверна, итеративное совершенствование UX-дизайна продукта не будет иметь большого значения. Необходимо начать с самого основания пирамиды и продвигаться вверх до тех пор, пока не определите, какие из выдвинутых гипотез оказались неверны.
Когда вы забраковываете одну из своих основных гипотез, вы тем самым совершаете разворот. Его последствия оказываются значительно более существенными, чем те изменения, которые вы наблюдаете при совершении плановых итераций. Разворот означает смену направления дальнейшей разработки. Например, переориентация на другой тип целевого клиента является поворотным моментом. Решение сменить дифференциаторы ценностного предложения также можно рассматривать как поворотный момент в создании продукта. В то же время внесение изменений в UX-дизайн не меняет направление разработки столь кардинальным образом.
Существует множество примеров успешных разворотов в создании продукта. Сайт для обмена фотографиями Flickr начинался как многопользовательская ролевая онлайн-игра «Game Neverending», ориентированная на социальное взаимодействие. После того как компания-разработчик добавила инструмент, позволяющий легко обмениваться фотографиями на веб-страницах, стало ясно, что пользователям он очень понравился. Компания развернулась навстречу пожеланиям клиентов и в феврале 2004 года запустила фото-приложение Flickr, которое быстро обрело популярность и было выкуплено компанией Yahoo! в марте 2005 года.
Популярное приложение для обмена фотографиями Instagram изначально именовалось Burbn и представляло собой социальный проект, написанный на HTML 5, в котором сочетались элементы игр Foursquare и Mafia Wars. После выхода Burbn в качестве нативного приложения для iPhone разработчики посчитали, что его функционал слишком перегружен. В итоге они решили создать новое приложение с нуля, убрав из него все, кроме таких функций, как «фото», «комментарий» и «лайк». Так, в октябре 2010 года появился Instagram, который, пережив взрывной рост, в апреле 2012 года был приобретен Facebook примерно за 1 млрд $.
Одной из самых сложных составляющих процесса создания бережливого продукта является необходимость принятия решения о том, следует ли продолжать использовать изначально выбранную рыночную возможность или взяться за новую, или вообще остановиться. Давайте сначала разберемся с последним вариантом. Вы не располагаете безграничным количеством времени, его лимит, как правило, определяется ограниченностью предоставленных вам ресурсов. В условиях стартапа вам приходится полагаться на внешнее финансирование от инвесторов, по крайней мере, до тех пор, пока вы не сумеете выйти в прибыль. Если вы не достигнете соответствия продукта рынку или не добьетесь значительного прогресса в достижении этой цели, возможность привлечения новых инвестиций может оказаться под угрозой. Даже успешные компании при разработке новых продуктов вынуждены учитывать имеющиеся бюджетные ограничения, а также жесткие временные рамки, установленные для достижения прогресса.
Я знаю несколько стартапов, которые, похоже, постоянно меняют направление своего движения. На самом деле вы не должны сворачивать с намеченного пути каждый раз, когда попадаете в трудную ситуацию, бросаться в погоню за каждой пришедшей вам в голову новой крутой идеей. Такое поведение известно как синдром блестящего предмета. Я часто повторяю шутку о том, что, если вы свернули трижды, значит, вы теперь движетесь в направлении, противоположном изначальному. Однако есть и другая крайность, в которую впадают те, кто упрямо продолжают биться головой о стену, вместо того чтобы, отступив на шаг назад, переосмыслить ситуацию.
Итак, если «дедлайн» еще не наступил, и у вас все еще есть деньги на разработку, как решить, стоит ли продолжать упорствовать или нужно сменить направление движения? Если после нескольких итераций усовершенствования продукта вы все еще не можете добиться прогресса в улучшении его соответствия рынку, следует рассмотреть возможность разворота. Если, несмотря на все затраченные усилия, целевые потребители все также критичны в отношении вашего MVP, опять же, следует подумать о развороте. Другими словами, если вы так и не смогли определить архетип клиента, который был бы в восторге от вашего MVP, следует подумать о развороте.
Иногда выбор нового направления, в котором вам следует продолжить свое движение, подсказывают результаты тестирования. Например, вы можете обнаружить, что та часть ценностного предложения, которую вы считали менее приоритетной, оказывается наиболее востребованной и высоко оцененной со стороны пользователей. В этом случае следует сосредоточить все усилия на достижении прогресса именно в этом направлении. Или же вы можете обнаружить, что целевой рынок состоит из отдельных сегментов и что представителям одного из этих сегментов действительно очень нравится какой-то из элементов вашего ценностного предложения.
На Рисунке 10.3 концепция разворота при продвижении к рыночному соответствию продукта объясняется через аналогию с восхождением в гору. Вы начинаете свой путь с подножия первой горы, которая олицетворяет собой рыночную возможность, выбранную вами на основе имевшихся представлений о целевом рынке и гипотез о ценностном предложении. Чем выше вы поднимаетесь, тем в большей степени ваш продукт соответствует рынку. Первый раунд тестирования обеспечил вас знаниями, которые способствовали улучшению продукта. Результаты второго раунда тестирования показывают, что вы приблизились к вершине горы (соответствию продукта рынку); однако по итогам следующего раунда стало понятно, что продвижение вверх существенно замедлилось. Ваш продукт стал лучше по сравнению с его начальным состоянием, но достичь достаточно высокого уровня его соответствия рынку не удалось. На последующих двух итерациях вы пробуете разные способы улучшения продукта, но, похоже, не можете добиться прогресса.
Рисунок 10.3. Смена направления движения для достижения более высокого соответствия продукта рынку.
В процессе проведения пользовательского тестирования вы обнаруживаете смежную рыночную возможность, представленную на рисунке второй горой. Вершина этой горы находится выше первой, что отражает больший объем потенциальной рыночной стоимости новой идеи. Вы решаете пересмотреть свои гипотезы и сменить направление разработки, чтобы воспользоваться вновь открывшейся рыночной возможностью. Вы повторяете цикл «Гипотеза – Проектирование – Тестирование – Обучение» и обнаруживаете, что способны улучшить соответствие вашего продукта рынку, достигнув при этом гораздо больших высот.
Эта аналогия служит напоминанием о том, что при совершении итераций необходимо отслеживать, насколько высоко вам удается подняться в гору (повысить степень соответствия продукта рынку). Старайтесь измерять скорость своего продвижения (улучшения рыночного соответствия продукта) после каждого раунда пользовательского тестирования. Если вам не удается добиться значительного прогресса, попробуйте найти другие пути, ведущие к вершине (пересмотрите свои гипотезы). Если после этого вы все еще не можете достичь заметного прогресса, остановитесь, чтобы по-новому взглянуть на ту «гору», на которой вы находитесь в данный момент (подвергните ревизии свои гипотезы о целевом клиенте и ценностном предложении), и оглянитесь вокруг в поисках других «вершин» (рыночных возможностей), до которых, возможно, вам будет легче добраться. Выберите себе новую цель (смените направление разработки) и попытайтесь ее покорить (совершайте итерации до достижения соответствия продукта рынку).
Прежде чем завершить вторую часть книги, я хочу познакомить вас с деталями практического применения процессов бережливого производства. В том случае, о котором пойдет речь, я совершил разворот – перешел с одной горы на другую после первого же раунда пользовательского тестирования. В следующей главе я расскажу вам о том, как и почему было принято решение, которое привело в конечном итоге к достижению гораздо более полного соответствия продукта рынку.