Карьера в IT: должность Software Product Manager

Статья продолжает цикл «Карьера в IT» — обзоры должностей в IT.

Если вы уже задействованы в IT проекте в качестве дизайнера, разработчика, тестировщика или другого специалиста и хотите получить большую свободу действий и влиять на продуктовую стратегию компании, то позиция Software Product Manager может оказаться именно для вас.

Software product manager — это человек, который:
— Выступает СЕО продукта;
— Отвечает за продуктовую стратегию компании;
— Имеет глубокое понимание своего сегмента рынка, потребителей и портфолио;
— Периодически тестирует бизнес-кейсы;
— Принимает на себя риски и управление ими;
— Энтузиаст своего продукта;
— Профессионал в коммуникациях и анализе поведения людей.

Наглядно продемонстрировать место SPM в команде можно так:

Задачи и обязанности

Основная задача менеджера по продукту — делать все возможное для постоянного совершенствования продукта на каждой стадии его жизненного цикла.

Выполняя свою работу, Software Product Manager коммуницирует как с командой проекта — CEO, разработчиками, визуальными дизайнерами, UX/UI специалистами, QA, так и с конечными пользователями. На определенном этапе именно взаимодействие с пользователями продукта может составлять более 70% ежедневной работы.

В круг обязанностей менеджера по продукту может входить следующее:
— Общение с заказчиком и его командой, сбор требований, выявление ожиданий и пожеланий;
— Создание user stories, приоритизация беклога продукта, распределение задач;
— Создание feature спецификаций (цели, аналитика, wireframes);
— Взаимодействие с дизайнерами (фидбек по выполненным задачам);
— Создание, обновление и мониторинг дешбордов продукта;
— A/B-тестирование;
— Координация взаимодействия с компаниями, которые исследуют поведение потребителей (UserTesting, Validately, Ask your Target Market и т.д.), затем анализ полученной информации;
— Принятие решений по продукту, основываясь на количественных данных.

Самым сложным часто оказывается именно первый пункт — коммуницирование с заказчиком. Очень важен поиск баланса между возможностью и реальностью, так как заказчик хочет многого, а его пользователи, зачастую, хотят несколько другого. И ваша задача — донести до заказчика мнение и нужды именно его целевой аудитории/пользователей и получить одобрение на внесение модификаций в реализацию его «возможностей».

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

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

Многие спрашивают, чем роль менеджера по продукту отличается от менеджера проекта. Product Manager — это Product Owner, он принимает бизнес-решения, вовлекается в маркетинг и в то, что мы называем Product Shaping. Таким образом, Product Manager влияет на сам продукт. Project Manager занимается не продуктом напрямую, управляет тем или иным проектом (отвечает за то, чтобы проект достиг своей цели).

Иногда эти роли бывают перемешаны, и один человек может совмещать в себе обе функции. Опять же, все зависит от проекта и компании. Например, у меня в компании проектного менеджера нет. Его функции разделены между CEO, CTO и Product Manager.

Как стать менеджером по продукту

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

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

1. The Lean Product Playbook by Dan Olsen — одна и моих настольных книг. Автор — талантливый предприниматель, консультант и Lean product эксперт. Благодаря его инициативе в Сан-Франциско существует сообщество людей, влюбленных в Product Management — Lean Product and Lean UX Silicon Valley. Они организуют на регулярной основе встречи для проведения тренингов, обмена информацией и лучшими практиками, нетворкинга. Некоторые видео можно найти на Youtube.

2. Intercom on Product Management by Des Traynor и John Collins — не настолько интересная, как первая, но служит прекрасным к ней дополнением.

3. Курс «Software Product Management» на Coursera. Стартовал в октябре, поэтому можете успеть пройти его с общей группой. Чтобы пройти курс бесплатно, необходимо регистрироваться на отдельные части курса (без сертификата).

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

5. Касательно используемых тулов, могу выделить следующие:
— UX Design: Balsamiq Mockups, Proto.io, Axure, Uxpin, Bootstrap;
— Agile Development: Trello, Pivotal Tracker, JIRA Agile;
— Исследование потребителей (американских): UserTesting, Validately, Ask your Target Market;
— Аналитика и A/B Testing: Google Analytics, KISSmetrics, Mixpanel, Flurry.

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

Куда двигаться дальше

Что касается перспектив роста в Product Management:
— Развиваться горизонтально — каждый новый проект будет приносить новые знания, возможности, а также понимание, что еще следует доучить и в чем разобраться;
— Создать собственный продукт;
— Стать консультантом (Advisor). Это сейчас крайне актуально — хорошие специалисты помогают растить продукт, получая за это equity или почасовую оплату.

Успешных вам продуктов!

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному3
LinkedIn



24 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Большое спасибо за статью! Нашел очень много полезного для себя.
Заинтерисовал такой момент

UX Design: Balsamiq Mockups, Proto.io, Axure, Uxpin, Bootstrap;
На сколько необходимо иметь опыт работы с одним из этих инструментов?
Ведь как правило прототипированием занимается дизайнер.

Александр, добрый день! Спасибо, приятно, что статья оказалась полезной. Да, чаще всего прототипированием занимается UX дизайнер, но зависит от конкретного случая. Эти инструменты очень простые в использовании, большого опыта не потребуется. Когда у Вас возникнет необходимость, Вы быстро научитесь

Product Manager все таки не принадлежит к Tech части. Он конечно должен понимать, что ему программисты говорят, но он отвечает именно за Business часть.

В интернете много написано про сравнение P managers — product, project, program.

К примеру www.quora.com/...and-Project-manager-roles

Елена, продуктовый менеджер не общается с заказчиками, если конечно он продуктовый менеджер. Заказчики бывают у проекта — кастомизации там, или in-house разработки.

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

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

Не менш часто плутають поняття Product Manager і Product Owner. Скрам, та й багато інших гнучких практик розробки, не є в першу чергу методологіями розвитку продукту. Основна причина хоча би в тому, що вони щільно вписані в «простір рішень» (навіяно аналогією векторного простору), замість «простору бізнес проблем».
Не дивно відтак, що менеджери, які займають посаду Product Owner’а — це часто представники відділу розробки. Основна їхня роль — обслуговувати, а не створювати і направляти беклог. Проблема в тому, що беклог описує все, що стосується продукту. Людина, яка опікується беклогом, автоматично починає відповідати за майбутнє продукту. Межа між продуктовим менеджментом і продуктовою розробкою таким чином стирається.
Чому це важливо? Згадаємо, як виглядає типова розробка продукту. Продуктовий менеджер проводить купу часу досліджуючи ринок, опитує потенційних клієнтів, відвідує профільні конференції, і все заради формування продуктового концепту. Концепт треба описати — формалізуємо у вигляді користувацьких історій. Провести зустрічі з командою і описати ключові речі — навіщо робимо, чому зараз, що має бути обов’язково і в якому порядку і т.д. Це все втілюється з допомогою команди дизайну в вигляді прототипу. Після цього продуктовий менеджер знову переключається на зовнішній світ — оцінка відгуків, удосконалення продукту, розробка нового або повна зупинка проекту. Тим часом, у команди розробки виникають мільйон питань, на які нікому відповісти, тому що продуктовий менеджер уже займається в цей час не менш важливими стратегічними питаннями. От для цього і є в компаніях Product Owner.
Очевидно, що часта зміна фокусів (світ бізнесу і світ команди), і жонглювання як стратегічними, так і щоденними, тактичними задачами, штука малоефективна. Це все відбивається на продукті — він втрачає цільність і вектор. Відповідальність — неадекватна, кількість обов’язків — непосильна для однієї людини. Тому розподіл обов’язків очевидний.
Підсумую. На двох стільцях сидіти можна, але не варто, срака боліти буде.

Все так, от тільки при передачі знань від Product manager до Product owner — не уникнути помилок. Тому доводиться виконувати обидві ролі одночасно (хай це й буде повільніше, зате продукт не доведеться переробляти / правити через непорозуміння)

Добавлю:
1) Часто путают понятия Product manager и Business analyst. ИМХО, это не одно и то же. В чем разница — i2.wp.com/...uploads/2014/08/PMvBA.jpg
2) И, пожалуй, лучшее видео на тему agile product ownership — www.youtube.com/watch?v=502ILHjX9EE

О разнице ПрМ и БА есть ещё такой отличный документ www.allankelly.net/...nMngm5-ProductManager.pdf

...только хотела написать что по списку обязанностей — как раз перечислено то чем занимается БА, спасибо за ссылки

Спасибо за статью.
Добавлю некоторые мысли от себя.

Роли менеджера продукта и менеджера проекта частенько путаются. Например распределение задач это занятие для тех лида или менеджера проекта ну или это самоорганизация команды. Но никак не то чем должен заниматься менеджер продукта.

Недавно появилась хорошая статья от Джоша Елмана. Это человек с огромным опытом и весьма сильно повлиявший на развитие линкедина и фейсбука. Рекомендую почитать medium.com/...t-d7bc5606e0c4#.t6616kqc1

Абсолютно согласен с автором что для ПМа нужен технический бекграунд. Много хороших ПМов умеют программировать.

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

Также вот интересная статья со списком вопросов с продуктового интервью tech.transferwise.com/...fying-product-interviews

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

Статью обязательно прочитаю, спасибо!

Спасибо за лаконичную статью. Заметил, что многие аспекты задач и обязанностей Product Owner’а похожи на те, с которыми сталкивается тестировщик/аналист, особенно в небольших командах и при плотном общении со стороной заказчика. Потому данная роль может рассматриваться как дальнейший вектор развития специалистов из области тестирования и QA.

Хороша стаття. Автору великих продуктових розробок і нових завершених продуктів. :)

Спасибо, Орест!

Спасибо. Нужная статья, как и вся серия таких статей на ДОУ. Может добавите ссылки на остальные статьи по специализации из этого цикла, как вот тут списком в конце статьи: dou.ua/...les/qa-engineer-position

Ссылки добавим, а также все статьи серии можно увидеть здесь — dou.ua/lenta/tags/Карьера в IT

Спасибо! Прекрасная статья, как раз то, что я сейчас ищу и интересуюсь для дальнейшего развития.

Статья хорошая. Но для меня всё равно остаётся размытой грань между product и project менеджером.

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

ок. Но всё равно границы очень размыты. То, о чем вы сказали, может сделать и UX/UI-designer. Думаю, каждая фирма сама разделяет границы обязанностей своих соорудников и даёт названия должностям. Да, кто-то должен делать эту работу, но будет ли это SPM, UX/UI или BA — уже дело вкуса работодателя. Я давно пытаюсь понять, где тут граница — и не вижу её.

Всё ясно, а вот за это

UserTesting, Validately, Ask your Target Market;
спасибо!

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

Спасибо, обязательно перечитаю всю указанную литературу. Хотя я и не являюсь product manager но с этими всеми задачами приходится сталкиваться или мне, или заказчикам. Как жаль конечно что на небольших проектах мы не можем выделить отдельного человека на это направление...

Підписатись на коментарі