Построение продуктового офиса

Построение продуктового офиса в B2B

Предпосылки

Часто в крупных компаниях продукты могут вырастать “сами по себе”, из прямых требований стейкхолдеров, оперативной обстановки бизнеса, или повторения за конкурентами. Бизнес диктует что делать и ожидает конкретные сроки по конкретным задачам. В таких случаях принято говорить, что продукт развивается согласно проектному подходу.

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

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

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

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

См. отличие проектного подхода от продуктового

Продуктовый офис

Продуктовый офис - это функция, которая масштабирует продуктовый подход в компании.

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

Продуктовый подход предполагает работу в 3 направлениях:

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

Практики

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

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

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

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

Практики определяют как будет выглядеть процесс Discovery команды.

Методология и артефакты

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

Lean Startup, Agile, Design Thinking, Customer Development, Working Backwards, Continuous Discovery, Shape Up, OKR, etc. А все ли перечисленное является методологией? Есть же еще методы и фреймворки- JTBD, North Star, Shape Up. А что-то может быть одновременно и методологией, и методом, в зависимости от контекста. А какие-то методы, применимые в одной области, могли перекочевать в другую, как, например, HADI из Growth любит появиться в Agile Discovery. Customer Development же в легкую может упроститься до Customer Interview. А так ли это все, или это только мнение?

См. создание продуктового фреймворка за 2 минуты

Наша задача не определить методологию, в которой мы работаем, а явно формализовать наш подход к работе для команды

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

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

Артефакты должны экономить время, а не отнимать

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

• Стратегия продукта
• Roadmap
• BRD/URD/PRD
• One-pager
• Release notes

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

Примеры вопросов, на которые мы должны ответить с помощью методологии и артефактов:

• кто потребитель этого документа?
• какие артефакты должны быть унифицированы?
• в каком формате мы описываем BRD?
• какой формат Release notes?
• как мы оцениваем рынок?
• как мы описываем гипотезы?

Процессы

Процесс - это следствие формализации внеплановой повторяющейся деятельности в плановую.

Алгоритм, который был формализован для упрощения жизни команд, чтобы “не думать заново”.

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

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

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

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

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

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

Ролевая модель и карьерный фреймворк

Ролевая модель - это формализованное описание ролей, их ответственности и полномочий в принятии решений.

Чаще всего, ролевая модель представлена в форме RACI/DRI, а описание отдельных ролей вынесены в должностные инструкции.

Ролевая модель нужна, чтобы:

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

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

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

См. Пример должностной инструкции

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

Внедрение новой ролевой модели - это переход от AS IS к TO BE. И не всегда этот переход может быть простым, особенно если кто-то привык работать в определенных рамках. Найдите способ сделать этот переход с минимальными сопротивлениями.

Другой важный элемент - карьерный фреймворк.

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

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

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

См. Пример матрицы компетенций

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

См. Пример ИПР

Культура

Формализовать методологию, процессы и роли - это просто. Сложно - внедрить это.

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

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

Ключ к решению этой ситуации - регулярность и терпение.

Обучение

Любым нововведениям нужно обучать, даже если они понятны и очевидны.

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

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

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

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

Сообщество

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

Создайте групповой чат, проводите Q&A собрания, позволяйте другим вносить предложения, задавать вопросы и спорить, обсуждать изменения между собой.

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

Мероприятия

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

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

Система

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

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

На этом этапе мы должны сделать так, чтобы все наши результаты стали:

• предсказуемыми
• измеримыми
• доступными

Ритмы

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

Ритмы проще всего задать основываясь на периодичности, примеры ритмов:

• Weekly
  • Status Sync - статус текущих гипотез/исследований, рисков, метрик
• Biweekly
  • Sprint Planning - приоритизация на 2 недели
  • Product Review / Demo - что доставили, что изменилось в метриках/поведении, обратная связь
  • Retro - как улучшить процесс, качество, взаимодействие, скорость цикла.
• Monthly
  • Roadmap Sync - синхронизация с роадмапом, корректировка планов
  • Tech/Product Health Review - техдолг/качество/производительность.
• Quarterly
  • OKR Review - оценка результатов квартала, обновление целей и ключевых результатов.
  • QBR - командное мероприятие с докладами по результатам работ
• Квартальное межкомандное планирование - синхронизация зависимостей с другими командами/платформой, договоренности по планам

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

Метрики

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

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

Сколько мы тестировали гипотез ранее? Какая была пропускная способность команд? Сколько мы стали экономить на работе, которую более не делаем? И другие:

• adoption, доля команд, использующих шаблоны/ритмы
• cycle time / lead time
• качество discovery - доля инициатив с явной гипотезой + метрикой

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