Как выглядит ежедневная работа продакт-менеджера на самом деле? Как миссия по созданию востребованных продуктов раскладывается на конкретные задачи? Какие инструменты используются? Какие особенности характерны для работы над AI-продуктом?

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

Материал будет полезен:

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

Далее — рассказ от лица нашего автора.

***

Привет!

Меня зовут Роман Гаев, я продакт-менеджер в Toloka AI.

Сейчас я занимаюсь двумя направлениями из B2B-части нашего бизнеса: Product for GenAI и Overall Product Quality — то есть общее качество продукта, в том числе фидбек пользователей, интерфейсные боли и баги, блокеры ревенью для текущих клиентов.

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

Понедельник

10:00-12:00 — Планирование недели. Обычно я отсматриваю:

  • Статус по всем продуктовым трекам, которые у меня есть: насколько мы совпадаем с планом, что нужно успеть на этой неделе.
  • Ключевые задачи, на которых нужно сохранять фокус на этой неделе: например, то, что двигает треки высокого приоритета для продукта или бизнеса; time-sensitive вещи; важные релизы, которые должны оказаться в проде.
  • Встречи, которые происходят в течение недели: к каким из них и как нужно подготовиться? что должно произойти до этой встречи?

Инструменты: Jira, Notion, Google Calendar, Slack.

12:00-12:45 — Планирование команды разработки на неделю. На встрече присутствуют: я как Product Owner, лид фронтенда, лид бекэнда, разработчики, дизайнер, QA-инженеры.

  • Открываем kanban-доску и смотрим, что осталось с предыдущего спринта и сколько ресурса разработки освободилось.
  • Смотрим на роадмап: как идем, где отстаем.
  • Берем из бэклога команды самые приоритетные задачи и проверяем, что их описание понятно и не требует доработки. Затем свободный разработчик берет их в работу.
  • Чтобы фичу взяли в работу, она должна пройти refinement-встречу («реф»), на которой мы верхнеуровнево обсуждаем детали реализации с разработкой и описываем в тикете спецификацию и требования. После этого производим оценку по времени.
  • Если не успели доработать описание и постановку задачи, а задача срочная по приоритету, то берем в работу и проводим refinement-встречу, дополняем требования на отдельной встрече прямо во время спринта.

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

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

Развивайтесь в профессии продакт-менеджера с помощью GoPractice.

→ «Профессия: продакт-менеджер».

→ «Симулятор управления продуктом на основе данных».

→ «Симулятор управления ростом продукта».

→ «Симулятор SQL для продуктовой аналитики»

→ «Симулятор управления ML/AI-проектами».

→ Не знаете с чего начать? Пройдите бесплатный тест для оценки навыков управления продуктом и подпишитесь на телеграм-канал GoPractice.

Инструменты: Jira.

13:00-13:30 — Еженедельная регулярная встреча со смежной командой, которая отвечает за ресурcы разметчиков данных. Планируем загрузку ресурсов для одного из моих клиентов.

  • Параллельно в некоторых новых направлениях нашего бизнеса я выступаю как менеджер проекта и клиентский менеджер: я помогаю наладить процессы, запросить ресурсы, чтобы все сошлось для клиента. Заодно получаю опыт того, как работает это направление, «на кончиках пальцев». Пока что там нет сформированного продукта, но такие погружения помогают понять общие принципы, которые позволят затем построить продукт.

14:00-14:30 — Еженедельный one-on-one с тимлидом. Обсуждаем мою загруженность, что получается, что не получается, спрашиваю советы. Если есть конкретные топики, то обсуждаем их: например, квартальное планирование продукта.

14:30-16:00 — Подготовка ко встрече брейншторма продуктовых идей.

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

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

Инструменты: Miro.

16:00-17:00 — Одна из регулярок с клиентом: погружение в разметку текстовых промптов и ответов на них. Наш продукт позволяет создавать данные высокого качества для обучения Generative AI (например, чатботы, большие языковые модели). В таком домене очень сложно понять и выделить критерии того, что действительно является хорошим ответом на вопрос и как контролировать это качество на больших объемах. Поэтому мы постоянно погружаемся в тексты, написанные нашими экспертами:

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

17:00-17:30 — Встреча о разметке данных, содержащих код: как улучшить текущий процесс.

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

17:30-18:00 — One-on-one с ресерч-инженером по мотивам встречи с клиентом.

  • Обсуждаем результаты встречи.
  • Я уточняю некоторые детали, которые не успели обсудить на встрече.

18:00-19:00 — Пишу фоллоуапы по встречам в каналы, устаканиваю в голове новую информацию.

Инструменты: Slack

Вторник

10:00-11:00 — Фокусное время (то есть время без встреч и коммуникаций в мессенджерах): разбор роадмапа на Q4, заполнение описания тикетов: что ожидаем увидеть, когда и в какой форме.

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

11:00-11:30 — Еженедельная one-on-one с лидом смежной команды по поводу их продукта оценки качества разметки.

Зачем? Хотим переиспользовать их проект на клиентах нового направления. Для них это выгодно, поскольку они получат фидбек по продукту от реальных клиентов.

11:30-12:30 — Дважды в неделю one-on-one с лидером цели, в которой я отвечаю за продуктовую часть.

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

13:30-15:30 — Фокусное время. Проходился еще раз по видению процессов, которые строим в новом продуктовом направлении. Смотрю, как это вяжется с картиной текущего продукта, как это может объединиться, какие проблемы могут возникнуть. Часто в таких случаях люблю порисовать в Miro.

Инструменты: письменные заметки, Miro.

15:30-16:00 — Обмен опытом между нашей и смежной командой: команды supply-экспертов для разметки. Мы часто пересекаемся: эксперты используют наш B2C-продукт для разметки, а наш продукт для B2B плохо работает, если плохо работают эксперты.

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

16:00-19:00 — Фокусное время.

19:30-20:00 — Участие в звонке с новым клиентом. Фасилитирует звонок и ведет клиента, как правило, один из sales-менеджеров. Также участвует sales engineer, который будет помогать клиенту интегрировать продукт в его процессы.

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

От продуктового менеджера на таком созвоне требуется увидеть:

а) текущие боли клиента и вернуться с планом их лечения;

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

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

Среда

9:00-12:00 — Разбираю результаты брейншторма со стейкхолдерами направления одного из типов разметки данных. Рисую и анализирую сквозной сценарий клиента. Разбираю список болей по сценарию, думаю над возможными решениями. Хочется увидеть картинку целиком, а не обрывочными фич-реквестами и блокерами.

Инструмент: Miro

12:00-13:00 — Регулярка смежного продуктового направления — B2C-продукта — с участием их стейкхолдеров и с привлечением экспертов разметки данных. Смотрим на бэклог и текущие приоритеты, на новые проблемы, челленджим приоритеты. Я тут выступаю тоже стейкхолдером: мое направление в каком-то смысле тоже заказчик и к тем, и к другим.

13:00-15:30 — Коммуникация по текущим задачам в тикетах, в Slack.

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

В тикетах в Jira обычно оставляем конечные решения/вехи/статусы, Slack — более свободная коммуникация и холивары.

Инструменты: Jira, Slack.

15:30-16:00 — Обсуждение инструментов для экспертов по кодингу с менеджером разметчиков: каких инструментов не хватает в продукте, чтобы этим экспертам было удобно решать задачки по кодингу.

16:00-17:00 — Sales-инженеры представили новый процесс заказа экспертов разметки. Sales-инженеры помогают клиенту настроить продукт, а эксперты, собственно, выполняют разметку внутри продукта. Процесс должен быть быстрый, понятный и должен включать нужные критерии для отбора правильных экспертов.

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

17:00-18:00 — Созвоны с командой инженеров по реализации проектов. Как я говорил, я веду несколько клиентов нового направления как проджект, чтобы вникнуть в требования к продукту. Это внутренний синк с нашими инженерами, где мы обсуждаем детали реализации, пересечение между проектами.

Четверг

10:00-10:30 — Подготовка к продуктовому демо команды. Для это необходимо:

  • подготовить драфт презентации;
  • составить адженду по командам;
  • добавить релизы из своей команды.

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

Немного про коммуникации внутри команды.

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

Они должны:

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

10:30-11:00 — Refinement фичи с командой разработки.

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

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

Участвуют: продакт, тимлид фронтэнда, разработчик фронтэнда.

11:00-11:30 — Фокусное время: ревью статусов open-source проектов.

Еженедельное ревью по нескольким сайд-проектам, которые мы делаем, чтобы выложить в open-source. Такие проекты делаются для показания уровня экспертизы в среде и последующего привлечения потенциальных заказчиков. Что делаю: проверка прогресса, пинг ответственных, помощь с менеджментом задач и людей.

11:30-12:30 — Фокусное время: отсмотр кастдев-интервью с клиентами

Наш специалист в Customer Research поделилась записями интервью с компаниями рынка GenAI. Отсматриваю, выписываю инсайты, новые гипотезы, задачи: с кем поговорить и как эти гипотезы проверять.

12:30-13:00 — Фокусное время: отсмотр багов, проставление продуктовых приоритетов.

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

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

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

Сейчас мы сошлись на более простой системе приоритетов, где учитывается:

  • Продуктовая критичность: как баг влияет на ожидаемое поведение продукта.
  • Бизнесовая критичность (более важная): как баг влияет на бизнес и верхнеуровневые цели компании.

Иногда в продукте встречаются мелкие вещи, которые могут сильно повлиять на бизнес — и наоборот

13:00-15:00 — Ad hoc проблема/запрос от клиента.

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

15:00-15:30 — One-on-one с продактом направления инфраструктуры.

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

15:30-16:00 — One-on-one с Head of Research. Обсуждаем текущий проект в направлении GenAI:

  • целеполагание;
  • текущие приоритеты;
  • вовлечение его команды на этом проекте.

16:00-17:00 — Продуктовое демо всех команд. Про демо я уже рассказывал выше. Как правило, я фасилитирую встречу и рассказываю про релизы своего направления.

17:00-18:00 — Квартальный kick-off направления по GenAI и обсуждение.

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

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

18:00-19:00 — Фокусное время: разбор почты/Slack.

Пятница

10:00-10:30 — Проверка сообщений и почты на срочное/важное/пожары, составление плана на день.

10:30-11:00 — Сбор результатов команды за неделю и мой отчет в формате поста — для более широкой команды. Это важно, чтобы держать их в курсе изменений в продукте, иногда получить фидбек по багам и предложения. Большая часть подобных «статусных» коммуникаций должна всегда закрываться офлайн, чтобы минимизировать количество встреч. Это и release notes, и статусы прогресса по проектам, и другая односторонняя коммуникация в стиле “for your information”.

Инструменты: Jira для сбора задач, отсмотра релизов и Slack для коммуникации.

11:00-11:30 — Refinement фичи с командой разработки: senior-разработчики помогают оценить и декомпозировать задачу junior-разработчику.

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

  • Брейнштормим различные варианты реализации: с разной степенью вовлечения frontend/backend-разработки.
  • Оцениваем задачу. Если достаточно разработчиков — 3 и более, — то пользуемся системой покер планирования. В данный момент мы оцениваем не в сторипоинтах, а в днях/неделях FTE (Full time equivalent, то есть работа одного человека полный рабочий день) разработчика. Я считаю, что сторипоинты имеют смысл тогда, когда вы достаточно долго работаете командой в одном составе и задачи плюс-минус взаимозаменяемы. Тогда оценку можно проецировать на любого человека из команды и ожидать одинакового срока.

Инструменты: Zoom, Jira, Miro.

11:30-12:00 — Встреча с лидом sales engineers по ресурсам его команды на проект.

  • Зачем? Важно, чтобы дедлайны и ожидания были реалистичными относительно ресурсов, которые выделены. После первых нескольких недель стало понятно, что выделенного инженера не хватает.
  • Вместе с техлидом подискутировали, где новые люди действительно помогут, с каких других менее приоритетных задач в компании их можно снять, обсудили наём новых.
  • Иногда ресурсы — это не блокер. Какие-то задачи можно запараллелить и просто залить туда больше ресурсов. Но иногда задачи связаны, и их результат блокирует друг друга.

Инструменты: Zoom, Jira, Miro

12:00-13:00 — Коммуникация в Slack, ответы на упоминания.

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

13:00-13:30 — Hands-on погружение в проект по сбору данных для LLM.

  • Зачем? Я считаю, что менеджеру важно на кончиках пальцев понимать, как происходит низкоуровневая работа. Это дает больше контекста для принятия решений.
  • Что делаем? С инженерами сбора данных, менеджерами, ресерчерами отсматриваем реальные данные, реплики, собранные для LLM. Пишем комментарии, выделяем, что идет хорошо или плохо, в конце встречи определяем следующие шаги.

13:30-14:00 — Обсуждали со смежниками интеграцию новых моделей в их библиотеку, которую мы используем. Договорились о сроках, о конкретной необходимой модели, как мы будем стучаться в API и какой на нашей стороне будет флоу дальше.

14:00-14:30 — Обсуждаем прогресс по воронке найма и перфомансу уже существующих экспертов разметки.

15:00-16:00 — All hands, то есть общая встреча компании. Делимся новостями мира AI, важными объявлениями, инсайтами, которые достойны быть рассказанным на всех.

16:00-17:00 — Продуктовая встреча по обмену опытом. Раз в две недели мы берем какой-нибудь ресурс на обучение, например статью или видео YouTube. Потом делимся впечатлениями, обсуждаем, думаем, как это можно применить в нашем продукте. Сейчас мы обсуждаем процессы создания больших языковых моделей и то, какие продуктовые фичи там нужны, как мы можем помочь компаниям.

17:00-19:00 — Коммуникация в Slack и тикетах, доработка текущего бэклога по проектам, описание спецификации тикетов на следующую неделю/спринт. Перед планированием команды разработки на следующей неделе нужно внести максимум деталей в задачи, которые мы ставим. Это необходимо, чтобы избежать лагов в коммуникации и результата, который не соответствует ожиданиям из-за неточной постановки задачи.

На этом все!

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

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

И если у вас остались вопросы, можно написать мне на эту почту — Roman.alex.gaev@gmail.com.

Автор иллюстрации к материалу — Анна Гольде