Дерево решений возможностей: визуальный инструмент для обнаружения продуктов

Один из способов запустить эту работу по поиску продукта — использовать мысленную модель под названием «Дерево решений возможностей» (OST). Чтобы помочь продуктовым командам эффективно обнаруживать и извлекать выгоду, мы рассмотрим, что такое дерево решений возможностей, как его использовать, пример OST и как подключить ваш OST к аналитике и экспериментам.

Что такое открытие продукта?

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

Обнаружение продукта включает в себя интервью с клиентами, слежение за клиентами, опросы, отзывы клиентов и тестирование прототипов. Открытие продукта должно происходить регулярно и часто. Другими словами, открытие не должно происходить раз в квартал; скорее, это должно происходить каждый день, в каждом модуле продукта, небольшими последовательными шагами.

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

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

Почему обнаружение продукта может столкнуться с проблемами внедрения?

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

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

В частности, лидеры хотят получить ответы на следующие вопросы:

• Откуда мы знаем, что обнаружение повлияет на важную бизнес-метрику?
• Сколько времени займет эта работа по открытию и сколько она будет стоить?
• Откуда мы знаем, что эти инвестиции окупятся?

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

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

Что такое дерево решений возможностей (OST)?

Структура дерева решений возможностей была первоначально разработана профессором дизайна Стэнфордского университета. В 2016 году Тереза ​​Торрес, основатель Product Talk, применила эту структуру к процессам поиска продуктов.

Каждое дерево решений возможностей содержит четыре ключевых компонента:

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

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

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

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

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

Как дерево решений возможностей улучшает принятие открытий?

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

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

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

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

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

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

Как работают деревья решений возможностей?

Давайте разберем каждый из четырех ключевых компонентов дерева решений возможностей и обсудим передовой опыт для каждого из них.

Метрики

Метрика вашего дерева решений должна быть согласована с KPI (ключевым показателем эффективности) из ваших OKR (целей и ключевых результатов), чтобы ваша работа была напрямую связана с успехом в бизнесе. Эта метрика — это линза, через которую вы будете исследовать свой продукт.

Другими словами, любые разговоры с клиентами или усилия по поиску продукта, которые не могут изменить метрику, не должны учитываться. Активно исследовать следует только те инициативы и усилия, которые имеют реальную возможность изменить метрику.

Но как выбрать хорошую метрику? Хорошие показатели должны уравновешивать противоречие между «успехом в бизнесе» и «близостью к продукту».

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

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

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

Возможности

То, что мы знаем, к какой метрике мы стремимся,неозначает, что мы знаем, с какими трудностями сталкиваются наши клиенты. Часто команды, ориентированные на водопад, выдвигают идеи «внутри четырех стен компании», не узнавая от клиентов, в чем их проблемы.

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

Продуктовые команды могут использовать любой из перечисленных ниже способов для выявления возможностей:

• Входящие отзывы клиентов
• Исходящие интервью 1:1
• Исходящие опросы
• Аналитика данных о продуктах
• Обсуждения с внутренними заинтересованными сторонами (например, поддержка, маркетинг, продажи)

Чтобы сделать эту концепцию более конкретной, давайте рассмотрим Gmail, почтовый ящик электронной почты, предоставляемый Google.

Возможность — этоне«Я хочу лучший спам-фильтр». Это идея решения, и мы попались в ловушку, прислушиваясь к тому, что строить, а не к тому, какие проблемы решать.

Когда мы рассматриваем идею функции «Я хочу лучший спам-фильтр», это может на самом деле указывать на множество различных основных проблем пользователей, таких как:

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

Как вы можете себе представить, набор возможных решений для возможности «быстрее найти электронное письмо» по сравнению с набором возможных решений для возможности «предотвратить прерывание меня электронными письмами» сильно отличаются друг от друга. Хотя верно то, что они разделяют одну и ту же идею «Я хочу лучший спам-фильтр», это не означает, что спам-фильтр — лучший способ достичь любой цели.

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

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

Идеи решения

После того, как вы выбрали возможность, сотрудничайте с дизайнерами и инженерами, чтобы определить различные возможные способы решения проблемы клиента:

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

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

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

Например, скажите, что вы отвечаете за платформу управления проектами, такую ​​как Asana или Trello. Некоторые пользователи хотят знать, какие задачи рискуют не уложиться в срок. Некоторые пользователи хотят знать, не перегружены ли некоторые сотрудники работой. Некоторые пользователи хотят понять, какие отделы сделали больше всего запросов о задачах. А некоторые пользователи хотят знать, какие группы выполнили больше всего задач.

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

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

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

Тесты и эксперименты

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

Например, скажем, вы отвечаете за контрактную программную платформу, такую ​​как Ironclad, и хотели бы предоставить функциональность, которая автоматически подключается к соответствующим условиям контракта на основе AI/ML. Вместо того, чтобы строить всю систему рекомендаций за один раз, вы захотите снизить риск этой инициативы, разбив ее на более мелкие части.

Одним из предположений может быть: «Мы считаем, что юристы хотят рассмотреть предложение, прежде чем включать его в контракт». Если это так, то предоставляемый нами пользовательский интерфейс должен позволять юристам видеть предлагаемый пункт контракта и давать им возможность принять или отклонить его.

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

Как бы мы это проверили? Мы могли бы провести тест «человек в машине» с юристом, чтобы увидеть, устраивает ли их включение пунктов контракта без их просмотра.

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

Для каждого эксперимента нам нужно убедиться, что мы сделали следующее:

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

Как мы расставляем приоритеты для различных экспериментов, которые мы хотим провести в соответствии с нашими идеями решения? Как правило, мы хотим расставить приоритеты с учетом следующих трех факторов:

1. Какие эксперименты больше всего изменят общую метрику OST?
2. Какие эксперименты позволят снизить риск самых больших предположений?
3. Какие эксперименты будут стоить нам меньше всего времени и усилий?

Когда использовать дерево решений возможностей

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

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

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

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

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

Реальный пример дерева решений возможностей

Чтобы воплотить эту концепцию в жизнь, давайте рассмотрим реальный пример дерева решений возможностей на практике. Допустим, вы отвечаете за расширение возможностей поиска в своем продукте B2B, который представляет собой конструктор веб-сайтов (например, Squarespace, WordPress, Wix и т. д.).

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

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

1. Результаты поиска в вашей функции в настоящее время довольно сложно просеять.
2. Пользователям приходится долго ждать результатов поиска, что расстраивает.
3. Многие пользователи добавляют в свои запросы «местные» ключевые слова на основе местоположения (например, «Нью-Йорк» или «Сан-Диего»), что является повторяющимся и утомительным, но необходимым для получения точных результатов.

Мы могли бы придумать дерево решений возможностей, как показано ниже:

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

И для любой данной идеи вы не просто отправляете эту идею от начала до конца — вы создаете проверяемые гипотезы и эксперименты, чтобы определить, какие аспекты идеи наиболее ценны.

Например, возможно, вы хотите, чтобы пользователям было проще просеивать результаты поиска, и одна идея, которая кажется убедительной, — показывать пользователям предварительный просмотр результатов.

Однако «предварительный просмотр результатов» довольно широк; что именно делает предварительный просмотр привлекательным?

Допустим, мы хотим проверить предположение о том, что «каждый результат должен быть проверен пользователями». В этом случае мы бы развернули эксперимент, в котором каждый возвращенный результат имеет свой собственный текстовый предварительный просмотр, связанный с ним.

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

И откуда мы знаем, что текст действительно лучший путь вперед? Что, если наших пользователей особенно интересуют изображения, похожие на Pinterest или Instagram? В этом случае вместо отображения текстовых ссылок мы должны провести эксперимент, в котором вместо этого мы будем отображать снимки на основе изображений для наших результатов поиска.

Взаимодействие между OST и продуктовой стратегией

Деревья решений взаимодействуют со стратегией продукта двумя ключевыми способами.

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

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

Как правило, улучшайте свою продуктовую стратегию после каждых трех экспериментов. Задавайте эти вопросы регулярно по мере завершения каждого эксперимента:

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

Согласование и сотрудничество с заинтересованными сторонами через OST

Люди принимают решения, исходя из того контекста, который у них есть, и разумные люди принимают такие же решения, если у них такой же контекст.

Если вы столкнулись с разногласиями, происходит одно (или оба) из них:

• Несогласный человек не имеет вашего контекста
• У вас нет контекста, который есть у несогласного человека

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

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

Ниже мы рассмотрим:

1. Как создать свой первый OST
2. Как усовершенствовать существующий OST
3. Как перейти к новому OST

Создание вашего первого OST

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

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

1. Согласование метрик : согласуйте ключевые бизнес-метрики и обсудите, как обнаружение приведет к лучшим результатам, чем водопад в долгосрочной перспективе.
2. Исследование возможностей : просмотрите первоначальный набор областей возможностей на основе отзывов клиентов и пригласите заинтересованных лиц также поделиться своими возможностями.
3. Выбор возможности : совместно выберите возможность для начала (а не то, какая из них «правильная» или «неправильная») и вместе задокументируйте процесс принятия решений.
4. Идея решения : совместно придумайте множество решений и согласуйте, какое начальное решение исследовать с помощью экспериментов.

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

Кроме того, вам может потребоваться более четырех встреч, чтобы привлечь заинтересованных лиц к себе в путь. Тем не менее, мы не рекомендуем втискивать несколько тем в одну и ту же встречу, так как это может вызвать усталость, потерю внимания и разочарование заинтересованных сторон.

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

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

Созревание существующего OST

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

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

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

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

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

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

Как только вы завоюете доверие своих заинтересованных сторон посредством этих встреч, вы можете отправлять обновления асинхронно, чтобы сэкономить время и усилия. Тем не менее, не забудьте установить четкие ожидания, что заинтересованные стороны могут и должны связаться с вами, если у них есть вопросы, проблемы, предложения или новые идеи для добавления в OST.

Переход на новый OST

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

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

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

Как только у вас появится область возможностей, на которой можно сосредоточиться, вы сможете работать с решениями и экспериментами без дополнительных входных данных (при условии, что вы со временем заслужили достаточно доверия с заинтересованными сторонами и что вы отвечаете на их вопросы по мере их поступления). вверх).

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

Подключение OST к аналитике

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

В качестве примера того, как вы воплощаете в жизнь дерево решений возможностей с помощью аналитики, мы обсудим, как это сделать с помощью Amplitude Notebooks.

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

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

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

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

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

Заключительные мысли

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

Мы должны чувствовать себя вправе корректировать процесс и терминологию в соответствии с нашими конкретными контекстами и потребностями, если мы помним об этих трех принципах:

1. Открытие продукта должно служить бизнес-целям.
2. Цель продуктовой команды состоит в том, чтобы итерировать решения, которые устранят проблемы клиентов, а не выпускать функции к какому-то произвольному сроку.
3. Мы, как команда, должны иметь возможность реагировать на информацию и отзывы клиентов в режиме реального времени, а не ждать квартальной или ежегодной каденции.

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