Два с половиной года я присоединился к команде Facebook — сразу после того, как компания купила MSQRD. Тогда я сомневался, что смогу научиться чему-то новому в крупной корпорации. И сильно ошибался.
Недавно был мой последний день в Facebook, поэтому самое время порефлексировать на полученный опыт и поделиться интересными наблюдениями.
Делиться конкретными кейсами я не могу, поэтому речь пойдет о продуктовой культуре Facebook. Если вам интересны более прикладные знания, то добро пожаловать в «Симулятор управления продуктом на основе данных». Значительная его часть формировалась под влиянием опыта работы в синем социальном гиганте.
Мой субъективный опыт
Все написанное ниже — мой субъективный опыт. Facebook — огромная компания с множеством продуктов и команд, каждая из которых уникальна в своем роде. Как и везде, все зависит от конкретных людей, которые тебя окружают.
Мой опыт основан на работе в продуктовой команде, которая выводила на рынок новый сервис — . В Facebook есть много технических команд, опыт там будет отличаться. Есть много команд, которые развивают давно состоявшиеся продукты. Их опыт опять же будет в чем-то другим.
Каждый член команды отвечает за общую цель
В большинстве компаний за цель конкретной команды отвечает ее менеджер. Разработчики, дизайнеры, аналитики прямой ответственности за общую цель не несут. Им нужно писать хороший код, делать качественный дизайн, быстро находить ответы на вопросы в данных.
Продуктовые команды в Facebook работают иначе: ответственность за цель лежит на всех. Работа разработчика оценивается не по качеству и скорости реализации фич, а по тому, как запущенные им проекты повлияли на продвижение к цели (“impact”). Если ты пишешь идеальный код, но эффект в плане метрик и инсайтов от твоих проектов нулевой, то на ревью возникнут сложности.
Главный плюс такого подхода — интересы всех участников команды синхронизированы и сонаправлены. Больше не надо уговаривать разработчика сделать дешевую костыльную первую версию, чтобы проверить идею. Он сам в этом заинтересован.
Из минусов (хотя иногда это может быть и плюсом) — принятие решений становится децентрализованным. Описанный подход подразумевает высокую степень свободы сотрудников как в выборе проектов, над которыми они хотят работать, так и в способах их реализации. Следствие — ручное управление становится практически невозможным. Иногда же это необходимо, например на ранних стадиях сложного проекта с высокой степенью неопределенности.
Функция проджект-менеджмента размазана по команде
Другая особенность продуктовых команд в Facebook — отсутствие конкретного человека, который выполняет функции проджект-менеджера. Эта роль размазана по команде.
В конкретном проекте ее может взять на себя продакт-менеджер или дизайнер, или разработчик, или аналитик. Обычно тот, кто больше всего горит и верит в проект. Этот человек организует процесс, синхронизирует всех между собой, разбивает проект на части, активно участвует в анализе результатов и формировании следующих шагов.
У подхода есть очевидные плюсы: высокая мотивация, способность влиять на цель, большое количество горизонтальных связей, рост и развитие сотрудников. Из минусов — растет вероятность рассинхрона между целями команды и конкретными проектами, могут страдать сроки и планирование.
Вы можете спросить, что же делает продакт-менеджер. Во-первых, продакт тоже ведет ряд проектов, обычно ключевых. Во-вторых, он так или иначе приглядывает за всеми остальными проектами, но такая структура дает возможность ему не погружаться в них слишком глубоко, не тратить время на синхронизацию и пинание людей. В-третьих, ключевая работа продакта — создать условия, в которых каждый участник команды будет четко понимать, что делает команда и куда хочет добежать, для чего и зачем это нужно. Так достигается баланс между свободой конкретного сотрудника и тем, что он фокусируется на том, что важно для продукта и компании. Об этом следующий пункт.
Миссия, цель, приборы
Единое понимание миссии и цели всеми участниками команды становится критичным при описанном выше способе построения работы. Если его нет, то люди начнут тянуть продукт в разные стороны, причем из лучших побуждений.
В командах на ручном управлении менеджер вполне может удержать в голове общую картину и быстро корректировать траекторию движения при необходимости. Как только значительная часть продуктовых решений спускается на уровень команды, появляется необходимость четко задать границы и ориентиры: сформулировать миссию и цель, создать приборы.
Миссия — это одно предложение, которое объясняет, зачем существует команда. Миссия формулируется не с точки зрения интересов бизнеса, а с точки зрения интересов пользователя. Вырастить time spent и долгосрочный Retention — это интересы бизнеса. — это интересы пользователей.
На основе миссии выбирается цель — это точка, куда команда хочет попасть в обозримом будущем. Цель обычно имеет числовое выражение, то есть состоит из метрики и ее целевого значения. Иногда цель может быть бинарной — сделать возможным X. Иногда целью может быть изучение потребностей какого-то сегмента аудитории, специфичной задачи или рыночной возможности (такие цели называют Understand goals).
Приборы — ключевая метрика и опережающие индикаторы, протянутые на дэшборды и в экспериментальную платформу.
Все звучит просто в теории, но оказывается сложно на практике. Попробуйте сформулировать миссию своей команды в одном предложении, вписавшись в интересы всего продукта и компании, не создав конфликтов с другими командами. Потом найдите метрику, которая четко отражает то, что вы хотите сделать, с понятным физическим смыслом, легко измеримую, чувствительную к масштабу ожидаемых изменений, которую нельзя искусственно накрутить, способную явно показывать прогресс при его наличии. После определите, как именно вы хотите изменить эту метрику в следующие шесть месяцев, какие проекты для этого надо реализовать, сколько людей и какая помощь от других команд для этого потребуется.
Чтобы глубже разобраться в том, как создаются, развиваются и масштабируются продукты, пройдите обучение в GoPractice.
→ Программа «Профессия: продакт-менеджер» поможет вам перейти в продакт-менеджмент из смежной роли или индустрии.
→ В «Симуляторе управления продуктом на основе данных» вы научитесь принимать решения с помощью данных и исследований при создании продукта.
→ В «Симуляторе управления ростом продукта» найдете пути управляемого роста и масштабирования продукта.
→ В «Симуляторе SQL для продуктовой аналитики» поймете, как применять SQL для решения продуктовых и маркетинговых задач.
→ В мини-симуляторе «Генеративный AI для продакт-менеджеров» вы научитесь применять генеративный AI для создания продуктов, решив практический бизнес-кейс.
→ В «Симуляторе управления ML/AI-проектами» научитесь применять технологии машинного обучения с пользой для бизнеса.
→ Не знаете с чего начать? Пройдите бесплатный тест для оценки навыков управления продуктом. Вы определите свои сильные стороны и слепые зоны, получите план профессионального развития.
→ Еще больше ценных материалов и инсайтов — в телеграм-канале .
Но прежде, чем заниматься всем тем, что описано выше, надо понять, что именно вы будете делать. Это понимание не может быть результатом фантазии или интуиции менеджера. Разработчики, дизайнеры, тестировщики должны четко понимать, почему надо работать именно над этим, а не над чем-то другим. Фундаментом для выбора цели является база знаний и инсайтов о пользователе, продукте и рынке, над которыми на постоянной основе работает команда.
Understand, Identify, Execute
Эти три слова описывают подход Facebook к продакт-менеджменту. В большинстве компаний фокус значительно смещен на этап Execute, то есть на реализацию конкретных идей и проектов (иногда это более чем оправдано, но не всегда). Обычно эти проекты — смесь увиденного у конкурентов, запросов пользователей, интуиции менеджеров. В Facebook такой подход не сработает ни на уровне убеждения и мотивации команды, ни на уровне защиты целей и планов перед руководством.
Предлагаемые активности должны базироваться на понимании задач пользователей, сильных и слабых сторонах продукта, текущей ситуации на рынке, который формируются через анализ данных и качественные исследования (user research). Поэтому существенная часть ресурсов и времени продуктовых команд в Facebook тратится на этапы Understand и Identify, которые являются фундаментом для этапа Execute.
Этап Understand подразумевает глубокое изучение пользователя, продукта и рынка, которые позволят увидеть имеющиеся возможности и проблемы. На выходе вы должны четко понимать, в чем ценность вашего продукта, какую задачу он решает, чего хочет достичь команда и почему.
Этап Identify — это генерация идей о том, как можно достичь цель, оценка их потенциала и приоритизация.
Идеи собираются из многих источников: брейншторм с командой, инсайты из анализа данных и качественных исследований, переиспользование опыта других команд, изучение конкурентов.
Оценка потенциала идей делается как через моделирование с помощью данных, так и через проверку релевантности идей на уровне проблемы и решения с помощью качественных исследований. Иногда для проверки оправданности инвестиций в определенное направление может быть спроектирован недорогой эксперимент.
На выходе получается список идей с примерной оценкой влияния на цель команды.
Только теперь команда переходит к этапу Execute. Члены команды выбирают проекты, в которые они больше всего верят. Начинается всем знакомый процесс дизайна, разработки, тестирования, релиза, анализа.
Важно понимать, что движение по шагам Understand-Identify-Execute не является однонаправленным. Каждый шаг имеет обратный цикл. Например, знания полученные после реализации первых проектов, могут повлиять на ранее сделанную приоритизацию, а иногда и на цель команды.
Описанный подход при должном исполнении намного более эффективен, чем работа на уровне генерации и реализации фичей (даже с обратным циклом анализа их влияния на продукт).
Решения строятся не в вакууме, а в четкой привязке к задачам пользователей, поэтому они получаются более эффективными, команда лучше понимает, что и зачем делает, а также с каждым проектом углубляет знания о пользователе, продукте и рынке.
Также это позволяет избежать пагубной ситуации, когда спустя время идеи на поверхности заканчиваются, и команда либо начинает делать необоснованно рискованные проекты, либо отправляется на второй круг делать то, что уже делала раньше.
Главное в применении описанного подхода — не переусердствовать. Анализа и изучения пользователей должно быть ровно столько, сколько нужно для принятия необходимых решений. Другой важный момент — не подгонять данные и исследования под заранее придуманные идеи, а искать идеи и решения исходя из полученных инсайтов о пользователе и продукте. Подгонкой продуктовые команды грешат очень часто. Facebook не исключение, но там это происходит относительно редко.
Подробнее прочитать про подход можно и . По ссылкам есть и иллюстрация описанного подхода на вымышленном примере.
Культура работы с данными
До прихода в Facebook я думал, что удивить меня тем, как выстроена в компании работа с данными, будет сложно. И вновь ошибался. Роль данных в процессах Facebook значительно выше, чем в других компаниях, которые я знаю.
Описать кратко культуру, которая строилась многие годы и пронизывает всю компанию, невозможно, но давайте обсудим некоторые интересные решения и подходы.
Аналитики в Facebook — не интерфейсы к данным, а полноценные участники команды, участвующие в принятии решений на всех этапах цикла Understand-Identify-Execute. Во многих компаниях на аналитическую команду ложится большой пласт мелких задач из разряда «посчитай то, посчитай это». Если в Facebook аналитик оказывается завален такими задачами, то он что-то делает не так. Его задача адаптировать аналитическую инфраструктуру компании под нужды своей команды, а потом обучить коллег ей пользоваться, чтобы те могли получать ответы на большинство вопросов самостоятельно. Это позволяет спустить значительную часть типовых аналитических задач на уровень разработчиков и менеджеров, тем самым высвободив время аналитиков на важные исследования, планирование, помощь в принятии ключевых решений.
Facebook много инвестирует в обучение сотрудников навыкам принятия решений на основе данных. Во-первых, все новые сотрудники проходят обучение в рамках буткемпа (вводная программа для вновь прибывших). Во-вторых, в командах уделяется много внимания и времени обсуждению результатов запусков и экспериментов. У нас была еженедельная встреча под названием Experiment Review, на которой разработчики делились результатами эксперимента с командой. Потом обсуждались выводы, дальнейшие шаги, ошибки в интерпретации. Также результаты всех экспериментов в обязательном порядке публиковались на всю команду, что позволяло распространять знания и генерировать новые идеи.
Facebook тратит много ресурсов на поддержание высокого качества ключевых датасетов. Есть ответственные, которые внимательно следят за консистентностью и достоверностью ключевых таблиц. Это снимает большой пласт аналитической работы с конечных пользователей. Также делает возможным использование этих датасетов теми, кто не работает с ними на регулярной основе. Обычно это невозможно, так как в данных всегда есть нюансы и проблемы, которые стороннему человеку без экспертизы раскопать сложно.
У каждой команды есть свой дэшборд, где отражена ключевая метрика и цель. Также для каждой команды создается свой набор метрик для экспериментальной платформы, которая автоматически обсчитывает результаты экспериментов, выдавая удобные и легко читаемые результаты с доверительными интервалами (платформа похожа на аналогичную в ). Это делает задачу анализа экспериментов доступной не только для аналитиков, но и для всех остальных.
Команды очень серьезно относятся к целям. Цель каждой команды отражена на дэшборде. Еженедельные встречи команды начинаются с апдейта прогресса к цели. Если видно, что метрика сваливается ниже уровня, необходимого для достижения цели к концу полугодия, то это повод для расследования и обсуждения, а иногда и для .
Гипотезы и факты. Инфраструктура, приборы, обучение — все это важно, но намного важнее то, насколько четко в обсуждениях люди разделяют гипотезы и факты, и насколько ответственно подходят к процессу превращения первых во второе.
Отсутствие ожесточенных споров — побочный эффект data-driven культуры
Споры обычно появляются на стыке двух мнений, каждое из которых не имеет жестких фактов под собой. Кто-то верит, что надо делать так, кто-то верит, что надо делать иначе.
За время работы в Facebook я практически не участвовал и не был свидетелем ожесточенных споров. Это не значит, что у людей не расходятся мнения и взгляды, но по умолчанию считается, что доказывать свою точку зрения исключительно на основе интуиции и веры — бессмысленно и непрофессионально. Если вы разошлись во взглядах, то нужно найти способ с помощью эксперимента, данных или качественных исследований пролить свет на вопрос.
Это делает обсуждения структурированными и конструктивными. Как только начинается дискуссия, которая базируется на гипотезах, то быстро находится человек в комнате, кто указывает на это и переводит разговор в русло поиска способов превратить гипотезы в факты.
Культурные особенности
Я не могу сказать, является ли описанное ниже в большей степени особенностью команд в Facebook, или же это влияние британской и американской культуры. Я думаю, что и то, и другое.
Возможности vs проблемы. В первые месяцы работы я часто просил коллег, с которыми подружился, проверять мой английский в важных исследованиях, которыми я планировал поделиться c широкой аудиторией. Часто я получал фидбек о том, что я формулирую инсайты в формате проблем, а не в формате возможностей. Например, я мог написать, что сейчас мы теряем N пользователей из-за такой-то проблемы. Они мне предлагали сформулировать это следующим образом: у нас есть возможность улучшить наши показатели, сделав то и то. Когда ты формулируешь что-то в формате проблемы, то фокусируешь внимание на том, что кто-то сделал неидеальную работу, о чем-то не подумал. Сформулировав эту же мысль в формате возможности, ты смещаешь фокус на то, что можно сделать, чтобы улучшить продукт, приблизиться к цели.
Оптимизм и открытость к новому. Когда я слышу идею нового проекта, то мой мозг сразу начинает искать причины, почему это не сработает. Такой скептицизм позволяет срезать заметную часть плохих идей, но иногда под нож попадают и хорошие. В культуре Facebook критичность к новому заметно ниже. Это не значит, что потенциальные проблемы новых идей не поднимаются, но такие обсуждения обычно носят характер поиска решений. Другая особенность — способность с энтузиазмом и оптимизмом продолжать работать над сложными задачами, где не получается добиться прогресса. Есть некоторое негласное осознание того, что часто путь к рабочему решению в продуктовом мире рождается через большое количество неудачных попыток.
Фидбек на чужую работу дается в очень аккуратной и уважительной форме. Подразумевается, что в Facebook работают умные люди, и если человек принял определенные решения, то на это были причины. Поэтому правильным подходом для дающего фидбек будет сначала понять мотивы принятых решений, задавая вопросы, а лишь потом донести свои идеи и предложения, понимая весь контекст происходящего. В первые месяцы я нередко давал фидбек, который был справедлив и релевантен, но имел столь прямую форму, что второй человек закрывался. Эффективность значительно падала.
В результате в компании получилось создать открытую, творческую и безопасную обстановку. Думаю, что цитата Эда Кэтмелла из Pixar неплохо передает ощущения от происходящего в Facebook.
“Originality is fragile. And, in its first moments, it’s often far from pretty. This is why I call early mock-ups of our films “ugly babies”. They are not beautiful, miniature versions of the adults they will grow up to be. They are truly ugly: awkward and unformed, vulnerable and incomplete. They need nurturing — in the form of time and patience — in order to grow. But the natural impulse is to compare the early reels of our films to finished films — by which I mean to hold the new to standards only the mature can meet. Our job is to protect our babies from being judged too quickly. Our job is to protect the new.”
Минусы работы в продуктовых командах в Facebook
Facebook — уникальная компания, близкая мне по духу и взглядам на многие вопросы. Мне повезло попасть в команду Workplace еще до публичного запуска продукта. Было интересно прожить ранние этапы формирования и становления сервиса, который теперь стремительно растет.
Но когда продукт доказывает свою состоятельность и интересность для Facebook (а для компании стоимостью $500 миллиардов число потенциально интересных продуктов невелико), то инвестиции в него начинают стремительно увеличиваться. А главная форма инвестиций в рамках Facebook — это количество людей, работающих над сервисом.
Я был вторым Data Scientist в Workplace. В момент моего ухода аналитическая команда уже была больше 20 человек. Рост команды привел к тому, что сфера ответсвенности постепенно сужалась и углублялась. В какой-то момент я понял, что работаю над маленьким кусочком пусть уже и большого бизнеса (на момент моего ухода более 30 000 компаний использовали Workplace, в том числе Walmart, Booking, Spotify, Starbucks, различные авиакомпании, банки, университеты, правительства).
Это, пожалуй, главный риск и минус работы в продуктовых командах крупной корпорации. Вы вполне можете шесть месяцев оптимизировать одну воронку. Это оправданная инвестиция на масштабе нескольких миллиардов пользователей, но не самый интересный профессиональный опыт (как минимум, для меня).
Стоит ли пытаться воспроизвести подобную культуру в других компаниях
Это неоднозначный вопрос. Процессы должны затачиваться под нужды конкретной компании, соответствовать ее этапу развития, целям и продукту. Описанная структура хорошо работает для Facebook, но не факт, что будет столь же эффективна для других продуктов и компаний.
Я бы рекомендовал ориентироваться на те проблемы, с которыми вы сталкиваетесь в компании, и пробовать для решения использовать отдельные понравившиеся кусочки из описанного выше.
Такой итерационный процесс с четким обратным циклом фидбека будет более эффективен, чем прямое копирование.
