Ваша команда не знает ключевых метрик продукта. Почему? Как это исправить?
23 марта, 2020
Редакция GoPractice
Когда я работал в Facebook, то у команды аналитики Workplace была классная традиция: еженедельная встреча команды начиналась с небольшой викторины.
Победитель прошлой недели готовил вопрос про какой-то ключевой показатель Workplace. Например, «Чему равна месячная аудитория продукта?» или «Сколько новых пользователей пришло за прошлую неделю?» или «Какая доля новых компаний достигает отметки в 10 пользователей?» или «Сколько мы заработали за прошлый месяц?»
Важным условием при формировании вопроса было то, что ответ на него можно легко получить с помощью метрик на дашборде команды.
Участники встречи должны были записать ответ на вопрос на бумаге. Ответить нужно было без помощи компьютеров, то есть по памяти. Тот, чей ответ был ближе всего к правильному, получал +1 балл в турнирной таблице, а тот, кто был дальше всех, терял 1 балл. По итогам полугодия определялся чемпион.
Я участвовал в пяти розыгрышах и выиграл три из них. Однажды к последнему туру у меня и у еще одного аналитика было одинаковое количество очков. Команда устроила нам финальный раунд, где мы должны были в блиц-формате ответить на пять вопросов. Я набрал на одно очко больше и выиграл кружку на фотографии ниже.
Я рассказал эту историю не потому, что хотел похвастаться победами (хотя и это тоже). Дело в том, что почти в каждом розыгрыше мы получали очень большой разброс ответов. Для меня это было неожиданно.
Во-первых, играли аналитики, которые большую часть времени работают с данными и должны в них неплохо ориентироваться. Во-вторых, это были аналитики в Facebook, компании с высокой культурой работы с данными, где у каждой команды есть четкие цели, есть дэшборд, доступный всем сотрудникам компании, все встречи начинаются с апдейтов по прогрессу по ключевым метрикам. Как эти люди могли так сильно ошибаться на несложных вопросах про продукт, над которым они работают?
Если вы проведете такую игру среди сотрудников вашей компании, то, скорее всего, будете сильно удивлены. У большинства людей будут очень далекие от реальности представления о том, как ваш продукт и бизнес выглядит с точки зрения цифр. У некоторых этих представлений не будет вовсе.
В этой статье обсудим, почему важно, чтобы участники команды держали в уме хотя бы примерные значения ключевых показателей продукта, почему этого не происходит и как этого добиться.
Если вы хотите глубже разобраться в том, как создаются, развиваются и масштабируются продукты, пройдите обучение в симуляторах GoPractice.
→ «Симулятор управления ростом продукта» поможет найти пути управляемого роста и масштабирования продукта. Вы построите модель роста и составите стратегию развития продукта (путь от 1 к N).
Еще больше ценных материалов и инсайтов — в телеграм-канале GoPractice.
Почему важно держать в уме значения ключевых метрик продукта
Каждый день разные участники команды принимают множество небольших решений, которые влияют на продукт. Эффективность этих решений во многом зависит от того, насколько представления людей об устройстве продукта соответствуют реальности, а также от того, насколько они эффективно используют эти знания в процессе принятия решений.
Вы можете возразить: «Зачем знать показатели продукта наизусть? Я же ведь всегда могу посмотреть на дашборд, написать SQL-запрос или попросить помощи аналитика».
В теории да, но на практике люди редко прерывают встречу или обсуждение, чтобы пойти изучать данные, особенно если решение не выглядит судьбоносным и очень рискованным. А в случае отсутствия фактов и данных в обсуждении ключевую роль начинают играть такие факторы, как способность продавить свое мнение, авторитет, убедительность и харизма.
На определенном масштабе команды отсутствие знания ключевых метрик не очень вредит эффективности. Руководитель команды еще может контролировать значительную часть проектов, корректировать приоритеты и ключевые решения при необходимости. Но при достижении определенного размера команды у руководителя остается намного более узкий арсенал инструментов. Он может задать вектор движения, он может мотивировать команду, большинство решений будут приниматься на местах. И в этой ситуации качество таких решений и эффективность всей системы будет уже сильно зависеть от реалистичности представлений членов команды о мире продукта.
Мы плохо представляем, как устроен мир, в котором мы живем
Ханс Рослинг в книге “Factfulness: Ten Reasons We’re Wrong About The World — And Why Things Are Better Than You Think» наглядно показывает, насколько далеки наши представления о мире от реальности. Он делится результатами своих исследований знаний разных групп людей о мире. Уже многие годы Ханс ездит по миру и проводит лекции, каждая из которых начинается с серии вопросов про окружающий нас мир. Это простые тестовые вопросы с вариантами ответа. Например:
«Какая доля девушек заканчивает школу в странах с низким уровнем жизни?»
«Где живет большая часть населения мира: в бедных или богатых странах?»
«Что произошло с долей людей, живущих в экстремальной бедности в мире за последние 20 лет?»
«Какова средняя продолжительность жизни в мире на сегодняшний день?»
«Каким будет население планеты к 2100 году, по прогнозам ООН?»
Доля правильных ответов на вопросы выше и другие подобные вопросы очень мала. Показательно то, что доля даже ниже, чем если бы люди отвечали на вопросы случайно.
Другой интересный факт: доля правильных ответов слабо коррелирует с уровнем образования и успешностью респондентов. Результаты опросов среди глав государств и руководителей крупнейших бизнесов в мире не сильно отличаются от результатов студентов университета.
На графике ниже изображены все страны мира. Ось X — среднее количество детей на женщину, ось Y — доля детей, которые выжили к 5 годам.
Вы можете четко выделить две группы стран, которые разделяет пропасть:
Развитые страны (преимущественно западные) с хорошей медициной и высоким уровнем образования. В таких странах низкая смертность младенцев и небольшое среднее количество детей в семье (1-3).
Развивающиеся страны (на ум сразу приходят страны африканского континента) с низким уровнем образования и плохой медициной. Им свойственны высокая смертность младенцев и большое среднее количество детей в семье (5-8).
Этот график отражает представления значительной части населения развитых стран об устройстве мира. Могу точно сказать про себя: представленные данные соответствовали моим ожиданиям.
Проблема в том, что график выше показывает ситуацию в мире в 1965 году, то есть 55 лет назад.
Если же посмотреть на текущее состояние дел, то никакой пропасти между развитыми и развивающимися странами уже нет. Скорее, есть градиент. Более того, огромная доля стран, которые раньше были в квадранте развивающихся, уже давно находятся в квадранте развитых стран на графике ниже.
Пропасть между представлениями людей об окружающем мире и реальностью такая же большая, как и пропасть между представлениями людей о продукте, над которым они работают, и реальным положением дел.
Ханс Рослинг приводит разные причины, которые объясняют наблюдаемые искажения в представлениях людей о мире: склонностью к упрощению, категоризации и обобщению, особенности человеческого восприятия, специфика работы медиа и прессы (непропорциональное внимание уделяется проблемам, острым и провокационным темам), устаревание данных в быстро меняющемся мире и многое другое.
Рекомендую прочитать книгу “Factfulness: Ten Reasons We’re Wrong About The World — And Why Things Are Better Than You Think». Там много интересных примеров, она дает хорошее представление о мире, в котором мы живем, и о том, куда он движется.
Как приблизить представления команды продукта к реальности
Я не уверен, что есть полное решение этой проблемы. Полное решение, возможно, и не нужно. Разные точки зрения людей в компании, разные взгляды на ценность продукта и перспективы его развития — необходимое условие творческого процесса. Но если вы все же хотите приблизить представления команды к реальности, то в этом помогут следующие шаги.
Сделать информацию про ключевые метрики продукта доступной
Доступность информации о ключевых метриках продукта подразумевает наличие у всех членов команды доступа к данным, создания публичных дашбордов для всех ключевых команд, покупку или разработку удобных инструментов и процессов для работы с данными.
Например, в Facebook любой сотрудник компании в любой момент мог посмотреть на дашборд любой команды. На этом дашборде были явно отражены ключевые метрики, их динамика и цели, к которым команда идет.
Другой аспект доступности данных — способность членов команды в нужный момент быстро их получить. Если людям нужно ждать два дня решения простой задачи из-за загруженности команды аналитики, то они естественным образом начнут принимать решения на основе интуиции. Сложно откладывать решение по определенному вопросу на два дня, если это блокирует пайплайн разработки продукта или любой другой важный процесс.
В Facebook менеджеры старались четко доносить до аналитиков, что они не являются интерфейсами к данным. Если получалось так, что мелкие ad-hoc задачи занимали больше 15% рабочего времени, то это проблема и ее надо решать на более структурном уровне.
Команда Workplace за время, которое я в ней проработал, выросла в несколько раз. На фоне роста и притока новых людей неминуемо росло число базовых вопросов про данные к команде аналитики. Когда объем таких мелких вопросов достигал существенного количества, обычно кто-то брал инициативу и проводил SQL Bootcamp. За несколько встреч новички узнавали, как хранятся данные, как делать простые запросы к данным, где можно найти шаблоны запросов. Некоторые же мои коллеги даже делали специальные инструменты, которые позволяли легко получить ответ на самые популярные вопросы, и в ответ на релевантные вопросы отправляли ссылку на них.
Создать процессы, которые будут помогать превращать информацию в знание
Дашборды, инструменты, обучение людей навыкам получения данных — это фундамент. К сожалению, доступность данных не превращает их в знание в головах членов команды. Один из способ превратить доступную информацию в знание — создание специальных процессов.
Ниже я поделюсь тем, что, с моей точки зрения, хорошо работало в Facebook.
Все командные регулярные встречи начинались с быстрого апдейта по целям и метрикам. Учитывая, что все члены команды были обычно сильно мотивированы достичь цель, то этот формат вызывал живой интерес и работал хорошо. Подробнее про культуру Facebook можно прочитать здесь.
Когда я в беседе делюсь этим примером, то часто слышу аргумент, что для нашей команды апдейт метрик каждую неделю не имеет смысла, потому что метрики обычно за неделю принципиально не меняются. Но смысл этого процесса не в том, чтобы показать изменение метрик, а в том, чтобы еще раз напомнить людям, где мы находимся, куда и почему мы идем. Это способ превращения информации в знание.
Неожиданные колебания метрик, запуски, продуктовые изменения и эксперименты обязательно изучались, а результаты обязательно публиковались на всю команду. Например, для экспериментов был специальный канал, где анонсировался каждый новый эксперимент с описанием, гипотезой, целевыми метриками. В этой же группе люди делились результатами и выводами по всем закончившимся экспериментам. Культура документирования знаний позволяет со временем накапливать и структурировать важную информацию. Такая база знаний — прекрасный актив, который помогает легко находить нужную информацию, а также позволяет новым членам команды быстро набрать экспертизу в продукте и улучшить его понимание.
В Facebook у нас также были регулярные еженедельные встречи с обсуждением результатов экспериментов. На этой встрече все, у кого были активные эксперименты, делились результатами с помощью стандартного шаблона, после чего следовала общая дискуссия с представителями команды роста, аналитики и продукта.
Отдельно хочется отметить важность создания эффективной культуры обсуждения разных вопросов в команде, где гипотезы и факты четко разделяются. Если кто-то делает какое-то утверждение или предложение, то оно должно быть подкреплено результатами UX исследования или данными. Если же человек выдает свою гипотезу за факт, то такое важно уметь замечать и на это явно указывать.
Это лишь несколько примеров, которые работали в Facebook. Все компании разные, и наверняка вам надо будет адаптировать процессы выше или придумать новые, которые интегрируют данные в процессы принятия решений в вашей компании или команде.
В заключение
Все еще сомневаетесь, что ваши коллеги не знают ключевые показатели продукта, над которым работают? Просто сыграйте с ними в следующую игру: подготовьте 10-15 вопросов про ключевые метрики продукта или компании, попросите всех ответить на них с выключенными компьютерами и нарисуйте распределения ответов.
После этого можете и дальше проводить такую игру с определенной регулярностью. Это решит сразу несколько задач:
Это хороший способ измерять то, насколько представления вашей команды о продукте и бизнесе далеки от реальности, и какова динамика вашей команды в этом вопросе.
Это также поможет мотивировать людей периодически самостоятельно проверять дашборды с ключевыми метриками.
Вы также заметите, как люди начнут опираться в обсуждениях и принятии решений на те метрики, которые участвовали в игре.
Если вы хотите глубже разобраться в том, как создаются, развиваются и масштабируются продукты, пройдите обучение в симуляторах GoPractice.
→ «Симулятор управления ростом продукта» поможет найти пути управляемого роста и масштабирования продукта. Вы построите модель роста и составите стратегию развития продукта (путь от 1 к N).