Статей сегодня великое множество, довольно сложно найти классный материал, который будет полезен. Сегодня я поделюсь переводом своей любимой статьи Марти Кэгана, основателя Silicon Valley Product Group, от 2019 года.
Возможно, статья уже есть здесь, но совсем не грех дублировать полезную информацию.
Речь идет о типах (или ролях) продуктовой команды в технологических компаниях. Кого действительно можно назвать продуктовой командой?
Автор аккуратно излагает свои мысли, предупреждает о «нестандартной классификации» и понимает, что может задеть нежные чувства верящих в свой продукт. 😅
Первые, так называемые delivery teams, которые часто называются командами разработки, скрам-командами или командами инженеров. Если вы работаете по SAFe, то вы в этом списке. Состав команды насчитывает некоторое число разработчиков и продакт owner’а.
Такие ребята вряд ли представляют из себя продуктовую команду (отдельная статья автора об этом), так как их основная деятельность крутится вокруг output delivery. Разработка сильного высокотехнологичного продукт – это не про них.
Что же отличает реальную продуктовую команду от всех к остальных? Во-первых, их кросс-функциональность (продукт, дизайн, разработка); во-вторых, их деятельность оценивается с помощью конечных показателей (outcome), не промежуточных (output); в-третьих, у них есть ресурсы на поиск решения заданной проблемы.
В этом смысле цель продуктовой команды – решать проблемы теми способами, которые нравятся клиентам их продукта, и в то же время поддерживать бизнес.
В таком случае получается, что лишь небольшой процент команд являются продуктовыми командами. Чаще всего команды вовсе не имеют полномочий и «служат» бизнесу.
Третий тип команд – это фиче-команды. Такие команды ориентированы на промежуточных результат (output): фичи или проекты, которые предоставляются команде в виде списка приоритетов (по-другому, roadmap).
Отличия продуктовой команды от фиче-команды
Риски
Есть 4 атрибута продукта (и сопровождаемые их риски):
— Ценность. Будут ли пользователи использовать продукт?
— Юзабилити. Смогут ли пользователи понять, как пользоваться продуктом?
— Осуществимость. Сможем ли мы осуществить желаемое с учетом нашего времени, навыков и денег?
— Жизнеспособность бизнеса. Риск жизнеспособности бизнеса оценивается с точки зрения возможности продукта выйти на тот или иной рынок или канал продаж; возможности работать в рамках правовых норм и контрактов; соответствия продукта обещаниям бренда и др.
В продуктовой команде продакт несет ответственность за ценности и жизнеспособность продукта, дизайнер – за юзабилити, разработчик – за осуществимость. Команда работает, активно сотрудничая, отдавая и принимая фидбэк, принимая решение, которое будет выгодно для всех.
В фиче-команде все еще есть дизайнер, который отвечает за юзабилити, разработчик – за осуществимость. Но ценности и жизнеспособность бизнеса – это ответственность стейкхолдеров или руководителя, который попросил добавить фичу в роадмэп. Если они говорят, что нужно создать функцию x, то они считают, что 1) функция x принесет некоторую ценность 2) функция x является жизнеспособной для бизнеса.
И даже если, казалось бы, они несут ответственность за ценность и жизнеспособность, они все равно могут найти способ обвинить команду в том случае, если не будут довольны результатами.
Роль продакта
В продуктовой команде диапазон полномочий продакта широк – он должен обеспечивать ценность и жизнеспособность продукта, иметь глубокое понимание о клиенте, данных и индустрии, в которой существует его продукт.
В фиче-команде эти знания распределены между стейкхолдерами.
Роль продакта в фиче-команде обычно сводиться к роли фасилитатора (ну или к роли слабого кросс-функционального лидера), который на самом деле не несет ответственность за продукт.
Часто фиче-команды думают, что они занимаются разработкой продукта, однако их деятельность сводиться к разработке дизайна и тестированию юзабилити.
Из-за того, что у команды нет как таковых полномочий, очень трудно привлечь и удержать истинных дизайнеров продукта. В подавляющем числе случаев дизайнер в фиче-команде – это графический дизайнер, а не продуктовый. Дело не в том, что визуальный дизайн не важен, дело в том, что у графических дизайнеров нет опыта в интерактивном дизайне и UX. На этой почве давление испытывает именно продакт, пытаясь заполнить пробелы. К сожалению, многие продакты и вовсе не сталкивались с возможностью поработать с настоящими дизайнерами продукта, поэтому они не знают, чего им не хватает.
А если дизайнер продукта все-таки есть, то зачем нужен продакт?
В результате мы видим, что в фиче-командах роль продакт мендежера – это роль проджекта и частично дизайнера.
Итак, продакт менеджер – тот, кто рассматривается как потенциальный лидер компании, сильный игрок и двигатель прогресса – это продакт в продуктовой команде, не в фиче-команде.
Дело в том, что люди, как правило, неохотно признаются в том, что они работают в фиче-команде. Вот несколько тест-вопросов, которые помогут это выяснить:
— Что у вас на руках — заданная проблема и представленная команда или заданный роадмэп и дэдлайны?
— Смешиваются ли роли продакта и дизайнера в вашей команде?
—Смешиваются ли роли продакта и разработчика в вашей команде?
—Вы проводите большую часть дня, занимаясь управлением проектами?
—Использовали ли вы OKR в вашей деятельности? Как это было?
—Часто ли вы отчитываетесь перед кем-то?
Хотя продуктовые команды и фиче-команды внешне выглядят одинаково, внутренне они кардинально отличны друг от друга по механизму работы, по уровню полномочий и подотчетности и по работе продакта.