Всем привет. Хотел бы в рамках данной статьи рассмотреть такой вопрос, как построение команды продакт-менеджеров и выбор правильной конфигурации навыков у тех специалистов, которых мы бы хотели видеть в своей команде. 

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

Расскажу на своём опыте о том, с какими проблемами я столкнулся при построении продуктовой команды и какие выводы я сделал лично для себя.

Диспозиция была примерно следующая. Год назад я сменил работу и занял позицию Сhief Product Officer в международной компании Beter. Beter — это В2В компания, которая занимается поставкой спортивного контента для букмекерского бизнеса. И сразу встал вопрос построения продуктовой команды и выстраивания процессов, связанных с продуктовым менеджментом в компании. Когда я пришел в компанию, понятие продуктового менеджмента как таковое практически отсутствовало. Было несколько команд разработки, приоритезацией задач для которых и в целом определением того, что делать, занимался СЕО компании напрямую. Поскольку СЕО компании также являлся её основателем и идейным вдохновителем, продукт он знал хорошо. И пока компания представляла из себя стартап на 30-40 человек, данная схема прекрасно работала. Однако бизнес рос, количество клиентов, оборот и количество сотрудников компании росло и в какой-то момент СЕО понял, что управлять продуктом самостоятельно он уже не способен. В этот момент он нашёл меня.

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

Итак, я засучил рукава и начал искать людей. После первых же собеседований с потенциальными кандидатами стало ясно, что у нас с СЕО диаметрально противоположные представления о том, кто такой идеальный продукт менеджер и какой конфигурацией навыков он должен обладать. Я всегда считал (и продолжаю считать), что идеальный продакт-менеджер — это человек, способный управлять разработкой продукта, разбираться в технических деталях его работы. Это тот человек, который способен провести разработку по всему циклу SDLC, обеспечивая необходимое сопровождение для технической команды на каждом из этапов этого цикла.

Одним словом, для меня идеальный продакт-менеджер — это человек, для которого техническая команда — это инструмент развития продукта. И он способен качественно управлять этим инструментом, как токарь станком. То есть для меня наличие у продакт-менеджера команды разработки, в рамках которой он может принимать решения, как руководитель — неотъемлемая часть эффективного процесса разработки продукта. Такой продакт-менеджер должен уметь общаться с разработчиками на одном языке. Уметь, как минимум, читать код и быть способным понять, что этот код делает. Знать архитектуру своего продукта до достаточно мелких деталей (на уровне диаграммы объектов). Знать, каким образом его продукт взаимодействует с окружающим миром (посредством каких API протоколов). Для более детального понимания давайте введём такое понятие, как Technical Product Manager для обозначения такого продакт- менеджера. Как правило, это специалисты, перешедшие в продуктовый менеджмент из технических позиций — бывшие разработчики, тестировщики, архитекторы и т.д.

Однако у СЕО был другой взгляд на это. Он считал, что продакт-менеджер должен заниматься исключительно бизнес составляющей продукта: исследовать рынок, конкурентов, анализировать высокоуровнево, что не хватает нашему бизнесу для развития и приносить идеи с прогнозом по прибыльности для команды разработки. А дальше уже сама команда разработки, находящаяся в этом случае в другой организационной и управленческой вертикали, сама разберётся, каким образом это реализовать. Давайте назовём такого специалиста Business Product Manager. 

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

Через шесть месяцев после начала этого эксперимента я могу сделать следующие выводы:

  1. Большая часть бизнес составляющей продуктового менеджмента, которая обычно характеризует эту профессию (юнит-экономика, продуктовые метрики, техники приоритезации, Customer Journey Map, дизайн А-В тестов, проверка гипотез, Customer Research и т.д.) осваивается любым вменяемым техническим продакт-менеджером за 2-3 месяца без особых проблем (при наличии хорошего наставника). 

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

  3. Ценность глубокой детальной проработки бизнес составляющей продукта оказалась сильно завышена. Анализ рынка и конкурентов, прогноз прибыльности новых продуктовых фич, опрос пользователей и т.д. так или иначе основывается на небольшом количестве собранных данных. То есть это в любом случае моделирование, которое на практике оказывается практически невостребованным и не отвечающем реалиям бизнеса. Подчеркну, что в данном случае речь идёт уже про сформировавшийся, вышедший на самоокупаемость В2В бизнес. Очевидно, что в стартапе, который ещё, возможно, даже не знает, в какую сторону ему стоит двигаться, ситуация может отличаться.

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

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

  1. Если у вас стартап, вы получили какие-то инвестиции и весьма смутно себе представляете, как развивать ваш бизнес, у вас есть только общая концепция — ищите опытного бизнес продакт-менеджера. Для вас сейчас наиболее важно определить стратегическое направление развития продукта. Цена ошибки очень высока. Пойдёте в неправильном направлении — уже будет неважно, насколько быстро и эффективно вы разрабатываете продукт.

  2. Вы можете себе позволить сильную и высокооплачиваемую техническую команду, в которой разработчики хорошо знают продукт или способны (и хотят) быстро в нём разобраться — набирайте бизнес-продукт менеджеров. Команда разработки сама разберётся, как им работать и настраивать процессы, и вряд ли нуждается в помощи «менеджеров». Пара хороших бизнес-продукт менеджеров в этом случае зададут хорошее стратегическое направление развития, а дальше разработчики всё реализуют сами. Именно по такому пути идёт большинство крупнейших IT-бизнесов, которые могут себе позволить перекупить сильнейших разработчиков на рынке. В этой ситуации продакт-менеджеры либо вообще не нужны, либо работают далеко от команд разработки.

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

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

  5. У вас В2В бизнес и ограниченное количество клиентов — ищите технического продакт-менеджера. Скорее всего, в силу бизнес-модели, у вас даже не будет достаточного количества репрезентативных данных для анализа бизнеса и классического продуктового менеджмента. При этом качество продукта, его стабильность и эффективность деливери становятся ещё более важными составляющими успешности.

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

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


Автор статьи — Александр Лобов, преподаватель курсов в OTUS.

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

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


  1. famadyx
    22.03.2022 18:38
    +1

    Та дилемма, о которой вы (или автор) пишете -- две крайности, ни одна из которых на дистанции результата не даст.

    Одинаково сложно научить технаря бизнесу и маркетингу, как и маркетолога (в вашей статье Business Product Manager это скорее Marketing Product Manager) технике. Но очевидно, что внимание в равной степени должно уделяться обеим составляющим.

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

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

    В холиваре "кто важнее/лучше/сильнее: маркетолог или разработчик" вы никогда не найдете правильный ответ, потому что его нет -- если бизнес рассчитывает на успех и развитие, то ему одинаково нужны обе эти составляющие. В вашем тексте, ИМХО, вы рассуждаете на тему "Что важнее: руль или колеса". В конкурентной среде подобные заблуждения могут быть фатальными.

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


    1. XaBoK
      23.03.2022 03:49

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

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


  1. Lelant0s
    23.03.2022 23:46

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

    Правильный CEO, толковый. А в команде у вас просто не хватало такой обязанности Product Manager как объяснять всем стейкхолдерам (включая девелопмент, маркетинг, продажи - если вы B2B - и далее по списку) **коммерческий смысл** внедряемых решений. Когда понятен этот смысл, переводить его на "девелоперский" не требуется, потому что если девелопер (и тем более CTO) не может, зная цель, перевести ее в действия в рамках своей непосредственной профессии - гнать таких девелоперов (и тем более CTO) на биржу труда.