Этот цикл иногда требует нескольких итераций. Данные, полученные по обратной связи от потенциальных клиентов, могут изменить то, как вы преподносите решение или идентифицируете новых персон. Вайнберг уточняет, что смысл этих колебаний туда-сюда состоит в том, чтобы убедиться, что вы решите проблемы и что клиент купит решение. Третий шаг — склонить заинтересованных клиентов к покупке продукта и совершенствовать его. Вайнберг рекомендует делать то, что потенциальный клиент увидит, потрогает и прочувствует: «Создайте параллельно несколько структурных схем страниц (wireframe) и мокапов». В начальной стадии лидер продукта сосредоточен на базовой функциональности, например, как в структурной схеме решается пользовательская история. Артефакт — это не объект; скорее, лидеру нужно обратить внимание на реакцию на предложенное объектом решение. Базовыми мокапами вы проверяете предыдущие предположения. Суть не в превращении тестовой аудитории в гарантированных клиентов, а в проверке твердости их намерений. Цикл «интервью — создание — проверка» можно повторять несколько раз, пока команда не достигнет комфортного для себя уровня риска. Иными словами, пока им не покажется, что накопилось достаточно данных обратной связи для обсуждения следующей версии прототипа.

Прототипирование — это один из способов обрести внутреннюю определенность и гармонию в процессе тестирования видения. Обязанность лидера продукта — настаивать на создании прототипов в качестве ключевых элементов стратегии тестирования. С внедрением прототипов на рынок и учетом их в работе над продуктом встает вопрос: в какой последовательности проводить качественное пользовательское тестирование и исследования — исследование прежде каких-либо действий или после? «Мы проводим исследования пользователей разными способами, — рассказывает Эмили Равич, старший менеджер дизайна проектов Spotify. — Иногда проводим раннее тестирование видения на высоком уровне, а иногда тестируем его на этапе разработки. Бывает, что проводим исследования, когда оно уже готово. Раннее тестирование видения мы выбираем, если нужно делать все в темпе, как в дизайн-спринтах. Между собой мы называем их дизайн-swats, как будто команда SWAT или группа специалистов решает срочную проблему».

Раннее тестирование концепции в стиле SWAT ускоряет команде Равич поиск решений. «Мы ускоряемся, потому что времени мало», — объясняет она. Полностью ввести в курс всех членов команды при необходимости действовать быстро — настоящее искусство: «Мы не можем далеко отрываться от спринта, и разработчики уже на низком старте. Чаще всего на это уходит четыре-пять дней. Чтобы вы поняли, как выглядит такое гиперскоростное исследование, приведу пример буквально двухнедельной давности. В первый день мы рассмотрели множество решений методом дивергентного мышления. На второй день мы объединились с инженерами и менеджерами продукта, чтобы привести идеи к общему знаменателю и хотя бы приблизительно определить, что мы собираемся узнать. Третий день — завершение прототипа и привлечение реальных пользователей, планировочные сессии и составление опросника. На четвертый день мы проводили опрос пяти-семи пользователей в течение 30 минут, и уже к концу рабочего дня составили и разослали бриф-исследования. Далее мы были готовы продолжать работу с прототипом».

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

Обозначение приоритетов

Сделав необходимую работу (получение данных обратной связи от конечного пользователя и проведение соответствующих исследований), лидеру продукта и команде предстоит обозначить приоритеты. Иначе говоря, определить, какие неудовлетворенные потребности требуют внимания в первую очередь. «На это есть два ответа, — говорит Джош Брюер. — Первый: у любого продукта есть изначальный набор приоритетов. Уже на раннем этапе мы решили, что пара моментов должна присутствовать обязательно. Без них остальное не имеет значения».

Исследование или тестирование изначального соответствия рынку всегда выливается в список ключевых задач. «Второй: если не сделать Х, все связанное с Х в системе не существует. И знаете что? Этот единственный Х несет большой риск». В простой двухшаговой модели Брюер определяет, что требует первоочередного внимания команды.

Это либо ключевой элемент, либо критическая составляющая, без которой не могут существовать другие ключевые элементы. Затем Брюер проходится по списку и выясняет, как команда будет тестировать перечисленное. «Помимо ключевых частей, остальные мы оцениваем баллами в соответствии с использованными исследованиями и методами. И сразу понимаем: “Отлично, у нас в самом верху списка четыре неудовлетворенных потребности”».

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

Иногда приходится смириться с тем, что надо сделать. Вот как этот сценарий описывает Брюер: «Надо — и точка. Приходится с головой погрузиться в работу и выполнить ее. А уже потом решать, как все объединить и как что между собой соотносится». Мы не рекомендуем соглашаться на все требования, но нам импонирует, что в результате обсуждение поворачивает в новое русло. От структуры команды и используемых процессов зависит, как построить разговор. Идеальной схемы обсуждения приоритетов нет, но обязательно надо делать это почаще, и без политики. Рассказывает Роуз Грабовски, бывший директор по управлению продуктом Invaluable: «Это смесь долгосрочного анализа и командной работы над получением обратной связи по инициативам в текущих спринтах, рассмотрения багов и попыток установить связь между выявленными проблемами. Каждый день переключаешься с высокого уровня на мелочи. Уж таковы особенности нашей сферы».

Баланс приоритетов и противоречия

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

Идей, как правило, слишком много. Советуем завести для них резервный список — на вайтборде, стикерах, канале Slack или в инструменте управления идеями. Если каждый уверен, что его идея будет где-то храниться и ее рассмотрят, а не отметут сразу, то тогда обсуждения проходят в разы проще.