Колонки

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 — кто это такой и чем занимается?
Присоединиться

Содержание:

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: советы изнутри профессии

Кто такой продакт и как им стать?

Продакт-менеджер: чем занимается, сколько получает, как им стать

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

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

Нашли опечатку? Выделите текст и нажмите Ctrl + Enter

Материалы по теме

  1. 1 Как организовать корпоративное обучение — гайд
  2. 2 Что включает в себя фонд оплаты труда и как рассчитывается
  3. 3 Попали под сокращение? Вот как обновить профиль в LinkedIn, чтобы не отпугнуть рекрутеров
  4. 4 Эффективность адаптации нельзя измерить. Какие мифы мешают грамотному онбордингу
  5. 5 Как поддержать сотрудников с тревожно-депрессивными расстройствами