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

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

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

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

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

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

Диаграмма 1 – Узкие места в коммуникации

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

Теперь, естественно, вы хотели бы участвовать во всех важных межгрупповых/внутрикомандных обсуждениях, но вам нужно подумать об одном – нужно ли это? Это что-то, что вы должны сделать, отложив в сторону свои другие обязанности?

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

Допустим, веб-инженеру нужно обсудить что-то с аналитиком продукта, а затем PA говорит, что им нужно обсудить что-то с разработчиком iOS по этому поводу. Теперь в идеале веб-инженер должен напрямую обращаться к PA и разработчику iOS, а не зависеть от PM (как показано на изображении слева).

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

Диаграмма 2: Waterfall против Agile

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

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

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

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

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

Диаграмма 3: Представление объема поставки

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

Вот представление размеров инициатив, предпринятых при разработке приложения:

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

{Также прочтите нашу статью « Менеджеры проектов и менеджеры по продуктам: различия, роли и проблемы »}

Диаграмма справа — это классическое «сделать». Преимущества применения Agile-подхода коснулись и этого этапа процесса управления продуктом . Этот подход поддерживает сочетание выполнения небольших задач с большими объемами работы (синий цвет), чему мы также следуем в Appinventiv.

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

{Ознакомьтесь с подробной статьей « 10 самых важных документов, которые должны подготовить менеджеры по продуктам »}

Диаграмма 4: Уровень участия руководства

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

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

По мере продвижения к вершине пирамиды количество задач уменьшается, а риски, связанные с этими задачами, также увеличиваются, здесь ОБЯЗАТЕЛЬНО нужно проконсультироваться с продакт-менеджером, а в сформированной его можно просто проинформировать. Эта диаграмма поможет не только менеджерам по мобильным продуктам, но и членам команды понять, когда следует полагаться на руководство.

Диаграмма 5: Анализ значения сегментации

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

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

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

Приведенная выше диаграмма состоит из трех гипотетических экспериментов 1, 2 и 3 с сегментами A, B, C и D. Из трех экспериментов в первом случае произошел подъем на сегменте A, за которым последовало снижение второй случай и третий без изменений.

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

Аналогичная ситуация возникает в эксперименте 3, где сегменты A, C, D уступают сегменту B, который показал значительные изменения. Опять же, исследование выяснит причины этого.

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

Часто задаваемые вопросы

1. Что такое структура управления продуктом?

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

2. Что такое процесс управления продуктом?

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