Фото автора Polina Zimmerman: Pexels

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

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

Продукт-менеджер, продукт оунер, продукт трекер


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

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

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

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

Теория ради теории


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

Самая большая группа у последователей юнит-экономики. По определению, которое часто используется это «метод экономического моделирования, который помогает определить прибыльность бизнеса через расчет прибыльности бизнес-юнита (единицы товара или одного клиента). Эффективен для digital-проектов.». Ответа на вопрос, почему вообще этот термин выделен из обычных методов расчёта экономики предприятия нет. До появления цифровых продуктов бизнес и государство также вели оценки, базируясь на определенных единицах, но в отдельную теорию этого никто не выводил. Например, в США одной из моделью является расчет дохода домовладений.

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

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

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

Моя любимая тема CJM – customer journey map. Если вы не знакомы с этим термином, то вкратце это о том, где пользователь спотыкается, когда пытается купить продукт, перейти на новую версию или выполнить любой сценарий взаимодействия с вами.

Перенесемся в эру динозавров: в эпоху до персональных компьютеров. Люди и раньше покупали товары, заказывали услуги, ходили к врачу. Конечно, и тогда все не пускалось на самотек. Анализ процессов (workflow management, а потом и process mining) существовал задолго до CJM.

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

Конференции, митапы, воркшопы


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

Встречаются доклады таких типов.

«Мы применили подход N и уменьшили отток клиентов на K%». Все бизнесы уникальны, даже в рамках одного рынка. У вас сработало – хорошо. Но один пример ни о чем не говорит.

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

«Выстраивание отношений с командой разработчиков, сейлов, маркетологов, администраторов и т.д.». Работа в коллективе это базовый навык современной работы т. н. knowledge-worker (у нас это офисный сотрудник). Продукт-менеджер ставит задачи, описывает продукт, контролирует ключевые точки и даты. Чем более четко и прогнозируемо работает продукт-менеджер, тем более счастлива его команда.

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

Давайте будем проще. Если вы опытный продукт-менеджер вы все делаете хорошо. Развивайтесь в предметной области.

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

У вас противоположное мнение? Отлично! Буду рад дискуссии.

Комментарии (11)


  1. Amokmorg
    24.02.2022 13:35

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

    вы путаете со scrum master'ом


    1. MikhailZakharov Автор
      24.02.2022 13:54

      Не соглашусь, хоть и понимаю, почему product manager и product owner путают. Product owner существует только в методологии Scrum. Эта роль отвечает только за конкретный бэклог определенного продукта. Задача product owner в коммуникации со scum командой: объяснение приоритетов, приоритезация бэклога, видение продукта. На Хабре есть статья Product Owner vs Product Manager или Product Owner/Product Manager / Хабр (habr.com)


      1. alexhouse
        24.02.2022 14:57
        +1

        Вопрос, вероятно, к формулировке "роль в Scrum, которую может выполнять любой член команды". Так как роль product owner выделенная и не может быть делегирована любому члены команды. Иначе, по классике, у вас уже не скрам, а совсем что-то другое :)


        1. MikhailZakharov Автор
          24.02.2022 14:59

          Спасибо! Теперь понятно, где я был неточен.


  1. Hydrobelka
    24.02.2022 21:22
    +1

    Еще есть ощущение, что у Product Manager в текущей интерпретации нет фокуса на качественную проработку требований. Нарисовал cjm, согласовал дизайн, описал user story (в лучшем случае) и понеслась.

    А как с этими артефактами потом разработчику работать, что конкретно надо делать, на сколько решение оптимально, как уменьшить ресурсы, как декомпозировать? Пусть тимлид придумает.


    1. MikhailZakharov Автор
      24.02.2022 22:48
      +1

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

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


  1. Lelant0s
    25.02.2022 01:46
    +1

    Как руководитель product-функции (чтобы не спорить о названиях) согласен, что многое новое это хорошо забытое старое, при этом извращенно-упрощенное. Юнит-экономика - отличный тому пример. Но создается ощущение, что автор понадергал самых что ни на есть worst practices и выдает их за текущее состояние дел.

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

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

    Качество формируется запросом. Нет второго - не будет и первого.


    1. MikhailZakharov Автор
      25.02.2022 10:23

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

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


      1. Lelant0s
        25.02.2022 10:39
        +1

        Понимаю.

        К сожалению, большинство (99%) продакт-менеджеров на постсоветском пространстве это "менеджеры по запилу фич". Я понимаю, что этот посыл идёт от руководства, имеющего технический бэкграунд (условный основатель/CEO, который всю жизнь был разработчиком), но это *в корне* неправильно. Продакт - это маркетинговая функция, а не техническая.

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


  1. SergeyMats
    25.02.2022 09:37
    +1

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


    1. MikhailZakharov Автор
      25.02.2022 10:26

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