Кто такой stand 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-методологиям. Разбираться в маркетинге, юзабилити, разработке и управлении, а главное — понимать жизненный цикл продукта.

Источник

Как превратить 15 минут Scrum-собрания в ежедневный аншлаг?

Ежедневное собрание в Scrum-команде должно помочь собственнику продукта оптимизировать разработку и готовить продукт или сервис к релизу в срок и без оплошностей. Это красивая теория. На практике — Scrum meeting может быстро превратиться из эффективной короткой встречи в никому не понятную рутину. Как обеспечить команде полезную ежедневную встречу и не превратить ее в “обязаловку”?

Собрание в Scrum (или Scrum Stand Up) — плановая встреча, которая помогает продуктовым группам быть более эффективными и актуализировать ежедневные процессы. Рекомендуется, чтобы митинг не продолжался более 15 минут. Помимо product owner и Scrum master во встрече также участвуют другие члены команды.

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

Формат проведения Scrum meeting не предполагает наличия стола и стульев. Все происходит стоя, чтобы не “растягивать” встречу на продолжительное время. Если некоторые вопросы требуют дополнительного внимания, они могут обсуждаться теми, кто вовлечен, после собрания.

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

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

8 простых советов для организации эффективного Scrum-собрания

Определите формат митинга

В Agile-контексте ежедневный Stand up происходит в течение спринта, который является периодом работы в 2-4 недели. Во время спринта определяется набор фич и требований из бэклога для новой итерации.

Важная задача — четко определить временные рамки встречи, и помнить, что ежедневный Stand Up отличается от других встреч (например от retrospective meeting).

Пригласите команду и определите участников встречи

Лучшее решение для Scrum-собрания — это 8-12 человек, заинтересованных в обсуждении. Это упрощает коммуникацию и не затягивает встречу. На собрании рекомендуется присутствовать трем основным заинтересованным сторонам, которые выполняют главные роли в Scrum-команде:

Разберитесь с местом и временем

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

Эксперты советуют проводить ежедневный Scrum митинг в одно и то же время каждый день. Лучше это сделать в начале дня — тогда у всех будет четкое представление о том, чему будет посвящен день.

Если у вас есть удаленные члены команды, заранее убедитесь, что они уведомлены о собрании и смогут участвовать. Во многих компаниях для работы с распределенными сотрудниками используются специальные удобные сервисы. Один из них — Standuply. Инструмент помогает проводить собрания или опросы в Slack, а потом отправлять результаты в таск-трекер.

Стоя, зато быстро

Многие согласятся, что собрание стоя не будет затягиваться никем. Кроме того, это помогает сфокусировать внимание на самом главном.

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

Соблюдайте повестку дня

Ежедневное собрание в Scrum должно быть основано на трех основных вопросах, на которые должен ответить каждый член команды:

Не забудьте делать пометки и расшарить их, чтобы все были в курсе и своевременно реагировали.

Упростите процесс

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

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

Сотрудничайте и коммуницируйте

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

Избегайте типичных ошибок

К наиболее частым ошибкам при проведении Scrum-митинга отнесем следующие:

А какие ваши секреты проведения собрания в Scrum-команде?

Источник

Product owner в банке – кто это и что он умеет

Продакт оунер. Владелец продукта. Продуктолог. PO.

Должность, которую часто считают синонимом «Менеджера проекта», благо ряд задач и обязанностей довольно схожи.

О том, кто такой продакт в понимании Альфа-Банка, что это за человек, что он умеет делать и как относится к своей команде, нам рассказал VDavydov Владимир Давыдов, руководитель по развитию цифровых каналов и продуктов Блока “Массовый бизнес”

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

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

Вот кто такой продакт и какими компетенциями он должен обладать:

Качества продакта

Профессиональные навыки и умения product owner’a тесно связаны с циклом создания продукта.

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

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

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

— Формирование и проверка гипотезы. Логичным итогом какого-либо исследования является набор продуктовых гипотез. А что надо делать с гипотезами? Правильно – проверять. Быстро, с пониманием критериев успеха. Чтобы что-то сделать хорошо, надо знать, что именно ты вообще делаешь, и каковы критерии этого «Хорошо». Если гипотеза подтвердила свою состоятельность, нужно суметь быстро довести ее до ума.

— Работа с командой. Создание продукта. Мы тут все agile-евангелисты и выбрали для себя фреймворк скрама как, на наш взгляд, самую эффективную методологию, позволяющую быстро доставлять ценность до потребителей. Поэтому у нас достаточно стандартный набор артефактов — dsm, pbr, sprint planing, demo, retro…

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

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

— Стейкхолдер-менеджмент. Стейкхолдер – это любой человек в банке, кто может оказать влияние на твой продукт. От ТОП-менеджера до сотрудника, осуществляющего сопровождение. По этому пункту можно отдельную статью написать 🙂 Главное правило – разделите стейкхолдеров на кластеры, сформируйте у каждой группы ожидания, а потом управляйте ими. Управляйте на постоянной основе.

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

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

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

Ответственность продакта

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

Сейчас мы пропагандируем именно такой подход — это очередной виток эволюции. Мы прошли довольно большой путь в формировании продуктового института (Альфа-Банк первым в России начал применять гибкие методологии разработки Agile, прим. редакции).

Цифра VS Банк

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

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

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

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

Это вопрос ответственности.

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

Если клиент не нашел какую-то кнопку (или она неудобно расположена) — это проблема дизайнера, его зона ответственности.

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

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

Черный список качеств

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

— Отношение к своей команде как к рабочей силе, как к ресурсу

Продакты в Альфа-Банке — люди, формирующие каждый свою команду спецназа. Команду людей, где каждый готов прикрыть друг друга. Это именно команда, а не шестеренки в механизме.

— Не видит разницы между лидером и руководителем

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

— Не разделяет рабочую культуру

Это важно. Мы стараемся подбирать людей так, чтобы уровень рабочей культуры у них был примерно один. Чтобы им было комфортно работать друг с другом. Если тебе дискомфортно работать с коллегами, общаться с ними и вообще приходить в офис — работать будет, прямо скажем, сложно.

— Отсутствие логического мышления

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

Продакты в Альфе

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

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

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

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

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

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

Но завтра таких человек может стать 20. Мы большой банк, у нас много продуктов и мы всегда смотрим в будущее. Вакансии 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 раза и перезапустить продукт на нескольких платформах в «Сравни.ру».

Содержание:

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

Источник