кто такой продукт оунер

Кто такой 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 – кто это и что он делает?

Что ещё за product owner? Кто это? Очередной интернет-специалист с непонятными обязанностями?

Спокойно! Всё понятно и чётко. Сейчас разъясним.

Кто такой product owner?

В большинстве источников перевод на русский звучит как «владелец продукта», и это создаёт путаницу. Что такое продукт компании? Это то, за что покупатели платят деньги. К примеру, продуктом автосервиса будет ремонт автомобиля, а продуктом интернет-магазина – товары, которые там приобретут.

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

Чем занимается product owner?

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

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

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

Зачем нужен человек, который знает продукт?

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

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

Обязанности продакт-оунера

И, конечно, не стоит забывать о коммуникации между всеми важными действующими лицами – владельцем компании, командой разработчиков, рекламщиками, покупателями и т. д. Так что дел для специалиста product owner хватает с лихвой. Многие владельцы бизнеса о нём даже не знают. А ведь, возможно, именно в его отсутствии заключается проблема в раскруткой бренда и интернет-продвижением услуг компании.

Источник

Product Owner: что должен уметь?

Компания InfoShell написала для нас о компетенциях, которыми должен обладать руководитель проектов.

Product Owner (далее PO) – это необходимая роль в команде гибкой разработки digital-продукта. Гибкий подход (Agile) принципиально отличается от традиционного (waterfall). Здесь главная оценка – работающий продукт, промежуточный результат, а устные договоренности и потребности заказчика важнее, чем техническое задание.

PO – это человек, который управляет созданием продукта и отвечает за то, что получится в результате. Компетентный PO сочетает в себе роли бизнес-стратега, рыночного аналитика, продакт-дизайнера и клиента. Он распределяет зоны ответственности, постоянно мониторит, что происходит в индустрии, оценивает качество продукта и одновременно является его пользователем.

И ВСЕ-ТАКИ ЧТО ЖЕ НУЖНО PRODUCT OWNER-у?

Определять видение продукта

Видение продукта – это совместный результат работы PO и заказчика. Оно зависит от бизнес-целей, которые преследует клиент. PO на этом этапе предлагает ему те или иные фичи, опираясь на свой профессиональный бэкграунд, аналитику рынка и конкурентов, позиционирование продукта и его целевую аудиторию.

Чтобы проектная команда придерживалась установленного видения, РО составляет дорожную карту продукта (roadmap) – краткосрочный или долгосрочный план выполнения, изменения и развития проекта.

Составлять и управлять бэклогом продукта

Бэклог – это список фич и задач для разработчиков, который может меняться в зависимости от потребностей проекта. Изменять бэклог может как РО, так и разработчик.

Product Owner должен управлять бэклогом так, чтобы команда реализовала необходимые фичи раньше, чем остальные. Их приоритетность напрямую связана с бизнес-задачами заказчика и сроками проекта. Например, если разрабатываемый продукт должен быть запущен в течение 6 месяцев, PO должен определить, какие главные функции должен включать его MVP (minimum viable product) – минимально жизнеспособный продукт, и, исходя из этого, решить, какие фичи сделать первыми. Важно, чтобы эти фичи приносили доход продукту даже на ранних этапах запуска.

Описание работы фич также лежит на РО.

Создавать визуальные прототипы

Умение быстро создать приблизительный интерфейс приложения, сайта или веб-сервиса – еще один навык, необходимый для PO. Он должен смоделировать поведение пользователя и создать прототип в соответствии с ним. Для этого необходимы знания и опыт User Experience/User Interface (UX/UI).

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

Контролировать разработку на всех этапах

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

Вырабатывать продуктовую стратегию вместе с заказчиком

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

» data-image-caption=»» data-medium-file=»https://i0.wp.com/apptractor.ru/wp-content/uploads/2018/10/Product-Owner-1.jpg?fit=1024%2C723&ssl=1″ data-large-file=»https://i0.wp.com/apptractor.ru/wp-content/uploads/2018/10/Product-Owner-1.jpg?fit=740%2C523&ssl=1″ svg+xml,%3Csvg%20xmlns=’http://www.w3.org/2000/svg’%20viewBox=’0%200%20740%20523’%3E%3C/svg%3E» alt=»Product Owner» width=»740″ height=»523″ data-lazy-srcset=»https://i0.wp.com/apptractor.ru/wp-content/uploads/2018/10/Product-Owner-1.jpg?w=1400&ssl=1 1400w, https://i0.wp.com/apptractor.ru/wp-content/uploads/2018/10/Product-Owner-1.jpg?resize=640%2C452&ssl=1 640w, https://i0.wp.com/apptractor.ru/wp-content/uploads/2018/10/Product-Owner-1.jpg?resize=1024%2C723&ssl=1 1024w, https://i0.wp.com/apptractor.ru/wp-content/uploads/2018/10/Product-Owner-1.jpg?resize=768%2C543&ssl=1 768w» data-lazy-sizes=»(max-width: 740px) 100vw, 740px» data-recalc-dims=»1″ data-lazy-src=»https://i0.wp.com/apptractor.ru/wp-content/uploads/2018/10/Product-Owner-1.jpg?resize=740%2C523&ssl=1″ />

Разрабатывать модель монетизации

РО должен сделать так, чтобы продукт приносил доход. Необходимо уметь просчитывать юнит-экономику (заработок бизнеса с потока пользователей), чтобы продукт не приносил убытков, анализировать и улучшать LTV (LifeTime Value) – прибыль от одного пользователя за все время сотрудничества, а также общий Revenue (доход).

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

Эффективно общаться с заказчиком и командой разработки

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

Оценка прогресса продукта тоже входит в дело Product Owner-а

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

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

Для тех, кому лень читать, мы собрали все необходимые навыки PO, услышанные от Михаила Карпова, в таблицу.

Источник

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 раза и перезапустить продукт на нескольких платформах в «Сравни.ру».

Первая всероссийская премия в области AgroTech-решений. Участвуй сам или номинируй достойных!

Содержание:

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

Источник