Учить языки программирования или не учить? Вот в чем вопрос. Каждый продакт-менеджер сталкивался с ним в начале своей карьеры. Если коротко — нет, но есть нюансы.

Кто вообще такой этот человек, продакт-менеджер? Он формулирует стратегии по развитию продукта, которые позволяют достигнуть бизнес-целей, технически осуществимы и отвечают потребностям клиентов. И слово бизнес здесь — ключевое. Задачи менеджера связаны с бизнес стороной и отличаются от задач программиста; уже поэтому кодить попросту необязательно.

Но что же насчет нюансов?

Размер компании

Во-первых, между обязанностями менеджерa.

Для того, чтобы максимально сократить затраты на время и быстрее получать результаты, вам и придется учиться программированию. Если вы работаете в стартапе с небольшим количеством людей и, например, хотите получить какие-то данные из базы данных, то лучше уметь писать элементарные запросы на Python/SQL, чем писать задачу для нужного разработчика. В этом случае навыки программирования становятся вынужденной необходимостью.

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

Глубокое знание продукта

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

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

Общение с командой

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

Как знание английского помогло бы во время путешествий, так и умение программировать поможет заговорить на одном языке с разработчиками, быстрее разбираться как в технологическом стеке, так и в проблемах, с которыми сталкиваются его разработчики. Хотя для работы с разными продуктами придется анализировать разные стеки, для каждого вида разработки есть общепринятые стандарты — Java/Swift/Kotlin для мобильной или MEAN/LAMP веб-разработки. 

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

Расширение кругозора 

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

Кроме того, планирование также является огромной частью написания кода. Так что если у вас есть проблемы с организацией рабочего процесса, то самое время взяться за SQL или Python.

Бонус: Техническое интервью

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

Подведем итоги

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

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


  1. vadimr
    12.10.2022 08:37
    +3

    Управлять процессом, не понимая его, нельзя, по тем же самым причинам, по которым нельзя построить управляющую обратную связь для чёрного ящика. Из таких попыток происходят все анекдоты об “эффективных менеджерах”.

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

    Продакт-менеджер, не умеющий программировать – не нужная ни одной из сторон прокладка между тимлидером и финансовым директором.


    1. Ivan22
      12.10.2022 10:48

      ты еще скажи - это как министром обороны сделать гражданского


      1. vadimr
        12.10.2022 11:39

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


      1. CyaN
        13.10.2022 16:19

        Министром обороны - легко. А вот начальником Генштаба - нет.


  1. i360u
    12.10.2022 09:27
    +1

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


    1. Ivan22
      12.10.2022 10:49
      +1

      если это стартап аля убер - должен ли продакт быть из таксистов?


      1. i360u
        12.10.2022 11:24

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

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


  1. AndreyDmitriev
    12.10.2022 10:15
    +2

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


    1. vadimr
      12.10.2022 10:22

      В следующий раз будет отзывать вас из отпуска :)

      Всё имеет свою цену.


    1. Ivan22
      12.10.2022 10:50
      +1

      ну ПМ должен разбираться, но не должен кодить сам. Это как бы золотая середина.


  1. CyaN
    13.10.2022 16:12

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

    А получается в результате примерно так:

    Hidden text

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

    В маленьком стартапе - возможно. А если у вас информация из полусотни систем собирается в пару тысяч таблиц хранилища данных?

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