Сегодня моя цель – коротко рассказать о подходах data-informed продуктового менеджмента, который я исповедую и попытаться заинтересовать вас в использовании его базовых инструментов в ваших продуктах.
Короткий дисклеймер – я пришла в продуктовую разработку из проектного менеджмента в аутсорсе. Для меня стало неожиданностью, что в то время как продуктовым метрикам уделяется пристальное внимание, процессные и командные часто незаслуженно уходят на задний план.
Для себя я сформулировала, что измерения успешности продукта состоит из трех блоков:
— счастье пользователей;
— успешность (качественная и количественная) итераций и релизов;
— счастье команды.
Счастье пользователей
Часто его мы пытаемся измерить так подробно и со стольких сторон, что анализ полученной информации превращается в настоящую пытку.
Поэтому в проектах мы попробовали использовать легковесный фреймворк HEART и подход Цели-Сигналы-Метрики, который придумали ребята из Google, и который здорово помогает сфокусироваться на по настоящему важных для UX продукта вещах.
HEART разделяет все метрики на 5 категорий
Happiness (Счастье)
К метрикам счастья относятся, к примеру:
— пользовательское удовлетворение;
— ощущение, что продуктом легко пользоваться;
— net promoter score.
Engagement (Вовлечение)
К примеру:
— количество визитов пользователя в неделю;
— количество фото, загружаемых юзером в день;
— количество лайков и шэров.
Adoption (Принятие)
К принятию можно отнести:
— обновления до новой версии;
— созданные пользователем подписки;
— покупки сделанные новыми пользователями в приложении.
Retention (Возвращаемость)
Конкретными метриками здесь могут быть:
— количество пользователей, остающихся активными с течением времени
— churn
— повторные покупки
Task Success (Успех ключевых задач)
Ключевыми задачами могут, к примеру быть:
— успешные поиски;
— время загрузки фотографии;
— полностью заполненный пользователем профиль.
Необязательно пытаться придумать важные для вашего продукта метрики во всех этих категориях. HEART — о том, чтобы выбрать 1 или 2 по настоящему важных и на какой-то период сконцентрировать внимание именно на них.
К примеру, в энтерпрайз продукте, который пользователи так или иначе должны использовать каждый день, вовлечение может быть не так важно. Зато счастье и успех ключевых задач – это то, на чем стоит сконцентрироваться как минимум на стартовом этапе.
HEART позволяет легко «конвертировать» важные для вас категории в значимые метрики, которые можно непосредственно отслеживать.
Все, что вам нужно, это начать не с брейнсторминга интересных штук, которые вы бы хотели трекать в проекте или который позволяет отслеживать новая хитрая система продуктовой аналитики. Вам нужно начать с более высокоуровневых штук: определиться, какие цели преследует ваш проект.
Goals-Signals-Metrics
Как бы капитански это не звучало, иногда бывает не так просто сформулировать цели продукта, с которыми однозначно согласна вся команда, и в этом неплохо помогает HEART. Также здесь важно не допустить типичную ошибку – не формулировать цели в терминах уже существующих метрик.
К примеру, одна из наших целей в моем текущем продукте – заинтересовать пользователей рекомендациями и сделать так, чтобы они проводили в их изучении больше времени.
Часто одной цели могут потенциально подходить несколько сигналов, поэтому на этапе их определения полезно поанализировать и понять, какие из них легче или сложнее трекать, какие более чувствительны к изменениям в вашем продукте и определить оптимальный для вашей цели.
Сигнал в этом случае – количество времени, которое пользователи взаимодействуют с рекомендациями. Метрика – это количество минут на пользователя, потраченных на изучение рекомендаций.
Описанный процесс помогает естественным образом приоритезировать метрики и избавиться от лишнего шума в ваших измерениях. Это своеобразная бритва Оккама, которая со стороны выглядит очень тривиальной, но часто наталкивает на неожиданные выводы и действия.
А как же процесс?
Но измерения продукта, – это еще не все. И хотя HEART дает многое для того, чтобы понять, как сделать продукт лучше для наших пользователей, для долгосрочной успешной работы нам не хватает понимания того, все ли у нас хорошо с процессом и командой.
Часто в продуктах я сталкиваюсь с тем, что эти вопросы замалчиваются, потому что вроде бы все и так неплохо, у людей горят глаза, мы тут делаем классную штуку, да и вообще это все какое-то старперство.
Но в любых системах склонна накапливаться энтропия. И если сегодня вы поставляете на рынок классный продукт, но не думаете о том, почему каждый ваш релиз происходит чуть дольше, чем предыдущий, а люди начали уходить с работы чуть раньше, в вашем проекте может зреть бомба замедленного действия.
Очередная жуткая тривиальность, о которой все знают, но которую очень легко игнорировать: time-to-market, скорость реакции на рынок и действия конкурентов критично важны для успеха продуктов.
Отсутствие внимания к тому, как развивается ваш технический долг, насколько успешны ваши итерации, какие стратегические проблемы копятся в вашем процессе, приводят к тому, что ваши проекты превращаются в попытку запрыгнуть в уходящий трамвай.
Мой маленький бутстрап процессных метрик состоит из трех частей. Их легко мерить, и если вы еще не делаете этого, я призываю вас попробовать подумать над собственным набором метрик, которые отражают прозрачность и здоровье вашего процесса. Конкретные примеры метрик могут не соответствовать тому, что важно измерять в вашем проекте, поэтому будьте осторожны с буквальным применением этого блока.
Количественные метрики релиза
Тут все просто. Чтобы понять, как у вас дела, достаточно мерить скорость vs качество вашей работы.
Метрикой скорости может служить непосредственно скорость команды или составная метрика: пользовательские истории, сделанные в течение этой итерации/не завершенные, но запланированные/перенесенные в следующую итерацию.
Метриками, отражающими не ущемляете ли вы качество в ущерб скорости могут быть:
— количество дефектов, найденных за итерацию/vs пробравшихся в итоге на продакшн
— распределение дефектов по типам/компонентам и источникам
К тому же такая штука здорово помогает на раннем этапе вылавливать технологические риски проекта.
Мне довелось работать в проекте, где основным источником дефектом стал внешний компонент, использовавшийся командой. В тот момент, когда это обнаружили, – он был просто досадной неприятностью, и от него решили избавиться, чтобы не портить статистику.
Где-то через полгода было довольно печально наблюдать за соседними командами, которые начали в спешке отказываться от этого компонента, который к тому времени превратился для многих в настоящий блокер к дальнейшему развитию продуктов.
Качественные метрики релиза
— отношение количества сделанных пользовательский историй к общему числу историй в проекте;
— отклонение от запланированной даты релиза;
— технический долг.
Наверняка многие из вас сталкивались с проектами, о которых говорят, что «да это легче с нуля написать, чем поддерживать». Виной этому часто технический долг, разроссшийся до невероятных размеров. Если вы не знаете о нем и не менеджите его сегодня, вполне возможно, что завтра он сделает вам больно. Это кажется потрясающе очевидным в engineering-centered компаниях, но я видела столько случаев, когда бизнес и продукт настолько доминируют над здоровыми инженерными практиками, что нельзя было не упомянуть этот пункт.
И, наконец, качественные метрики.
В первую очередь – это простой список того, что было хорошо, что стоит улучшить. Тут важно сказать, что это не просто метрика, которую надо отслеживать. Это процесс непрерывных улучшений, который нужно постараться внедрить на своем проекте. Если мы постоянно не стараемся стать лучше, то постепенно мы становимся чуть хуже, чем были раньше. Как минимум потому что окружающий мир не стоит на месте.
Список того, что стоит улучшить может включать в себя абсолютно любые вещи, – от добавления в ваш код стайл новых гайдов до покупки удобных стульев для команды. И это не просто – собрались, поговорили и разошлись, – а план конкретных действий, которые нужно сделать для улучшения.
Team is the King
И о последней, самой важной, как на мой взгляд, части отличного продукта.
Простой тест – знаете ли вы, что заставляет каждого человека из вашей команды каждое утро приходить на работу? А знаете ли, что заставляет сцеплять зубы и думать «как же они меня достали, еще раз и пойду писать заявление»?
Если вы, как и я, считаете, что без мотивированной и удовлетворенной команды продукт в долгосрочной перспективе не может стать полностью успешным, то самое время разобраться с этими вопросами.
Каждый раз, когда я говорю подобные штуки, люди начинают спрашивать, – «Ну и как узнать такие интимные вещи? А вдруг мой коллега хочет уйти из нашей большой компании в тех стартап или скопить денег и переехать в Таиланд? Как же он мне об этом расскажет?»
Но ведь вы, правда, не хотите узнать об этом в тот момент, когда он положит заявление на стол? Поэтому я предлагаю начать с анкеты, которую разработал Макс Ландсберг и которая позволяет получить кучу важной информации, о том, что драйвит и расстраивает вашу команду, и дальше понять, что с этим делать. И обязательно прочитайте «Motivate Me Right» Стаса Давыдова, если по какой-то причине вы этого еще не сделали.
Обратная связь
В любом продукте на разных этапах развития мы стремимся получить максимум фидбека от пользователей. Он служит своеобразной путеводной звездой и часто помогат понять, на правильном ли мы пути.
Личный профессиональный фидбек внутри команды – это такая же путеводная звезда. Если вы регулярно не получаете фидбек о вашей работе от вашей команды и не даете его тем людям, с которыми вы вместе создаете продукт, в вашем продукте могут копиться проблемы, которые вы даже не осознаете.
На одном из проектов мне довелось наблюдать за уходом талантливейшего разработчика.
Забавно, но о нем никто из менеджмента за 2 года работы не узнал, что этот парень по настоящему нуждался в профессиональном признании, очень трепетно относился к выступлениям на конференциях, наставничеству новичков, участии в оупенсорсных проектах. Участие в конференциях все время откладывалось, то дедлайны в проектах, то денег маловато, чтобы поехать на Java Day где-то в штатах, и через 2 года он не выдержал и ушел работать в крупную компанию tech евангелистом.
Я уверена, этому разработчику было что сказать своим менеджерам в качестве фидбека. И таких примеров море. Фидбек помогает получить и дать важную для развития и сохранения команды информацию, и ею не стоит пренебрегать. Вы можете пойти еще дальше и попробовать собирать фидбек на уровне нескольких команд или большого проекта. Почитайте, как это делает Valve, это вовсе не так сложно, как может показаться.
Итого
1. Работая с продуктом, помните, что данные – это всего лишь инструмент. Ориентируйтесь на цели, а не на циферки в статистике.
2. Не забывайте, что ваш продукт зависит и от здоровья ваших процессов. Они заслуживают вашей любви и внимания.
3. Команда заслуживает их еще в большей степени. И даже если в вашей компании описанными мной вещами занимается hr или функциональный руководитель, вы должны быть тем человеком, которому действительно важно, что на этом фронте у вас все хорошо.
Автор: meaou
