Лидеры продукта - Нейт Уокингшо

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

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

Задача лидера продукта — в умении вести за собой команду к четко сформулированной цели. Он отвечает за всю рабочую обстановку — от проблем и разочарований клиентов до конкуренции внутри компании. По крайней мере, именно об этом мы рассказываем в книге.

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

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

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

ПОДБОР КОМАНДЫ ПРОДУКТА

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

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

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

TransferWise создала полностью автономную продуктовую команду с четкими KPI (ключевыми показателями эффективности деятельности)[12], но полной свободой в создании роадмапа, разработке организационной структуры, выборе команд и ресурсов, необходимых для выполнения плана. Любая команда вправе изменить любую часть продукта. Например, маркетологам не нужно ждать реализации продукта для выполнения своей части работы; у них есть полный доступ к созданию страниц, изменению потока пользователей и всего, что им необходимо для достижения цели.

В Pluralsight команды полностью автономны, кроссфункциональны и работают вместе. Команда не начинает работу, пока не наберется нужный состав. Каждая команда самостоятельно разрабатывает, реализует и полностью контролирует свой опыт и опыт пользователя (илл. 3–2).

Иллюстрация 3–2. Дэвид Платт (слева) проводит тест предпочтений пользователя для обучающего опыта Plurasight

В условиях такой автономии Spotify разработала одну из своих известных моделей. Они начали с «отрядов» — совместно работающих независимых команд со всеми навыками и инструментами дизайна, разработки и реализации своей части продукта.

Каждый отряд самоорганизуется и выбирает свой подход. Одни пользуются спринтами Scrum, другие — Kanban, а третьи — их смесью. Отряды группируются в «племена», работающие над родственными сферами продукта, но им не позволяется превышать число Данбара[13]. Чтобы координировать функциональные наработанные методы (например, дизайн) во всех командах, вводятся «отделы» и «гильдии» для обмена знаниями и опытом между «отрядами» и «племенами».

Как ее ни опиши, но именно маленькая, автономная, кроссфункциональная команда, приближенная к клиенту, все чаще становится важным фактором успешного лидерства. В этом мире ничто не идеально, излишняя автономия грозит эффектом масштаба[14] и представляет сложность для взаимозависимости и согласованности команд. Однако почти все эксперты, с которыми мы общались, крайне лестно отзывались об этой идее. Это ключевое, компромиссное решение, которое сохраняет центральную роль пользователя в разработке качественного продукта, а задача координации из внешней становится внутренней. Автономия — более предпочтительная система мотивации, чем старый метод кнута и пряника, а структура команды масштабируется проще, чем при любой нисходящей модели. В сегодняшнем быстро развивающемся мире у команды больше информации, опыта и знаний о проблемах пользователей и конкретной сфере работы над продуктом, чем когда-либо будет у вас. Спрашивается, зачем недооценивать ее?

«Традиционное управление незаменимо, когда нужно подчинение, но если вы хотите вовлеченности — а именно она сейчас и нужна, ведь люди выполняют более сложную и комплексную работу, — то без автономии и самоуправления не обойтись», — поделился с нами опытом Дэн Пинк, автор книги «Драйв: что нас мотивирует»[15].