Большинство продуктовых команд — не продуктовые команды

Статей сегодня великое множество, довольно сложно найти классный материал, который будет полезен. Сегодня я поделюсь переводом своей любимой статьи Марти Кэгана, основателя Silicon Valley Product Group, от 2019 года.

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

Речь идет о типах (или ролях) продуктовой команды в технологических компаниях. Кого действительно можно назвать продуктовой командой?

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

Первые, так называемые delivery teams, которые часто называются командами разработки, скрам-командами или командами инженеров. Если вы работаете по SAFe, то вы в этом списке. Состав команды насчитывает некоторое число разработчиков и продакт owner’а.

Такие ребята вряд ли представляют из себя продуктовую команду (отдельная статья автора об этом), так как их основная деятельность крутится вокруг output delivery. Разработка сильного высокотехнологичного продукт – это не про них.

Что же отличает реальную продуктовую команду от всех к остальных? Во-первых, их кросс-функциональность (продукт, дизайн, разработка); во-вторых, их деятельность оценивается с помощью конечных показателей (outcome), не промежуточных (output); в-третьих, у них есть ресурсы на поиск решения заданной проблемы.

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

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

Третий тип команд – это фиче-команды. Такие команды ориентированы на промежуточных результат (output): фичи или проекты, которые предоставляются команде в виде списка приоритетов (по-другому, roadmap).

Есть 4 атрибута продукта (и сопровождаемые их риски):

— Ценность. Будут ли пользователи использовать продукт?

— Юзабилити. Смогут ли пользователи понять, как пользоваться продуктом?

— Осуществимость. Сможем ли мы осуществить желаемое с учетом нашего времени, навыков и денег?

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

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

В фиче-команде все еще есть дизайнер, который отвечает за юзабилити, разработчик – за осуществимость. Но ценности и жизнеспособность бизнеса – это ответственность стейкхолдеров или руководителя, который попросил добавить фичу в роадмэп. Если они говорят, что нужно создать функцию x, то они считают, что 1) функция x принесет некоторую ценность 2) функция x является жизнеспособной для бизнеса.

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

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

В фиче-команде эти знания распределены между стейкхолдерами.

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

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

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

А если дизайнер продукта все-таки есть, то зачем нужен продакт?

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

Итак, продакт менеджер – тот, кто рассматривается как потенциальный лидер компании, сильный игрок и двигатель прогресса – это продакт в продуктовой команде, не в фиче-команде.

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

— Что у вас на руках — заданная проблема и представленная команда или заданный роадмэп и дэдлайны?

— Смешиваются ли роли продакта и дизайнера в вашей команде?

—Смешиваются ли роли продакта и разработчика в вашей команде?

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

—Использовали ли вы OKR в вашей деятельности? Как это было?

—Часто ли вы отчитываетесь перед кем-то?

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