Дэн Олсен – MVP. Как выводить на рынок товары и услуги, которые нравятся покупателям (страница 50)

Восхождение на вершину соответствия продукта рынку

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

Тем не менее, эти макеты все еще нельзя было считать «финальными». У нас возникло еще более глубокое понимание того, что хотели бы получить пользователи от сервиса блокировки нежелательной почты. Например, мы узнали, что блокировка на уровне категорий рассылки не подходит для случаев, связанных с кредитными картами и каталогами. В отношении этих предложений пользователи хотели бы иметь возможность указывать свои предпочтения на уровне конкретных компаний (например, получать предложения от Chase или Wells Fargo по кредитным картам, каталоги от Nordstrom и L.L. Bean). Мы также получили обратную связь по поводу наших сообщений и пользовательского интерфейса, которая могла помочь в дальнейшем совершенствовании продукта.

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

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

Выводы

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

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

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

Часть III

Создание и оптимизация продукта

Глава 12

Создание продукта с помощью методов Agile-разработки

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

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

Agile-разработка

До этого момента мы успешно применяли итеративный подход, поэтому вполне логично будет использовать его и при непосредственном создании продукта. «Agile-разработка» – это термин, используемый для описания различных итеративных и поэтапных методов создания продукта. До внедрения Agile-разработки большинство программных продуктов создавались с использованием «водопадного» подхода, суть которого состоит в последовательном выполнении ряда шагов. При нем команда разработчиков сначала определяет все требования технического задания, и лишь затем приступает к разработке продукта. Далее проводится внедрение и тестирование, чтобы убедиться, что все работает так, как было задумано. Ключевой особенностью «водопадного» подхода является то, что разработчики не переходят к следующему шагу до тех пор, пока предыдущий этап не будет завершен на 100 %. Другими словами, никакого проектирования не происходит до тех пор, пока не будут определены все требования, и никакой программный код не пишется до тех пор, пока не будет спроектирован весь продукт. Такой подход также называют BDUF (Big Design Up Front)[22].

В свою очередь, разработчики, практикующие Agile-подход (сам термин Agile означает «гибкий», – прим. пер.), разбивают проект на более мелкие составляющие, для реализации которых требуются короткие циклы определения требований, проектирования и кодирования. У Agile-разработки имеется несколько преимуществ. Во-первых, тактика продвижения мелкими шагами позволяет быстрее реагировать на рыночные и прочие внешние изменения. Во-вторых, в процессе разработки продукт быстрее выносится на суд пользователей, что означает более раннее получение обратной связи, которая помогает концентрировать последующие усилия в правильном направлении. В-третьих, разработчикам проще выявлять и ликвидировать ошибки за счет одновременного выполнения меньшего объема работ.