4 типа Product Lead лидов на примерах

Недавно прочитал интересную книгу И. Адизеса «Развитие лидеров»: она может помочь как обычным продактам лучше понимать своих коллег, так и более Sr. и Lead-ребятам, которые уже менеджат других. Суммирую книгу на примерах с работы и заодно рассказываю про главные сюрпризы, которые не ожидал для себя открыть после 8 лет карьеры в Booking.com.

Автор начинает с того, что идеальных CEO (лидов, директоров, CPO, GPM, — неважно) просто не существует. И дело тут не в философском «идеал недостижим», а в простом жизненном факте, что в зависимости от ситуации нужны разные качества и их комбинации.

Давайте посмотрим на реальный пример. Представим себе большую компанию, где команда брейнстормит новую фичу:

Все продакты сейчас, наверное, подумали: "Первый — самый адекватный, а программист вообще красавчик — уже код пишет! Остальные какие-то тормоза". Я так тоже раньше думал, но давайте разбираться.

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

На заре карьеры продактом я был уверен, что правильный стиль — это PE, а остальные просто мешают мне делать работу быстро. На самом деле, PE-лидер — эффективная, но опасная связка: сам придумал 10 идей, сам побежал их делать, а через неделю придумал еще 10 (прямой путь к выгоранию). Особенно больно бывает подчиненным такого лидера: теперь босс только придумывает, а вы только делаете, причем частно он еще и не хочет слушать про "все не так просто", "нужно больше времени" и вот это все. То же выгорание, на этот раз - команды.

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

Именно поэтому в международных компаниях команду ведут «противоположные» типы — чаще всего EP-продакт и IA-тимлид. Ну а чем сложнее «команда» (департамент, бизнес-юнит, компания), тем более разношерстная команда лидеров ей нужна.

В стартапах важно напирать на E и P, чтобы быстро проверить гипотезу, и ни в коем случае не строить паутину процессов (A), которые все затормозят и могут и не пригодиться вообще.

При найме и создании долгосрочных подразделений важно задуматься про I, потому что выигрывают матчи не индивидуумы, а слаженные команды. Я вообще люблю думать, что хорошая команда может делать любой продукт, от computer vision до платежки, от e-commerce до med-tech, а если ее бросить на продажу яблок, то и там они придумают виралку, insta-яблоки, лоялти-программу сока и вырастят продажи на 300%.

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

Во-вторых, я буду следить за своей A и I частью, которая в моем текущей ситуации (менеджерю 4 продуктовые команды) становится все более и более важной. Я уже не могу сам все P (потому что у меня аж 4 продукта!) и не могу все E (потому что мои подчиненные офигеют за мной успевать). К счастью мой Senior Engineering Manager (босс тимлидов) — гениальный IA, так что есть у кого учиться и балансировать меня.

Идеи E должны быть сильные, а значит основаны на аналитике, работе с данными и четкой системе приоритизации. Чтобы идеи превратились в реальность, нужно уметь прикинуть software architecture продукта, понимать полезность API, уметь мерить метрики, запускать A/B-тесты. Да, правда нужно все уметь и быть способным научить своих ребят. Все эти знания можно прокачать на умных симуляторах в школе ProductDo (productdo.it) - минимум воды, максимум практики от синьоров международных компаний.

Когда у вас сильны харды, а к ним вы добавляете еще и правильные лидерские софты, то все у вас будет хорошо. Удачи!