Жить не в офисе и нанимать сильных людей

Программный комитет конференции Рroduct Fest , которая пройдет 9 декабря в Москве, решил взять интервью у некоторых спикеров конференции. Первым в списке оказался Глеб Кудрявцев — человек яростно пропагандирующий удалённую работу в IT-компаниях.

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

Да, и сейчас я занимаю должность CPO (Chief Product Officer), но не всей компании, а отдельного направления. Я руковожу командой продукт-менеджеров и проджект-менеджеров в детском направлении Skyeng. Оно представлено английским языком и математикой. Также есть эксперименты в других поднаправлениях.

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

Поставим еще одну реперную точку, Skyeng — это самая большая онлайн-школа в России?

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

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

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

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

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

Иногда они приходят со стороны маркетинга.

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

Ты со скепсисом относишься ко всяким онлайн-школам продуктового направления?

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

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

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

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

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

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

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

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

А твой собственный путь в продукт-менеджеры тоже с таким же маленьким кладбищем?

Конечно, у меня прилично прикопано. Я пробовал запускать свои стартапчики разного рода. В 2008 году я начал с сервиса по озеленению офисов. Мы ставили в офис цветы по подписке, поливали, ухаживали, вели полный цикл. На тот момент, кстати, проект не взлетел. Моя целевая аудитория сидела в офлайне, а я переоценил степень интернетизации. То есть я пытался двигаться и всё делать исключительно через онлайн, и у меня не было никакого опыта продаж.

Были высокие шансы?

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

Параллельно мы с моим научным руководителем делали стартап по созданию тест-систем для диагностики разных заболеваний и по оказанию услуг в области молекулярной биологии. Я вообще изначально генетик. Я ушел из «науки», когда понял, что бесплатно работаю, а долю мне предлагать никто не собирается. Но я много сделал и многому научился. Это был реальный такой стартап. Мы подавались на всякие гранты. Что-то выигрывали, что-то нет.

Был уникальный опыт, лично подавал жалобу в ФАС на министра сельского хозяйства. Нас несправедливо зарезали на одном из конкурсов. В итоге, мы даже сумели пробиться с нашими госзакупками куда-то довольно высоко. Это было крайне интересно. Но я потом из этой всей истории ушел. Ушел, потому что понял, что мне ближе мир информационных технологий.

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

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

Мне очень понравилась тема бизнес-процессов. Я писал статьи на эту тему, и в итоге ушёл работать в Мегаплан. В Мегаплане за полтора года я прошел путь от аналитика до продукт-менеджера. У меня появилась своя команда и ответственность за управление CRM.

Регулярно брался за любимое дело — делать свои стартапы. На тот момент я увлёкся мобильными приложениями. Уровень моего понимания бизнеса и всего на свете на тот момент был такой, что я просто думал: «А как пишут люди мобильные приложения? Что надо сделать?» Надо купить Macbook и начать писать. Я плохо умел программировать, но мне это было всё равно.

Снова вернулся к теме растений, с которыми был связан первый бизнес. Решил написать определитель растений. Тогда я не думал о том, какая это ниша и какой объем рынка. Реализовал приложение, и потом еще два или три года капали денежки. Это был классный опыт, но не денежная ниша.

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

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

Я придумал продавать шкатулочки с эмблемами от разных карточных игр, в первую очередь, headstone, а шкатулочка такая под размер карт. Мне сделали деревянную форму, по которой я делал эти отливки, навострился их делать. Для меня производство стоило рублей 200. А покупателям я их продавал по 50 баксов. Под новый год хорошо разбирали. Это было очень прикольно, потому что это был кейс, когда я применил мозг. Понятно, что это тоже была крайне ограниченная ниша, но у меня был интерес именно не миллион долларов заработать, а посмотреть, где вообще бывает маржинальность. Я увидел, что вот в таких вещах, например, бывает маржинальность.

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

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

Одно главное качество, которое есть у продукт-менеджера, — он отличает лажа или не лажа, появляется внутренний триггер. Какие еще, на твой взгляд, главные черты отличают сильного продукт-менеджера?

Это не просто умение отличать — лажа не лажа. Это фактически его натренированная нейросеть уже. Это отличие именно опытного продукт-менеджера.

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

Ещё важная черта — это результативность. То есть можно классно со всеми договариваться, придумывать, но не доводить дела до результата, то есть ходить и быть такой птицей говоруном. Очень важно, что ты не просто говоришь, а можешь предъявить, что ты сделал, чего достиг или что зафакапил, это иногда бывает даже более ценно. Но в любом случае ты это реально сделал. Вот это супер важно.

Удаленная работа конкурирует с офисом, как по твоему мнению?

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

Как это происходит в офисе? Сотрудник приходит, что-то там мельтешит и вроде как работает. А отсутствие результатов он всегда готов обосновать миллионом различных отмазок. Его присутствие в офисе — это тебе как шоры на глаза, как туман войны. Это мешает тебе увидеть реальную картину.

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

Что плохого есть в удаленной работе, что тебя прям бесит?

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

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

Ещё из парадоксальных проблем — удаленщики зачастую перерабатывают. Они работают больше офисных сотрудников. Дом и офис это одно и то же. Просто включил компьютер и сидишь весь день. Потом выключил, пошёл спать. Многие скатываются в такой режим.

Что самое отвратительное в офисной работе?

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

Но вообще часто бывает, что в офисе коммуникации слабо контролируются. Более того, часто важные вопросы отдаются на решение случайным факторам. Например, я иду на кухню, вижу там директора по маркетингу, начинаю с ним обсуждать какой-либо проект. А представим теперь, что я бы не пошёл на кухню. Это что значит, я бы не обсудил важный проект? Для меня это дико странно. Я называю это кухонный менеджмент, когда то, что делает ваша компания, зависит от того, встретились ли на кухне два ваших важных сотрудника или нет. Можно сказать, офис позволяет иметь немножко «рукиизжопы», назовем это так.

Это самое плохое в офисе. А что самое крутое в офисе?

Самое крутое — неформальное общение.

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

Понимать, что программист тянет не тянет, в общем, достаточно просто — ставим задачу: вот они сроки, вот результат. А как понять, что продукт-менеджер тянет?

Разные компании могут ожидать разного, поэтому здесь нет универсального ответа. Можно посмотреть на то, что он запустил или на то, что он сделал. Выписываешь список того, что ты ожидаешь от продукт-менеджера. Затем ты говоришь: «Вот ты продукт, я от тебя ожидаю вот это, вот это и вот это. Ты согласен?», — и допустим, он соглашается. Тогда вы это фиксируете как цели на квартал, больше или меньше, как удобно. Затем вы проверяете, достигает ли он этих целей. Если достигает — молодец. Вот и всё.

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

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

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

Какие главные полномочия должен получить продукт-менеджер?

На конференции буду рассказывать про опыт найма. Я считаю, что у нас сильно недооценивается роль продукт-менеджеров. Две главные вещи вообще на рынке: полномочия по управлению бюджетом в широком смысле, бюджетом всего проекта, и полномочия по HR-функции, то есть найм и увольнение. Я считаю, что руководитель, в данном случае продукт-менеджер не может быть эффективным в принципе, если у него нет права нанимать и увольнять своих людей в команде, причём свободно в рамках бюджета. То есть у меня есть бюджет — всё, кого хочу нанимаю, кого хочу увольняю и именно я решаю, как вести этот проект. На российском рынке этого практически нет. У нас продукт-менеджер зачастую — это тот, кому дают команду и говорят «вот, у тебя есть команда и всё». Максимум, что он может сделать — попросить поменять вот этого разработчика на другого.

То есть полномочий по найму тотально не хватает?

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

Подавляющее количество людей в Skyeng — это удаленные сотрудники. И ты тоже удаленный сотрудник своей компании.

Да, это всё так.

Какое главное качество удаленного сотрудника?

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

Внутренне мотивированный человек?

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

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

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

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

А чего команда от него ожидает или чего она должна ожидать, по крайней мере, от хорошего продукт-менеджера?

От хорошего продукт-менеджера команда должна ожидать понимания смысла, что они делают. Продукт-менеджер — это, в том числе, тот человек, который дает смысл. Он говорит, что не просто мы делаем, камешки кладем, а что мы строим Великий собор. И хорошая команда у хорошего продукт-менеджера всегда строит Великий собор, даже если она просто кладет камешки.

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

Какие заблуждения про продукт-менеджеров есть?

Мне кажется, есть заблуждение, что приняты универсальные догмы. Например, продукт-менеджер обязан круто считать аналитику, или продукт-менеджер обязан круто делать customer development, или вообще любую вещь, которую можно придумать. И это подается как данность, дескать есть технология, знаешь её — ты продукт-менеджер, не знаешь — не продукт. Я считаю, что это ерунда. В смысле, нет какой-то одной технологии, которая позволяет тебе считаться продукт-менеджером. Это всё равно, что ты вот токарь, и должен так точить болванки. Но, кроме того, что ты умеешь так точить болванки, на самом деле, это ничего не значит.

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

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

Зависит от того, насколько дизайн является ключевой функцией продукта.

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

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

Когда я говорю аутсорсеры, я имею в виду, в том числе, внутренний аутсорс. Когда я нанимаю подчинённого на дизайн, это внутренний аутсорс. Тут хорошая практика — это нанять того, кому ты полностью доверяешь и дальше ему полностью доверять. Я придерживаюсь этого.

В случае аутсорса сотрудника нужно направлять, и в случае с дизайнером я даю ему набор поведений, которые должны быть на странице, говорю, что вот эти сценарии должны быть реализованы. А потом мы просто проходим по чек-листу. Он приносит макет, говорю: «Так, вот этот сценарий покажи мне, этот сценарий и этот». Если все сценарии реализованы, я говорю: «OK, молодец. Как это выглядит, тебе виднее, ты дизайнер и мне, если честно, всё равно. Тебе как главному дизайнеру важнее дизайн, а мне важны сценарии. Посмотрели, что они реализуются классно, наверняка, ты договорился со всеми остальными дизайнерами, что им тоже ОК, поэтому я даже вообще не буду тебя спрашивать, почему здесь кнопка зеленая, красная или вообще кнопки нет, а ты вместо кнопки сделал меню, если это удовлетворяет условиям задачи». Вот и всё.

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

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

Дальше верификация иногда без реализации и ты можешь понять, валидна она или нет. Бывают разные виды проверок, начиная просто даже с экспертного мнения, дальше коридорные тестирования, дальше AB-тесты и так далее. Есть много способов проверить гипотезу, иногда просто помогает залезть в аналитику.

Кто должен принимать решение о найме продукт-менеджера?

Его начальник. Тот, кто думает, что ему нужен продукт-менеджер. Вообще считаю, что принимать решение о найме должен будущий руководитель сотрудника, неважно продукт-менеджер это, дизайнер, разработчик, кто угодно. Люди нанимаются под конкретного руководителя, конкретному руководителю с ними работать, значит именно он должен принимать такое решение. Навязанные наймы не работают. Если я приду к кому-то и скажу: «Давай, я тебе найму чувака, потому что я так считаю», а тот человек к этому не готов, то ничего хорошего из таких историй не выходит.

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

Поймем откуда взялся первый продукт-менеджер? Скорее всего, его нанял СЕО компании, и он его непосредственный руководитель. И при найме второго продукт-менеджера СЕО должен себе честно ответить, могу ли я потянуть ещё одного подчиненного, какова моя личная загрузка? Дальше этот СЕО понимает, я нанял человека, а можно доверить ему своих подчинённых или нельзя. Дорос ли он до руководства другими продукт-менеджерами или не дорос. Если не дорос, то CEO нанимает второго человека под себя, как бы больно это не было. Потому что невозможно плодить бесконечное число подчиненных.

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

Это главный сценарий?

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

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

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

Что нужно сделать, чтобы нанять сильного продукт-менеджера?

Нужно понять, что для тебя является качествами, определяющими силу. Это очень индивидуальная история. Кто-то считает этого сильным, кто-то другого считает сильным. Моя техника такая, я пытаюсь представить себе некую идеальную рабочую неделю, идеальный рабочий месяц, идеальный рабочий год сотрудника, которого я хочу нанять. Неважно, продукт-менеджер это, дизайнер или кто угодно. Выписываю, что он будет делать и каковы его обязанности. А дальше я смотрю на это и думаю, какая самая сложная часть из всего, какое из этих качеств реже всего встречается на рынке. Топ-3 выделяю.

Дальше я думаю, как мне эти топ-3 качества проверять. Например, я считаю, что продукт-менеджер должен хорошо знать аналитику, уметь ковыряться во всей этой истории. Понимать конкурентов и уметь с ними работать. И допустим, должен хорошо формулировать свои мысли. Далее я придумаю задание, либо вопросы на интервью, которые помогут мне понять, как взвесить человека относительно этих качеств. В моём случае, это письменные тестовые задания. Я выделяю парочку ключевых качеств и делаю тесты. Найти идеального продукт-менеджера это супер индивидуальная история.

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

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

Что по-твоему значит плохой менеджмент?

Чтобы понять, что такое плохой менеджмент, поймем, что такое хороший менеджмент. У хорошего менеджмента очень простое определение. Хороший менеджмент определяется тремя вещами:

• ты знаешь, куда ты идешь, то есть знаешь цель;
• ты идешь по направлению к цели, или как минимум держишь направление;
• это не случайно.

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

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

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

Гребет — значит использует все доступные ресурсы вокруг себя. Реально все доступные ресурсы. Например, прихожу к руководителю:

— Что ты думаешь по этому вопросу?

— Ты должен сам доходить до каких-то вещей

— Нифига. Я использую все доступные ресурсы. Ты — мой ресурс. Вот когда ты будешь недоступный, тогда я буду сам. А если мне проще об тебя подумать, то я буду это делать, потому что я использую Любой ресурс.

При этом, если компания не предоставляет ресурс, менеджер пойдет искать его на рынке. Если денег нет, он пойдет бесплатно искать. Ну, и так далее. Вот в моём понимании — это хороший менеджер.

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

Это хороший менеджер, если он вовремя скажет: «Ребят, цель была впереди, но ветер нам в лицо, мы не догребем до конца. Давайте развернемся», — и сознательно эту цель переносит назад, куда там ветер дует и гребет. Это хороший менеджер.

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

Читайте блог Глеба PM Life в Telegram и приходите послушать его доклад на конференцию Product Fest 9 декабря в Москве.