Хотите управлять продуктом? О чем молчат все менеджеры по продукту

https://medium.com/on-product-management/c664ba7e5138
  • Перевод
Безусловно, каждый в команде разработчиков делает всё возможное для выпуска крутого продукта. Но в случае неудачи все шишки сыплются на одного человека — менеджера по продукту. Конечно, на орехи достанется не только ему. Но именно для менеджера по продукту эта неудача — не просто «рабочий момент», а крест на всей проделанной работе.

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

Перевод статьи выполнен компанией-локализатором Alconost.

image


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

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

Да и потом, как мило роль выглядит со стороны:
  • вы — мини-директор;
  • вы ведете за собой других;
  • вы — эксперт отрасли;
  • вы решаете, как будет выглядеть и восприниматься продукт сегодня и в будущем;
  • вам хорошо платят;
  • вы — реальный босс.

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

image
Вкратце

На самом деле, управлять продуктом — это:

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

Управлять продуктом НЕ означает:

  • иметь решающий голос;
  • быть единственным генератором идей;
  • быть дизайнером;
  • быть программистом;
  • управлять обеспечением качества;
  • оптимизировать сайты;
  • писать вспомогательные маркетинговые материалы.

Откуда я знаю

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

Почему «к моему удивлению»? Во-первых, потому, что я действительно не знала, чем занимается менеджер по продукту. «Ух ты, — думала я, читая и перечитывая письмо с предложением работы. — На всех собеседованиях я только и делала, что говорила о своих страстных увлечениях. Неужели этого оказалось достаточно?». Во-вторых, потому, что диплом я защищала по психолингвистике. А психология языка, по моим последним данным, имеет мало общего с финансовым ПО.

Первым моим продуктом был QuickBooks. Я отвечала за управление бета-версией нашего ежегодного релиза. Опыт, который я получила, показал мне все аспекты профессии менеджера по продукту. Аспекты, о которых не упоминают в описаниях вакансий.

Четыре главных аспекта — вот они.

1. Вы управляете не продуктом, а проблемой, которую он решает.

Когда я узнала, что буду управлять QuickBooks, меня чуть не вывернуло. «QuickBooks?! — возмутилась я. — Да этой программе сто лет в обед!» (на самом деле, конечно, это не так — но когда живешь в Кремниевой долине, где новые продукты появляются каждую секунду, QuickBooks воспринимается как какой-нибудь патефон). Я была разочарована тем, что не смогу работать как «настоящий» менеджер по продукту и создавать «инновации». Мне хотелось управлять стильным, модным, молодежным продуктом.

Но я глубоко заблуждалась.

image

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

У вас всегда будет слишком много запросов на добавление новых возможностей — и слишком мало времени. Слишком много багов — и слишком мало времени. Вам всегда есть что делать. Допустим, вы располагаете готовым продуктом, с которым у пользователей уже сложилась тактика взаимодействия, а у компании вокруг этого продукта уже выстроены бизнес-процессы. Кем вы должны быть, чтобы внедрять инновации в таких рамках? Правильно. Супергероем.

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

2. Продукт крут, если он крут в представлении пользователя.

Управление нашей бета-версией подразумевало не только еженедельное общение с тестировщиками по e-mail, но и разговоры с ними по телефону. Иногда я целыми днями занималась предоставлением разнообразной технической поддержки. Поначалу это жутко разочаровывало. «Почему я занимаюсь реагированием на проблемы? — недоумевала я. — Я же должна была управлять продуктом!».

Я провела много времени в общении с пользователями и в наблюдении за тем, как они используют продукт. И я поняла, что пользовательское «не работает» на самом деле означает, что продукт работает не так, как они ожидали. Пользовательское восприятие — это и есть реальность, и не мое дело объяснять пользователям, что они делают не так. Наоборот: мои беседы с пользователями помогли мне понять, что делаю не так я. С этим пониманием я приходила к разработчикам и дизайнерам, чтобы устраивать «мозговой штурм» и делать так, чтобы у пользователей все «заработало».

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

3. Менеджер по продукту — не дизайнер и не разработчик.

Мне сказали, что для регистрации приложения в AppStore понадобится дизайн продающей страницы. Будучи новичком, я восприняла задачу буквально — и увязла в слоях и цветовых палитрах Photoshop. Опьяненная выбросом эндорфина, сопровождающим процесс творения, я отправила страницу по почте своему начальнику. Его ответ не изобиловал похвалой в той степени, в которой я ожидала. Ответ был таким: «Клёво. Это наш дизайнер делал? Как по мне, пускай бы еще поиграл с цветовой схемой». «Дизайнер?! — вопросила я у компьютера. — О чем он вообще?».

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

4. Не быть звездой, а управлять Вселенной.

В первый день в команде QuickBooks мой начальник провел меня по офису и представил всем — буквально всем: специалистам поддержки, маркетологам, разработчикам, дизайнерам, финансистам. Это меня ошеломило — но куда больше я была обеспокоена тем, сколько времени на это «убил» мой начальник. Почему он не начал с представления меня другим менеджерам по продукту? «Конечно же, я познакомлюсь с ними позже», — решила я. Но в куда более неловкое положение меня поставило даже не то, что он представил меня такому огромному количеству людей, а то, как он это сделал. «Она будет отвечать за выпуск QuickBooks», — говорил он всем. А я не понимала, как я вообще собираюсь выпускать QuickBooks, если я еще даже не скачала его на свой компьютер…

Шли недели, и становилось понятно, что выпускать QuickBooks в мир я буду не одна, как могла бы, если бы речь шла о голубях на выпускной церемонии. Наоборот: моя работа — способствовать правильным мозговым штурмам и общению между людьми (теми, с кем меня знакомили в первый день), чтобы в итоге мы пришли к решениям, от которых зависит выпуск. Это и шокировало, и немного утешало (совсем немного). Мне не нужно было предлагать самые лучшие идеи. Я должна была лишь убедиться в том, что в комнате собрались нужные люди, способные предложить море идей, из которых я могла бы выбрать лучшую.

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

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

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

И если целевому пользователю ваш продукт не нужен — виноваты вы, а не он.

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией приложений, игр и сайтов на 60 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее: https://alconost.com

Alconost 93,97
Локализуем на 68 языков, делаем видеоролики для IT
Поделиться публикацией
Комментарии 29
    0
    Ну действительно, причем тут менеджер? Это ведь product designer! Человек, болеющий и отвечающий за качество продукта, в чем-то проектирующий его, а не присматривающий за сроками, безликий и ни в чем, конкретно, не разбирающийся «менеджер».
    Мне кажется, UXer больше всего подходит на такую роль ;-)
      +3
      Ага, особенно если продуктом является библиотека шифрования.
        0
        Product manager, product owner, product designer — хоть горшком назови, задача одна, выпускать успешный продукт. Не обязательно быть UXером, чтобы понимать, что продукт нужно ориентировать на задачи пользователя. Даже если это библиотека шифрования.
          +1
          Как показывает практика UXer в роли ПМа может создать очень неприятный перекос в приоритетах.
          ПМ должен думать не только о качестве продукта, но также и о комфорте команды, о перспективах роста продукта.
            0
            нет, PM это обычно человек вырастающий из разработчиков, системных архитектов или SME. Хороший технарь, легко понимающий нюансы внутреннего планирования продукта, а не только «сделайте мне красиво». Плюс надо иметь опыт в сфере, иметь контакты с клиентами и сообществом, иначе откуда узнаешь чего именно надо клиентам в следующей версии?
              +1
              К сожалению не совсем так. Возможно, прочитав эту статью Вы не верно поняли, чем занимается Продакт менеджер. Справедливости ради, отмечу, что статья тоже несколько однобока. Отвечая именно Вам, а не автору статьи, скажу, что UX бэкграунд это весомое подспорье, которое пригодится на этапе проектирования продукта но не более. Мало толку от юзабилити, если сам по себе продукт не решает проблем пользователя или не имеет чёткого позиционирования и стратегии вывода на рынок.
                0
                Ну, надо все-таки отличать UX от usability. UX-специалист как раз и должен «решать проблемы пользователя», это его главная задача. Почитайте ГОСТ Р ИСО 9241-210 про HCD.
              +1
              >>Я не удивлюсь, если действительно «каждый» хочет стать менеджером по продукту. Это одна из немногих профессий, для которой не
              >>требуется быть экспертом в какой-либо специфической сфере. Чтобы управлять продуктом, не нужно знать,
              >>как создавать модели данных или писать код;
              Ага да, есть такие люди, бывают полезными, когда начальство понимает что орать на тех кто делает всякое полезное нельзя, но поорать на кого-то все-таки хочется.

                0
                Судя по всему, у героини поста должность совмещала обязанности как менеджера по продукту так и менеджера проекта, раз она общалась с непосредственными исполнителями. Вообще-то это две разные роли.
                  0
                  А как по вашему повышать вовлеченность команды? Если у команды не будет уелостного видения продукта и понимания того, как и для чего его использую пользователи, то они такого нагородят. У меня на практике есть яркие примеры таких «франкенштейнов», которых затем в спешном порядке приходилось вытаскивать за уши.

                  ИМХО роли в команде зачастую определяются внутренним устройством компании, а не базовыми методологиями или стандартами. Совмещение ролей также очень часто зависит от стадии жизненного цикла продукта. В общем нюансов куча.
                    0
                    А как по вашему повышать вовлеченность команды? Если у команды не будет уелостного видения продукта и понимания того, как и для чего его использую пользователи, то они такого нагородят
                    Так не важно кто этим занимается — РП или ПМ. Кроме того, может быть схема когда вовлечены только несколько ключевых исполнителей (архитектор, тимлид и т.п.) а рядовым исполнителям просто спускают конечные задачи.

                    роли в команде зачастую определяются внутренним устройством компании, а не базовыми методологиями или стандартами. Совмещение ролей также очень часто зависит от стадии жизненного цикла продукта
                    Абсолютно верно. Более того, если уровень загрузки и компетенция сотрудника позволяет — лучше именно совместить. Я долго работал менеджером проекта, задачи мне ставил менеджер по продукту. Он не был мне начальником, скорее заказчиком, внутренним. И знаете, отношения заказчик-исполнитель не способствуют продуктивной творческой деятельности. Вроде как делают один продукт, одно дело, а де-факто цели получаются разные. А дальше как лебедь, рак и щука.
                    Но разумеется экстраполировать на любые проекты нельзя, очень много нюансов.
                    0
                    PM просто обязан общаться с разработчиками — обязательно с руководителями команд и иногда напрямую с программистами. как иначе донести до них свои требования к очередной версии?
                    А если регулярно с ними не встречаться и не общаться, то как можно эти требования вообще составить? Ведь вся эта работа это составление технических и маркетинговых компромиссов, относительно ресурсов и временных ограничений.
                    Если требовать звезд с неба, их можно получить, но это будет за счет других, не менее востребованных фичеров или времени. А GTM штука тонкая, никого не ждет.
                    Так что надо постоянно жонглировать возможностями Dev/QC/SA/TS, требованиями клиентов и рынка вообще и временными рамками. Картинка с курицей без головы очень подходит
                      0
                      PM просто обязан общаться с разработчиками — обязательно с руководителями команд и иногда напрямую с программистами. как иначе донести до них свои требования к очередной версии?
                      Не обязательно. У менеджера по продукту может быть единая точка входа в разработку — руководитель проекта. Я так работал долгое время. Традиционная схема заказчик-исполнитель.

                      А если регулярно с ними не встречаться и не общаться, то как можно эти требования вообще составить
                      Вообще-то требования к продукту должны исходить от потенциальных клиентов или менеджера продукта, но никак не от разработчиков.
                        0
                        Не обязательно. У менеджера по продукту может быть единая точка входа в разработку — руководитель проекта. Я так работал долгое время. Традиционная схема заказчик-исполнитель.


                        это если проекты разовые. Если идет разработка стабильного продукта (или как еще называть «долгоиграющий» продукт, который развивается от версии к версии годами), то руководитель проектов не нужен — проекта, собственно, не существует.

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


                        требования — да. разработчики могут тут разве что подкинуть мысли и идеи для фичеров (типа «я тут ковырялся, и такая фигня прикольная получилась, может пристроим куда нибудь?»).
                        Но когда я прихожу к тимлиду с требованиями, а он мне говорит «нет технической возможности», что мне делать, топать ножкой? Именно поэтому я и писал о компромиссах, PM должен задействовать всех, от клиентов и сейлсов с интеграторами, до разработчиков, тестировщиков и саппорта.
                        У меня бывало и такое что фичер приходилось убрать из версии за месяц до публичной беты, потому что начальник саппорта говорил что не успевает натренировать людей на поддержку фичера.
                          0
                          это если проекты разовые. Если идет разработка стабильного продукта (или как еще называть «долгоиграющий» продукт, который развивается от версии к версии годами), то руководитель проектов не нужен — проекта, собственно, не существует.
                          И снова позволю себе с вами не согласиться :) Последние 3 года трудился руководителем проектов именно на «долгоиграющих» продуктах. Это были отраслевые тиражируемые коробочные решения. В таких продуктах четко различаются две стадии:
                          1. Разработка первой версии до выхода на рынок. Это классический проект с бюджетом, сроками и качеством. Причем первая версия может разрабатываться не один год.
                          2. Дальше, в зависимости от организации процесса в компании, тоже могут быть проекты. У нас проектом назывался очередной большой релиз. На него формировался набор требований, фиксировался ресурс и конечно сроки. Причем к такой схеме мы пришли от «беспроектной», как вы описали. Это был хаос хотелок клиентов патчей и релизов. Абсолютно неуправляемый и непрозрачный для руководства процесс.

                          Но когда я прихожу к тимлиду с требованиями, а он мне говорит «нет технической возможности», что мне делать, топать ножкой?
                          Это ответ, что называется «на отъе… ись». Как аргументируют? Нет нужных компетенций или нет людей?
                            0
                            1. Разработка первой версии до выхода на рынок. Это классический проект с бюджетом, сроками и качеством. Причем первая версия может разрабатываться не один год.


                            тут я полностью согласен. у нас это еще называли startup mode

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


                            у нас очередная версия проектом не было, да и понимание того что за время разработки версии требования и условия могут измениться тоже диктовали такой подход. у нас было достаточно клиентов которые реально могли диктовать что им нужно в следующем релизе (и менять требования о ходу дела), и хватало зависимостей от апстрима и интегрируемых продуктов, которые вполне могли не успевать за нашим расписанием. Так что scrum/agile/etc более чем помогали.
                            Конечно же элементы управление проектом там были, куда без них? Но продход не был как к очередному проекту — все намного сложнее

                            Это ответ, что называется «на отъе… ись». Как аргументируют? Нет нужных компетенций или нет людей?


                            нет нужных фичеров в апстриме или в интегрируемом продукте. свои велосипеды создавать займет годы. Или требуемое клиентом абсурдно с т.з. данной технологии и выступает против всех нормальных best practice в отрасли. Да мало ли на самом деле возможных причин :)
                              0
                              у нас очередная версия проектом не было, да и понимание того что за время разработки версии требования и условия могут измениться тоже диктовали такой подход
                              Верно, поэтому мы старались сокращать очередной релиз до 2-4 месяцев, не более. Чтобы можно было зафиксировать требования на этот срок. Ну практически как итерация в agile.

                              нет нужных фичеров в апстриме
                              Если често не понял ни про «фичеров» ни про «апстрим». Что это значит?
                                0
                                Верно, поэтому мы старались сокращать очередной релиз до 2-4 месяцев, не более. Чтобы можно было зафиксировать требования на этот срок. Ну практически как итерация в agile.


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

                                Если често не понял ни про «фичеров» ни про «апстрим». Что это значит?

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

                                апсрим это вообще понятие из опенсорса — обычно нестабильный, свежий код который разрабатывается сообществом, а коммерческая фирма его берет потом, дописывает, тестирует, и превращает в настоящий продукт. но опять же, если в апстриме нет функционала, то фирма которая его принимает на обкатку обычно этот функционал не добавляет (хотя мы и тут делали исключения)
                    +1
                    Как мило «беспокоюсь, не воспринимают ли меня простым дублером JIRA» :-)
                      0
                      очень неверная по многим пунктам статья. PM это очень тяжелая работа, и на ней надо быть очень хорошим техническим экспертом, иначе просто не вникнешь в тонкости планирования версии.

                      это я из опыта работы Sr PM в Red Hat, если что.
                        0
                        Руководитель продукта в большей степени режиссёр или если хотите дерижёр, а так же маркетолог и немного финансист. Техническим бекграундом он обладает куда в меньшей степени, нежели выше озвученными качествами. Не могу говорить за вас, но судя по всему Вы имели ввиду Проектного менеджера, хотя и он тоже в большей степени планировщик и коммуникатор, нежели технический эксперт.
                          +1
                          нет, именно product manager. человек не понимающий внутренностей продукта не может управлять его разработкой. не обязательно лезть в код, но быть хорошим экспертом по продукту разработкой которого управляешь просто необходимо, иначе можно или самому нагородить глупостей, или по непониманию дать разработчикам увлечься какой нибудь ненужной клиентам чушью, которая им кажется интересной, но на самом деле не имеет отношения к требованиям рынка.
                            0
                            > человек не понимающий внутренностей продукта не может управлять его разработкой
                            > не обязательно лезть в код
                            Нет ли тут противоречия? Я не говорил, что он не должен знать продукт изнутри, но на высоком архитектурном уровне, а хороший технический эксперт это всё же более низкоуровневая роль. Кроме того, что вы скажете о тех продуктах и сферах, где технической подоплёки как таковой нет, а есть скорее технологическая — разница, думаю, понятна?
                              0
                              все верно. не обязательно знать конкретно каждый класс и функцию, но понимать (блин, как бы это по русски сказать) — flow событий, подробный алгоритм, надо обязательно. и это касается любой отрасли
                        +2
                        Хорошая статья. «Не быть звездой, а управлять Вселенной» — вообще зачёт.
                          +1
                          Я тогда заканчивала колледж по специальности «Психология»…
                          К моему удивлению, мне предложили стажировку на должности менеджера…
                          я действительно не знала, чем занимается менеджер по продукту…
                          диплом я защищала по психолингвистике…
                          Когда я узнала, что буду управлять QuickBooks, меня чуть не вывернуло…


                          Коллеги, видится мне это так:
                          1. Берут некую особь из золотой молодежи, без профессии и без опыта работы, и с помощью родителей или еще кого-то сажают на шею команде профессионалов, которые уже давно выпускают успешный продукт. Особь при этом еще и кривится — не на инновации её посадили.
                          2. Запас прочности опытной команды был достаточен, и они смогли повезти на своей шее и эту наездницу, причем обучая её по пути как надо работать.
                          3. По ходу движения свежеиспеченный эффективный менеджер делает для себя открытия как меньше лажать в работе, а теперь еще и делится с нами.
                          4. Но какова ценность её откровений? И даже если всё сказано правильно, не лучше ли почитать какого-нибудь другого автора на ту же тему?
                            0
                            вот вот, мне показалось примерно то же самое. и да, я сейчас работаю с quickbooks, и очень часто желаю им мучительной смерти и прочих разнообразных лучей. теперь я знаю почему с каждой версией там все веселее
                            0
                            Работаю ПМ 6 лет. В разных компаниях, разных командах и на разных стадиях жизни продукта ПМ может выполнять разные функции. Это и разработка концепта — для кого, зачем, сколько заработаем и сколько потратим. Это и дизайн продукта — функции, интеграция с другими продуктами, и сам дизайн. Если нет выделенного менеджера проекта или скрам мастера, то ПМ нередко сам управляет разработкой и планирует релизы. Если нет менеджера по маркетингу продукта, то надо заниматься еще и рекламой и ПР.
                            По моему опыту ПМ — это такой мини-босс, который не должен быть экспертом во всех областях, но должен иметь о них хотя бы базовое представление. Но некоторые области все же самые важные: вы должны быть экспертом по своим продуктам — их пользователям, функционалу, финансовым показателям, возможностям роста и конкурентам. Вы должно четко понимать, зачем компания делает продукт. И тогда есть шанс сделать что-то достойное.

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое