Скотт Хёрф - Как создать продукт, который полюбят

Не забывайте о «матрице боли» (рис. 3.2). Что вы записали в правый верхний квадрат, где болит сильно и часто? Как вы создадите продукт мечты для заказчиков? Какие из их проблем способны решить только вы?

Рис. 3.2. Матрица боли – простой инструмент, который я создал для себя, чтобы значительно облегчить процесс анализа результатов исследования и получения выводов

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

Диогенис Брито, занимающий пост продуктового дизайнера в стартапе Slack, напоминает:

«Вам нужно сосредоточиться на том, что 100 процентов ваших заказчиков – люди. Технологии изменяются очень и очень быстро, а мотивы людей остаются такими же. Пирамида потребностей Маслоу никуда не делась. Стройте дизайн вокруг этой концепции: чем ближе вы к базовым потребностям человека, тем больше шансов, что ваш дизайн обретет бессмертие».

Другими словами: держите в уме актуальные, проверяемые, реальные горести и радости, о которых вы узнали в процессе исследования. Не поддавайтесь соблазну уйти в мечты и надежды. Запомните: выпустить минимально жизнеспособный продукт (MVP) на рынок только для того, чтобы что-то проверить, – это пустая трата времени, денег и таланта ваших специалистов.

Вы можете больше.

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

Огромную проблему на совещаниях по продукту представляет «клубная» эйфория, когда сфокусированность уступает место всеобщему хаосу. Как управлять вниманием команды и вести здоровую дискуссию?

Заведите доску для записи идей. Она послужит сразу трем практическим целям.

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

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

• Лучшие идеи остаются, а те, что похуже, сами собой тонут. Это преимущество проистекает из естественной склонности группы забывать, кому принадлежит идея. Поэтому доска очень полезна, особенно если у группы много идей. Главное, не подписывать идеи: так вы не заденете ничьего самолюбия и не запустите механизм неприятия чужой разработки или механизм «придумано не нами». Технику «общего котла» (The Cauldron) использовали в Apple, где на совещании иногда присутствовал и Стив Джобс. Гленн Рейд, бывший директор по разработке приложений для потребителей в Apple, говорил: «Общий котел позволял нам сделать замечательный суп, сварить зелье – и неважно, где была чья идея. Ретроспектива показала, что очень важно было отделить идеи от их авторов. Если идея была хорошей – мы соглашались, если идея была плохой – она оседала на дно котла. Мы не помнили, кто что придумал, – это не имело никакого значения» [74].

Преимущество есть и у техник ограничения времени, как, например, та, которой воспользовались в онлайн-стартапе Medium. Берете группу нужных людей, формулируете проблему, которую необходимо решить, и – «у вас есть две минуты, чтобы записать все идеи, которые придут им в голову [насчет решения этой проблемы], – сказал мне директор по разработке и запуску продуктов Джейсон Стирман. – После этого у вас будет пять минут, чтобы записать идеи на доску и объяснить их. После этого – еще две минуты, чтобы дописать недостающие идеи… конечный результат – вы получаете максимально возможное количество идей. Мы так часто устраиваем мозговой штурм».

Есть еще одна мощная техника, которую используют в Amazon. Она известна как «задом наперед» (working backwards). Сначала владелец продукта должен написать предполагаемый пресс-релиз для будущего продукта, а также собрать придуманные цитаты из отзывов пользователей, часто задаваемые вопросы и рассказы покупателей о том, как они использовали продукт.

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