Как ни странно, до 2011 года, когда идея Эрика Райса о бережливом стартапе[21] (вам стоит прочитать эту книгу) достигла критической массы, предприниматели не считали нужным «часто и на ранней стадии» обращаться к клиентам. Эмпирическая, динамичная и прозрачная природа бережливого стартапа строилась на основе разработанной Стивом Бланком методологии customer development[22] и методологии дизайн-мышления. Конечно, в организациях есть UX-дизайнеры, занимающиеся проектированием «для пользователя» (в отличие от проектирования для технических специалистов), но в концепции бережливого стартапа проверенное исследование пользователей стало вопросом жизни и смерти продукта. Концепция бережливого стартапа сделала исследование пользователей поддающимся количественной оценке.
Так мы приходим к третьему принципу – проверенному исследованию пользователей. «Проверка» (валидация) является особенностью бизнес-методологии бережливого стартапа. Под этим термином понимается процесс подтверждения того, что конкретный потребительский сегмент считает ваш продукт ценным. Без проверки вы просто предполагаете, что клиенты оценят продукт по достоинству. Проверенное исследование пользователей выходит за рамки простых наблюдений и способности поставить себя на место потенциальных пользователей. Этот процесс основан на проверке на реальность, которая заключается в прямой обратной связи, полученной от взаимодействия с пользователями. Он помогает вашей группе определить, что скрывается за образом продукта – мечта или потенциальный кошмар.
Эрик Райс популяризировал термин «минимально жизнеспособный продукт» (MVP). Этот термин просто означает получение информации о том, востребован ли ваш продукт потенциальными клиентами, на основе построения только самых важных функций предлагаемой ценности. Этот подход заметно отличается от традиционной разработки проекта, при которой построение прототипа часто превращалось в представление будущего продукта потенциальным инвесторам. Получая одобрение клиентов на ранней стадии коммерческого предложения, вы снижаете риски продукта. А если пользователям не понравится то, что мы им предложим, мы будем должны либо переориентироваться на другой потребительский сегмент, либо обратиться к другой проблеме, которую может решить предлагаемая ценность.
Для применения таких итеративных инструментов, как MVP, ваша команда должна провести исследование и получить подтверждающие данные перед разработкой решения. Желательно убедиться в том, что ваша команда ориентируется на правильную категорию клиентов (то, что не получилось у стартапа из главы 1), а не на некоего обобщенного персонажа. После проверки конкретного проблемного момента вы можете продолжить добавление функций, а затем протестировать эти функции с использованием тех же исследовательских методов. Этот метод известен под названием
