Шесть диаграмм в управлении продуктом

27 Авг 2020

Перевод оригинальной статьи

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

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

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

• КПП менеджера по продуктам
• Пропускная способность поставки
• Водопад против Agile
• Зависимость риска, уровня инициативы и вовлечения руководства
• Диаграмма осведомленности
• Уровень сегментации

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

КПП менеджера по продуктам

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

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

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

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

Для сравнения, в примере справа веб-инженер непосредственно обращается к аналитику, который объясняет ситуации. Затем они согласуются с разработчиком iOS. Обратите внимание, сколько взаимодействий (красных стрелок) должно произойти.

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

Как это использовать: если вы постоянно перегружены, подумайте о том, как ваша команда взаимодействует друг с другом — нужно ли вам присутствовать на каждой встрече? Работает ли ваша команда так же, когда вы находитесь в отпуске, или все останавливается? Если у вас последний вариант, вам нужно сделать сознательное усилие, чтобы облегчить взаимодействие без вас.

Пропускная способность поставки

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

Проблема обычно вызвана работой на больших кусках работы (воронка слева). В результате команда может работать только над одной темой одновременно. Этот подход может быть приемлемым, если мы 100% уверены, что надо сделать именно так, но это бывает очень редко. Если что-то выпало из нашей воронки и это не работает, то вы потратили больше усилий, чем требовалось, чтобы добраться до осознания ошибки в продукте.

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

Как это использовать: оглянитесь назад на то, над чем вы работали в течение последних нескольких месяцев (а не только на то, что вы выпустили). Были ли все эти темы масштабными и сложными или же они представляли собой смесь текущих работ? Все они могут быть в одной теме или разными. Назначьте базовый размер каждой части работы (S, M, L) и подумайте о том, как будет выглядеть ваша воронка.

Водопад против Agile

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

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

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

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

Зависимость риска, уровня инициативы и вовлечения руководства

В этой диаграмме есть два аспекта. Слева — сама пирамида инициативы. Ширина пирамиды показывает сколько инициатив должно быть реализовано одновременно. Широкая основа означает много тем, а узкая-мало. Чтобы сделать это жизнеспособным, темы с более высоким риском находятся вверху (немногие), а темы с более низким риском — внизу (многие).

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

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

Как это использовать: я обнаружил, что это отличный инструмент для взаимодействия как с руководством, так и с командами. Это объясняет, почему начальство обязательно должно быть вовлечено в одни темы и не должно быть вовлечено в другие.

Диаграмма осведомленности

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

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

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

Уровень сегментации

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

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

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

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

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