Лучшие приемы от руководителя, стоящего за двумя самыми топовыми продуктами в мире

Тодд Джексон, бывший PM Google и Facebook рассуждает о своем опыте работы в качестве продакт-менеджера и дает советы о том, как быть продуктивным и полезным

Тодд Джексон находился в небольшом конференц-зале с горсткой дизайнеров, инженеров и Марком Цукербергом. Речь шла о редизайне новостной ленты Facebook, призванном упорядочить работу Facebook и сделать ее еще более увлекательной. Они просмотрели последние макеты, обсудили размеры фотографий, плотность текста и переработанную навигацию сайта. Затем они сосредоточились на одном, казалось бы, незначительном моменте: преобразовании имен людей из синих в черные. Джексон, менеджер по продуктам в комнате, знал, что это сложнее, чем можно подумать.

На самом деле у Цукерберга была простая философская позиция по этому вопросу - имена людей должны оставаться жирными и синими, потому что люди являются центром Facebook. Люди - это то, вокруг чего вращается весь контент, и они должны выделяться, сказал он. Команда Джексона придерживалась другого мнения: для более глубокого вовлечения аудитории Facebook должен эволюционировать, чтобы в первую очередь демонстрировать контент.

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

Такова участь менеджера по продукту. И Джексон знает об этом лучше многих. Будучи руководителем отдела Gmail во время работы в Google, отдела News Feed в Facebook, а теперь и генеральным директором своего собственного, недавно запущенного Android-стартапа Cover, он решал сложные проблемы вместе с некоторыми светилами технологий. Если кто и знает, как сбалансировать несколько интересов, так это он.

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

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

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

У Джексона есть еще несколько правил для таких ситуаций - лучшие практики для руководителей продуктов:

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

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

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

Будьте мастером влияния, а не власти: Очевидно, что у вас нет власти над учредителями или другими заинтересованными сторонами, перед которыми вы выступаете, но вы также, вероятно, не имеете власти над инженерами, с которыми работаете. Вы должны быть хорошим коммуникатором и упрощать людям жизнь. "Заполняйте пробелы везде и для всех", - говорит Джексон. "Проверьте новую функцию, напишите первый пост в блоге, сделайте макеты, которые дизайнеры могут счесть любительскими, но они дадут им вдохновение. Делайте рутинные вещи, которые меняют ситуацию и двигают дело вперед.

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

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

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

По словам Джексона, для достижения прогресса в работе с любой конкретной заинтересованной стороной необходимо знать, что для нее важно. Понимание их ценностей — это как умение говорить на разных языках. У основателя компании совершенно другие заботы, чем у сотрудника отдела эксплуатации или маркетинга - даже на ранней стадии. "Наиболее важные аспекты будут разными для каждого человека. Такие основатели, как Ларри [Пейдж] или Цук, хотят знать, каков пользовательский опыт для продукта X? Почему это важно со стратегической точки зрения? Операционные и юридические службы хотят знать, насколько сложно будет поддерживать продукт X. Сколько запросов на обслуживание клиентов они получат в результате? Знать и говорить непосредственно со своей аудиторией очень важно".

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

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

Во время своей работы в Google Джексон участвовал в обсуждении нового пользовательского интерфейса, в котором Gmail, Календарь и Документы можно было бы искать в одном месте. "Ларри предложил пойти гораздо дальше. Его идея заключалась в том, чтобы "просто распознавать" весь экран компьютера непрерывно, чтобы вы могли легко искать и находить все, что когда-либо видели на своем компьютере. Это замечательно. Но эта технология не имела ничего общего с технологией, которую мы создавали, и была бы в десять раз сложнее. Но для Ларри это был аналогичный процесс. С одной стороны, это выходило за рамки того, что могла сделать наша команда. С другой стороны, это причина, по которой компания делает удивительные амбициозные вещи, такие как автомобили без водителя".

Рекомендация Джексона: Позволяйте себе сбиваться с пути, но не слишком сильно. "Если они дают конкретные предложения, с которыми вы не согласны или которые звучат странно, всегда старайтесь понять сущность просьбы. Иногда вы можете быть категорически не согласны с конкретикой, но вы действительно согласны с главными целями". Кроме того, основатели заставляют свою команду мыслить шире — это поможет вам добиться лучших результатов в долгосрочной перспективе".

Если неудачи перерастают в серьезные решения, Джексон рекомендует прижать основателей к стенке. "Спросите их напрямую: "Так это решение?", - говорит он. "Затем четко сформулируйте свои дальнейшие действия: "Мы проследим за этим моментом и вернемся к вам".

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

В 2007 году, когда Джексон впервые присоединился к команде Gmail, это был первый поставщик услуг электронной почты, предложивший поддержку IMAP бесплатно (если не считать Netscape за 10 лет до этого). Yahoo, Hotmail и другие взимали за это плату в рамках своих премиум-планов. У руководства Google возникли вопросы о том, как действовать дальше. В то же время ведущие инженеры Gmail были впечатлены анонсом iPhone и хотели, чтобы пользователи продукта получили отличный опыт работы на этой платформе. IMAP позволит пользователям синхронизировать все свои действия на телефонах и настольных компьютерах, накладывать ярлыки, ставить отметки и архивировать сообщения - поэтому он занимал центральное место в стратегии.

"Но мы все еще не знали, сможем ли мы сделать его бесплатным", - говорит Джексон. "Это позволило бы пользователям Gmail пользоваться сервисом, не видя рекламы, и, следовательно, мы не смогли бы получить доход, чтобы оплатить расходы на хранение данных. Но Ларри и Сергей - в основном, руководствуясь интуицией - сказали, что он должен быть бесплатным. Они рассуждали так: если людям понравится Gmail на телефоне, они будут чаще пользоваться сервисом в целом, и будет гораздо больше ценных побочных эффектов от того, что люди полюбят свои аккаунты Gmail".

Джексон и его команда провели исследование, и неудивительно, что стоимость этой стратегии была бы значительной. Но Брин и Пейдж все равно сказали: "Давайте сделаем это". Теперь, в будущем, когда единый вход во все приложения Google играет такую важную роль, это был, безусловно, правильный шаг. Это решение даже подтолкнуло конкурирующие почтовые службы предложить IMAP бесплатно и увеличить лимиты хранения данных. Это довольно значительная победа.

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

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

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

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

Если удовлетворение запросов и проблем основателей — это основная часть работы руководителя, то еще более важной частью является мотивация и координация дизайнеров и инженеров для достижения целей компании. Это сопряжено со своими личными особенностями, ловушками и уловками. Но если и есть один общий совет, который Джексон держит в рукаве, то это следующий:

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

"Я люблю создавать макеты и работать с дизайнерами, чтобы показать, как все может выглядеть. А потом вы начинаете рассказывать историю. Например, когда мы работали над редизайном ленты новостей, мы говорили: "Лента новостей стала загроможденной. Она была такой же на протяжении многих лет. Люди прокручивают ленту вниз, и как только они попадают на записи, которые они уже видели, они закрывают Facebook и занимаются чем-то другим. Разве не было бы удивительно, если бы лента новостей выглядела вот так?". Тогда вы показываете макеты и говорите: "Здесь так много потрясающего контента, который публикуют страницы, за которыми вы следите, ссылки, которыми поделились ваши друзья, фотографии, которые понравились вашим друзьям. Что, если мы сделаем так, чтобы они выглядели настолько хорошо, что люди будут просматривать в два раза больше историй в день? Если бы это произошло, они бы проводили на сайте в два раза больше времени. Другие люди получили бы в два раза больше лайков, а мы бы получили в два раза больше дохода". Такую историю команда может понять и поддержать".

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

Хотя эта тактика действует на всех по-разному, Джексон обнаружил, что она особенно мотивирует инженеров, которые могут иметь более обособленный взгляд на проект. "Я думаю, что инженеров волнует будущее. Они становятся инженерами, потому что хотят помочь создать будущее. Поэтому покажите им, как оно может выглядеть. Заставьте их радоваться тому, как это может выглядеть. Если они воодушевлены, они будут усердно работать, чтобы воплотить это в жизнь".

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

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

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

Будьте зонтиком для дерьма, а не воронкой для дерьма: Вы должны беречь свое время и время своей команды. Как руководитель, вы постоянно участвуете в совещаниях, где руководители очень прямо говорят, что все не работает, и команда должна лучше работать над X, Y или Z. "Вы должны выработать толстую кожу, а затем научиться переводить всю критику, которую вы слышите, в нечто мотивирующее".

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

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

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

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

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

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

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

Когда продукт передается команде, работающей над ним, один инженер может сломать что-то, что другой инженер сразу же заметит и исправит. И в Google, и в Facebook были созданы системы, позволяющие всем видеть продукт на каждом этапе внедрения. В определенный момент этот цикл исправлений и инноваций превращается в гордость за продукт и желание, чтобы он был совершенным, говорит Джексон. Когда вы хорошо относитесь к тому, чем пользуетесь каждый день, вы чувствуете себя намного лучше, когда открываете его для внешних пользователей. "Быть признанным своими коллегами или людьми, которых они уважают, — вот, пожалуй, главное, что движет людьми".

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

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

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

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

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

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

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

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

Вы также хороший PM, если ваше отсутствие замечают лучшие инженеры в вашей команде. "Вы хотите, чтобы они спрашивали: "Что бы сделал или сказал этот PM, если бы она была здесь?" Вы хотите, чтобы лучшие люди ценили ваше мнение настолько высоко и знали, что у вас есть технические навыки, чтобы внести значимый вклад".

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

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

Оригинал: