product owner что это

Кто такой Product Owner, чем занимается и как отличается от project-менеджера

В scrum-команде есть несколько основных ролей. Одна из них — Product Owner. Рассказываем, кто это и чем занимается.

Product Owner, или «владелец продукта» знает всё о потребностях и болях пользователя, возможностях команды, видит их точки соприкосновения на благо всего проекта.

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

Менеджер проекта и Product Owner — это не одно и то же. Менеджер проекта — руководитель: он распределяет задачи и нагрузку, проверяет и снова руководит процессом.

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

Пишет про управление в Skillbox. Работала координатором проектов в Русском музее, писала для блога агентства CRM-маркетинга Out of Cloud.

Функции Product Owner ближе к работе, которую выполняет Product Manager. Чтобы научиться и стать профессионалом в этой области, обратите внимание на практический курс «Управление продуктом» от Skillbox.

Роли продуктового менеджера и владельца продукта часто объединяют в вакансиях.

Роль Product Owner
в scrum-команде

Напомним, что Scrum — методология гибкой разработки программного обеспечения. Она основана на Agile-манифесте.

Scrum-команда — это владелец продукта, scrum-мастер и разработчики. В заказной разработке — еще клиент, пользователи и стейкхолдеры.

Чем занимается
Product Owner

Product Owner выполняет часть функций руководителя проекта, менеджера продукта и маркетолога. Он не управляет, а направляет команду, чтобы вместе прийти к желанному результату. У него есть власть и ответственность.

Product Owner отвечает за продукт на всех этапах его создания:

По Scrum владелец продукта — это роль одного человека из команды. Но компании, которые используют фреймворк, адаптируют его под свои потребности. Поэтому бывает, что один человек выполняет сразу несколько ролей. Например, менеджер проекта в заказной разработке — это и scrum-мастер, и Product Owner. Это противоречит scrum-гиду, но вполне допустимо, если система работает и приносит нужный результат.

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

Что важно для владельца продукта

Обязанности владельца продукта зависят от типа проекта. Вот что для вас важно, если вы — Product Owner.

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

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

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

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

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

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

Заключение

Мы рассказали, кто такой Product Owner и чем он занимается. Если у вас остались вопросы или вы хотите подробнее разобраться в Scrum и Agile, советуем почитать и посмотреть:

Чтобы быть владельцем продукта, нужно уметь работать по Agile-методологиям. Разбираться в маркетинге, юзабилити, разработке и управлении, а главное — понимать жизненный цикл продукта.

Источник

Product Owner vs Product Manager или Product Owner/Product Manager

Кто прав? Единого ответа нет. Сфера ИТ стремительно развивается, компании расширяются, создаются новые проекты, которые требуют новых подходов. Появляются “многостаночники”: девопсы, фулстек-разработчики, технические проджект-менеджеры. Все это зачастую приводит к путанице, когда HR-команда не может четко сформулировать, кто же им собственно нужен, и появляются вакансии, которые включают в себя набор обязанностей “от всех по чуть-чуть”.

Сделав сравнение Project Manager и Product Manager, я получила вопрос:

“А в чем тогда разница между Product Owner (владелец продукта) и Product Manager (менеджер продукта)?”

Давайте разбираться вместе!

Product Manager не привязан к какой-то определенной модели, методологии или фреймворку.

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

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

На этапе зарождения продакт-менеджмента скорость развития рынка и выпуска продуктов была совсем другой. Продакт-менеджер разрабатывал видение продукта и передавал его на реализацию проджект-менеджеру. В 1980-х, когда рынок стал меняться быстрее, продукты к моменту их выхода могли потерять свою актуальность. Появился Scrum со своей ролью владельца продукта, который чувствует, “куда ветер дует” относительно его бизнеса, и вносит необходимые изменения в беклог, постоянно держа руку на пульсе и корректируя приоритеты.

“визионера, который ведет идеи новых продуктов от первоначального концепта до запуска “созревшего” продукта”.

Примеры вакансий и более подробное их описание можно посмотреть FB Product Manager и Sr. Product Manager от Amazon. В Google помимо более 600+ запросов на эту должность, есть своя обучающая программа “Google Associate Product Manager Program”.

А что же с требованиями к этим должностям? Какими эти позиции видят рекрутеры?

Требования к Product Manager:

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

Понимание, как превращать потребности клиента в готовый продукт.

Опыт в проведении тестов (к примеру, A/B, A/A) и навыки анализа больших объемов информации.

Знание принципов UX/UI дизайна и инструментов для прототипирования.

Опыт в создании плана развития продукта или отдельных функций и отслеживание его выполнения.

Умение работать в постоянно-меняющейся окружающей среде и сбор необходимых аналитических данных для “процветания” продукта в этих условиях.

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

Требования к Product Owner

Опыт работы в Scrum и понимание гибких методологий и фреймворков в целом.

Организационные, аналитические и коммуникационные навыки.

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

Способность правильно приоритизировать деятельность (как свою, так и команды) для успешной работы над проектом.

Умение анализировать, КАК думают потенциальные пользователи, ЧЕГО они хотят, КАК себя ведут с целью дальнейшего “превращения” этой информации в функции и услуги.

Способность “предсказывать” тренды в будущем, основываясь на имеющихся данных.

Опыт в оптимизации продукта через А/В тестирование.

Умение разбивать весь объем работы на отдельные задачи для дальнейшей презентации их стейкхолдерам и членам команды.

Опыт написания технической документации.

И если требования более-менее отличаются, то обязанности очень подобны.

Обязанности Product Manager:

Находить и анализировать возможности рынка и потребности ЦА для создания концепта продукта и стратегии его разработки.

Общение с клиентами напрямую.

Создание плана разработки, контроль его выполнения и написание документации.

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

Написание high-view требований и детализация их с командой.

Создание пути клиента “от А до Я”, чтобы впечатления пользователей были максимально положительными на всех этапах взаимодействия с продуктом.

Мониторинг метрик, создание и проверка гипотез.

Помощь при выведении продукта на рынок и дальнейшая его поддержка.

Обязанности Product Owner:

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

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

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

Определять объем работ для разработчиков и формировать беклог.

Управлять релизами, ставить задачи команде.

Участвовать в демонстрациях и ретроспективах.

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

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

Формировать дорожную карту продукта.

Контролировать создание продукта от идеи до поставки заказчику.

Источник

Product Owner — кто это такой и чем занимается?

ex-СМО Orca.App, Travelata, Biglion, Mamba, Growth Head Bitrix24

Дмитрий Лучкин, Product Owner в «Сравни.ру», рассказал об особенностях своей профессии. До Product Owner он был директором по маркетингу в таких компаниях, как Mamba, Biglion, Chefmarket, GorodTroika, Travelata, Bitrix24, Orca.App.

По его словам, за последний год в новой должности ему удалось увеличить выручку в 30 раз, улучшить конверсии в 2,5 раза и перезапустить продукт на нескольких платформах в «Сравни.ру».

Содержание:

Product Owner — это специалист, который отвечает за развитие и управление продуктом в digital-проектах, контролирует все метрики и управляет командой разработки. Он владелец продукта, что означает, что Product Owner ведет себя фактически как предприниматель, который рискует, быстро генерирует и проверяет гипотезы.

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

Product Owner — какова его роль в Scrum-команде

Для начала, что такое Scrum. Это подход в управлении проектам, который появился в середине 90-х. В нем основной упор делается на гибкость и коммуникации внутри команды, четкое определение ролей, фокус на приоритетных задачах, которые нужно выполнить за короткий промежуток времени — спринт (от одной до четырех недель).

Product Owner лидирует в вопросе, что именно делать, какие цели у команды в каждом спринте. Он понимает, как сбалансировать задачи, чтобы достичь бизнес-целей, улучшить конверсии и клиентский опыт, но и не забыть про технический долг, инфраструктурные и SEO-задачи.

Спринты обычно следуют логике квартальных планов с OKR (методология Objectives and Key Results) и KPI, поэтому Product Owner согласовывает с топ-менеджерами приоритеты, цели и инициативы на квартал, а после они бьются на спринты.

В небольших командах, где нет Scrum-мастера, Product Owner отвечает за стендапы и ежедневные синки. На этих 15-20-минутных встречах каждый член команды говорит о том, что было и будет сделано. Это позволяет видеть прогресс, а также трудности и сложности для реализации целей.

Также он отвечает за груминг (первичная оценка) и планирование задач перед стартом спринта. Если в компании есть несколько команд, от деятельности которых зависит развитие продукта, то Product Owner еще отвечает за коммуникации с другими командами. Обычно это делается перед квартальным планированием, особенно это принято при использовании SAFe (Scaled Agile Framework), когда все команды работают с использованием принципов Agile, но имеют зависимости между собой, когда ваш продукт зависит от внесения изменений в микросервис или код, которым владеет другая команда.

Качества Product Owner

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

Деловые качества

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

Умение находить компромиссы, убеждать, продвигать интересы продуктовой команды — это очень важные качества. Зачем это нужно? Для того, чтобы получать ресурсы и нужные решения для развития продукта. Смотрите, вы анализируете метрики, общаетесь с пользователями, делаете опросы, кастдевы на постоянной основе, проводите UX-тесты. Но потом, чтобы получить нужное решение, необходимо это упаковать и донести до руководства. Это зачастую занимает 20-25% работы.

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

Например, чтобы увеличить конверсию на сайте, можно использовать механики Social Proof — это очевидно, но часть команды или руководства может сказать, что это не сработает, а вы знаете, что четыре из 25 механик у вас уже показали эффективность в другом проекте.

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

Личные качества

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

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

Это также касается постоянного поиска точек роста, несмотря на возможное отсутствие прогресса.

Известно, что 90-95% A/B-тестов не показывают изменения конверсий в лучшую сторону. Они не дают того, что от них ожидали, поэтому нужно быть готовым к тому, что не будет роста метрик в том или ином тесте, и при этом не терять энтузиазма.

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

Я, например, к любому тесту отношусь нейтрально, чтобы верить только цифрам. Победит А или В — вот и все. Делайте чаще A/B-тесты, чтобы поймать улучшение конверсий и метрик. Остальное не имеет значения.

Лидерские качества

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

Любой Product Owner должен уметь мотивировать, вдохновлять людей, показывать пример, помогать находить решение, заряжать энергией. Обычно хорошие Product Owner — это зажигалки, и команды в их управлении делают на 20% больше задач.

Также очень хорошо работает такая вещь, как оценка собственных действий, сделанных за прошедший спринт, месяц, квартал. Это анализ ошибок и неоптимальных решений. Я считаю, что такой ретроспективный взгляд нужен постоянно любому Product Owner. Это анализ того, что я мог бы сделать по-другому, что я могу сделать лучше. Туда же входит получение обратной связи от коллег.

Объем и глубина власти над продуктом

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

Я, например, копаюсь в данных и прогнозирую динамику текущей недели к прошедшей неделе, текущий месяц к прошлому месяцу. Я смотрю темп роста по каналам и конверсиям день ко дню нарастающим итогом в рамках недели (как выросли ваши показатели за понедельник-четверг к прошлому период понедельник-четверг) или месяца (как изменились показатели за 1-14 сентября к 1-14 августа, например).

Можно и нужно смотреть такую же динамику к прошлом году, т.е. сравнивать, как вы приросли 1-14 сентября 2021 года к 1-14 сентября 2020 года, например, на 12% из страницы тура в отправлении заявки на этот тур. А по-хорошему в сравнении с динамикой прошлого 2020-го года с позапрошлым 2019-м, где рост конверсии был, например, 18%. Т.е. в этом примере ваш рост замедляется.

Те ребята, которые погружены максимально глубоко, обычно сравнивают недели по дням, чтобы не было искажений по метрикам будней и выходных дней, т.е. сравнивают неделю 31 2021 года с такой же неделей 2020 года и помнят про такую же неделю 2019 года.

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

Бэклог продукта

У любого продукта есть бэклог — это список технических и аналитических задач. Чем более он качественный, тем выше шанс получить изменения. Поэтому все отобранные идеи записываются в бэклог в виде задач. Обычно это делает Product Owner.

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

Зачем это делается? Команде, которая живет в 1-2-недельном спринте, очень приятно видеть ежедневный прогресс по задачам. Такова психология. Людям важно видеть, что есть результаты работы каждый день, из дней состоит неделя, а из двух недель состоит спринт.

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

Приоритизация

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

Можно ранжировать задачи по полезности и экономическому эффекту (сколько заработает на этом твой продукт), можно использовать ICE/RICE-подходы. Например, скажу, что у меня эффективно работала оценка эффекта и масштаба использования (usage), т.е. если вы делаете то, что затронет 5% пользователей, то экономический эффект может быть небольшим.

Но есть обратный пример: эти пользователи могут быть сверхактивными в продукте (покупать в разы больше артефактов внутри игры), которые генерируют 40% выручки, или у них LTV (Life Time Value) больше среднего в пять-шесть раз. Тогда такая задача становится интереснее, и ее приоритет повышается.

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

Контроль этапов разработки

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

Так как Product Owner отвечает за месячные и квартальные OKR/KPI, то он видит, как по квартальному плану движется команда и какие эпики имеют шанс быть реализованными в рамках спринта, месяца, квартала.

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

Выработка продуктовой стратегии

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

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

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

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

Коммуникация

Коммуникация занимает как минимум 50% времени у любого владельца продукта. Нужно постоянно общаться с командой разработчиков, с дизайнерами, маркетологами и другими коллегами. Поэтому хорошо работают короткие циклы — встречи больше 30-45 минут большая редкость. Обычно хорошо укладываться в 15-30-минутные слоты и решать все вопросы оперативно. Множество чатов, множество коммуникаций. При этом нужно не забывать про аналитику, бэклог, похвалу и мотивацию разработчиков.

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

Впрочем, как с маркетингом, аналитиками, дата-сайентистами, топами. Наверное, это самый важный навык. Постоянные синки, встречи, убеждения, напоминания — без этого не обходится ни один час работы. Этим живет Product Owner каждый день.

Оценка прогресса

Product Owner постоянно оценивает прогресс работы над сервисам и функциями (фичами) в рамках спринта, это касается разработки. Назовем это треком #1. Также нужно оценивать бизнес показатели и метрики. Конверсии, темпы роста, ключевые метрики каждый день с прогнозом до конца месяца — это трек #2. На его основе понятно, как недельные результаты складываются в месячные и квартальные результаты.

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

Общее видение продукта

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

Дополнительно Product Owner должен сделать так, чтобы сформированное видение продукта стало общим. Чтобы видение, как и куда нужно развивать продукт, разделяли команда и руководство компании.

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

В чем отличие Product Owner от Product Manager

Многие считают, что это одно и тоже, но Product Owner — это владелец продукта. Он мыслит, как предприниматель, несет ответственность за то, что происходит с продуктом, куда он развивается.

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

Если Product Manager отвечает за часть воронки или часть метрик, например, конверсии или микроконверсии, например, из добавлено в корзину в транзакции, то Product Owner отвечает за финальный счет, который загорается на табло в конце каждого месяца.

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

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

Фото на обложке: Gorodenkoff / Shutterstock

Источник