6 принципов продакт-менеджмента в картинках

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

text

Мы основывались на статье, которую написал продакт-менеджер из Берлина Кёртис Штаньер (Curtis Stanier). Автор разрешил использовать его диаграммы, что мы с удовольствием и сделали.

Waterfall или Agile

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

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

Красная стрелка на графике — это усилия команды, те самые инвестиции. Их объём накапливается по ходу работы, поэтому кривая плавно идёт вверх. Желтая стрелка — ценность продукта.

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

На графике справа — agile-подход, когда большой проект раздроблен на мелкие итерации, каждая из которых релизится отдельно. Сначала готовим MVP: можно отправлять и получать текстовые сообщения. It’s alive! Продукт уже рабочий, его уже можно релизить и получать обратную связь от первых пользователей — сгенерированная ценность очевидна. Затем по кусочку ценность наращиваем: допиливаем дизайн, налаживаем голосовые сообщения, добавляем функцию обмена файлами, прикручиваем звонки, стикеры и так далее, пока не похороним Telegram.

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

Воронка задач

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

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

Команда может трудиться одновременно над несколькими разными задачами. Интервалы между релизами очень короткие, оценки работы проводятся чаще. Не получилось решить какую-то микрозадачу — не беда. Ресурсов было потрачено минимум, можно безболезненно сделать ещё итерацию, учитывая прошлые ошибки. Выводы, которые мы сделаем, могут стать стимулом для корректировки более крупных задач, что повысит шансы на успех и снизит объём усилий для их выполнения. Риска меньше, ROI больше.

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

Ограниченные знания

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

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

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

ПМ — тормоз

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

Допустим, у веб-разработчика появились вопросы по поводу отслеживания пользовательской активности. Он подходит с ними к продакт-менеджеру. Тот идёт к аналитику. Аналитик говорит, делайте всё, как у нас в приложении для iOS. ПМ идёт к яблокодеру, узнаёт все детали и передаёт их веб-разработчику. Эта ситуация изображена на диаграмме слева.

Не будет ли проще, если веб-разработчик сам обкашляет вопросики с аналитиком и потом метнётся кабанчиком к iOS-разработчику уточнять детали? Смотри диаграмму справа.

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

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

Вовлечённость руководства

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

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

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

Например, вы разрабатываете сайт, и нужно загрузить тестовые картинки, чтобы посмотреть, как они отображаются. Вам не нужен для этого CEO. Даже продакт-менеджера по этому поводу дёргать не стоит. А вот если нужно перейти на новую дизайн-систему, вам уже потребуется «добро» от топа.

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

Ценность сегментации

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

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

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

Копаем глубже первый эксперимент. Да, в целом, у нас рост, но по сегменту B почему-то резкое падение. Там кроется какая-то проблема. Второй эксперимент показал отрицательный результат, но раскрыл возможности для работы по этой модели с сегментом C. А в третьем эксперименте «тишь да гладь» оказалась иллюзорной, ведь реакция в каждом сегменте была значительной, просто разные результаты друг друга нивелировали при расчёте среднего значения.

Мудрая картинка учит нас детальнее прорабатывать гипотезы и глубже копаться в аналитике.

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

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