Если вы не опросите исполнителей работы, ваше сравнение окажется чисто умозрительным. Тем не менее вы можете обсудить возможные отличия решений в команде, чтобы выработать внутреннее соглашение. Только обязательно проверьте сделанные предположения, как только представится случай.
Рассмотрите все способы, которыми люди могут выполнять основную работу, связанную с вашим решением. Возьмите небольшую подгруппу потребностей или этапов процесса и разложите их на столе. Выберите два или три решения для сравнения. Обсудите в команде, какие результаты показывает каждое из них относительно других. Затем задайте вопросы: «Где наше решение находится в этом сравнении?», «Что можно улучшить?», «К каким этапам лучше обратиться с точки зрения стратегии?»
• Anthony Ulwick, Jobs to Be Done: Theory to Practice (Idea Bite Press, 2016).
Предложение ценности – явно выраженное обещание, которое организация дает своим клиентам. Шаблон предложения ценности (Value Proposition Canvas, VPC), созданный Александром Остервальдером, предназначен для упрощения обсуждения предложения ценности в команде.
• Составить профиль клиента.
• Обсудить профиль решения.
• Убедиться в связи между клиентом и решением.
• Сформулировать предложение ценности.
В интернете легко найти множество примеров применения VPC. Но многие ресурсы используют неточный язык при формулировке работ и смешивают пространство проблемы и пространство решения. Хотя VPC может стать неформальным инструментом для создания связей внутри компании, хотелось бы порекомендовать в начале исследования соблюдать точность при работе с информацией, особенно с ключевыми работами, которые надо сделать.
Загрузите образец VPC из интернета и потренируйтесь заполнять его самостоятельно, использовав любую тему, взятую из вашего бизнеса или деятельности какой-либо другой компании. Посмотрите, получается ли у вас совместить успехи и проблемы с создателями преимуществ и «обезболивающими».
• Alexander Osterwalder, Yves Pigneur, Gregory Bernarda, and Alan Smith, Value Proposition Design (Hoboken: Wiley, 2014).
Используйте JTBD, чтобы направить задачи в дорожной карте продукта и удостовериться – ваша деятельность связана с потребностями клиента. Дорожная карта не должна спускаться с высокого уровня абстракции с неопределенными датами выполнения каждого этапа, чтобы давать направление работы, не касаясь конкретных дат.
• Определить путь развития решения.
• Определить потребности клиента.
• Установить сроки и последовательности.
• Объединить усилия по разработке и дорожную карту.
Дорожные карты часто путают с подробными планами проектов, где определены сроки выполнения работ. Вместо этого считайте дорожную карту наброском, фиксирующим последовательность действий. Также не забывайте, что дорожные карты меняются. Вы захотите обновлять их примерно раз в квартал.
Сделайте черновик дорожной карты разработки вашего решения в следующем квартале. Посмотрите, сколько вы успеете за час или два. Используйте систему JTBD, чтобы связать темы дорожной карты с последовательностью действий.
• C. Todd Lombardo, Bruce McCarthy, Evan Ryan, and Michael Connors, Product Roadmaps Relaunched (Sebastopol, CA: O’Reilly, 2017).