Пару лет назад я стал следить за тем, что происходит в среде продукт-менеджмента. Преимущественно, конечно, на российском и ближайших рынках. Сейчас я готов сделать вывод, что вся видимая активность: сообщества, конференции, статьи, воркшопы – это шумиха, попытки потешить свое эго и теории ради теории.
Сразу признаюсь, чтобы не выглядеть обличителем, я довольно долго делаю продукты, и я также писал статьи и делал доклады ради тщеславия. Возможно, и эта статья написана с такой же целью.
Продукт-менеджер, продукт оунер, продукт трекер
Если тема для вас не нова, то попробуйте ответить, кто такой хороший продукт-менеджер. Раньше мне казалось, что это тот человек, который делает продукты прибыльными. На самом деле хороший продукт-менеджер просто выпускает продукт в срок с заданным набором функций. С таким подходом сталкиваются те, кто переходит в крупные зарубежные компании. В структурах таких организаций за производство продукта и за бизнес-часть отвечают разные ветки. Иногда это отдельно указывают через название позиций как 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 или планировать роадмап можно получить за пару часов.
У вас противоположное мнение? Отлично! Буду рад дискуссии.
