Для чего нам продакт-менеджер в аутсорс-компании

Почему аутсорс-команда не хочет вникать в продукт и думать как сделать его лучше? Поможет ли эту проблему решить продакт-менеджер? Делюсь нашим опытом в этом вопросе

Всем привет! Я Дима, сооснователь агентсва продуктовой разработки along. pw.

Мы создаем и развиваем новые IT продукты для предпринимателей. Умеем за месяц сделать мобильное приложение, в котором можно делать продажи подписок. Без no-code и fake door testing, только реальные масштабируемые продукты.

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

Разговор сегодня пойдет именно про запуск стартапов и новых продуктов на аутсорсе.

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

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

Почему он нужен в аутсорс проектах

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

Продакт может принести проработанную фичу с готовым дизайном, органично вписанную в бэклог продукта с правильным приоритетом. Но финальный «ок, работаем» мы в любом случае должны получить от клиента.

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

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

Разница между продактом и проджектом

Если говорить в двух словах, то продакт принимает решение о том, что мы делаем, а проджект решает есть ли на это сейчас ресурсы.

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

Почему у нас это два разных человека

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

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

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

Бэклог

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

Для ведения бэклога мы используем гугл-таблицу, в которой выделяется:

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

Роадмап

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

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

Согласование приоритетов

Это еженедельный звонок с клиентом, на котором мы:

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

Если мы понимаем, что на ближайшие две недели у нас уже не хватает фичей:

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

Грумминг

Напоследок оставил самое интересное) В типичном аутсорсе есть бизнес-аналитик, который описывает требования для команды и делает постановки задач. В нашем же случае описание фич так же берет на себя продакт-менеджер. Почему? Напоминаю, что продукт мы создаем с нуля, а значит при проработке любой фичи есть момент “придумывания”. То есть выбор варианта реализации фичи. Конечно, придумать может фаундер, а аналитик переложить это на требования к разработке. Но! Как я писал выше — мы стараемся максимально не вовлекать основателя в операционку по продукту, поэтому берем на себя это “придумывание”. А результат уже согласуем с фаундером и после его согласования пускаем в работу.

Формат работы по требованиям выглядит так:

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

В результате получается непрерывный процесс описания концепции, проработки данной концепции, реализации фичи, публикации, измерения эффективности обновления, повторение)

1. Получилось снять часть операционки по продукту с фаундера стартапа. Конечно, все ключевые решения все равно должен принимать основатель, он должен быть в курсе всего что происходит и контролировать ситуацию. В конечном счете мы просто исполнители, а все более менее значимые решения принимает клиент. Но мы стараемся быть полезными в принятии этих решений.
2. Сняли операционку с фаундеров самой студии) Да, как ни странно, роль продакта была у нас всегда, просто выполнял ее один из основателей студии — я или мой партер Дима. Сейчас благодаря выделенным людям мы можем больше фокусироваться на более глобальных вещах. Ну и статьи начали писать, как видите)
   
3. Больше опираемся на данные при принятии решений. Благодаря экспертизе продакта мы реально начали использовать данные, которые собираем с метрик. На их основе получается генерировать больше гипотез, которые взяты не “с неба”, а с реальных данных.
   

1. Пока не сформировался четкий шаблон питча, с которым продакт приходит к команде на грумминг. Сложно определить минимальнодостаточный объем информации, который нужно подготовить, да еще он меняется от фичи к фиче. Поэтому сейчас мы в процессе определения нормы и формата.
2. Скорее всего будем пробовать новую систему приоритезации бэклога. Сейчас она делается на основе экспертности клиента, а продакт помогает нужными данными. Хочется добавить количественное измерение для более качественной приоритезации. Сейчас смотрим в сторону RICE.
   

Интересно узнать опыт аудитории виси — сталкивались ли вы с проблемой “просто исполнителей” при работе с аутсорсом? Когда исполнитель ожидает готовый список задач, не вовлекается в продукт и не действует исходя из пользы для него. Как считаете — наличие продакт-менеджера в команде поможет решить данную проблему?