Привет! Меня зовут Анастасия Лестова, я UX-исследователь и Product Discovery Lead в Контур.Маркировке — продукте, помогающем бизнесу автоматизировать работу с государственной информационной системой мониторинга оборота товаров.
Моя команда ориентирована на управление разработкой на основе данных: мы оцениваем успешность фич и отслеживаем пользовательские проблемы по сигналам из метрик, менеджеры разработки управляют ресурсами также с оглядкой на процессные метрики. Разработка — отлаженный управляемый механизм, царство математически детерминированной рациональности. Но на основании чего разработка принимает решения? Да, на основании исследований, а их принято считать актом выхода в зону неопределённости, где на выручку приходят эмпатия и интуиция. Значит ли это, что исследования — стихийный процесс, пользу от которого нельзя измерить, усилить и направить в нужном направлении? Вовсе нет. В статье я хочу поделиться своим подходом к оценке эффективности исследовательских процессов и степени их влияния на разработку.
Существующие подходы
Запрос на оценку эффективности процесса дискавери родился внутри моей команды, которая хотела, чтобы инсайты с дискавери помогали эффективно менять продукт: делать его более привлекательным для новых клиентов и комфортным для текущих. Хотелось также спустя время объективно оценить, получается ли это. Но как конкретно это сделать, понимания не было. Бизнесу хотелось увидеть, как новый для продукта опыт повлияет на ключевые метрики: процент продлений и подключений.
Я вовремя обратила внимание команды, что при всей ценности этих метрик, они не про дискавери как процесс. На продления и подключения клиентов влияет множество факторов. Получается, бизнес- и продуктовые метрики лишь косвенно отражают влияние дискавери на продукт, и их нельзя взять за метрики эффективности процесса. Почему? А потому что у дискавери команды нет инструментов прямого влияния на бизнес-метрики. В реальности процесс доставки ценности исследований гораздо длиннее и бизнес получает отложенный эффект.
Я посмотрела на опыт коллег по рынку, чтобы разобраться, как принято оценивать эффективность Product Discovery и оказалось, что готового решения нет:
Исследования в тренде, и иногда их оценивают скорее как гигиенический фактор или декоративный элемент. Как будто бы польза от этой деятельности сама собой разумеется.
Есть те, кто предпочитает оценивать эффективность исследований по метрикам активности: считают число проведенных исследований, подтверждённых (??♀️) гипотез или даже интервью. У кого много, тот и молодец. Мы понимаем, что эти цифры указывают лишь на интенсивность работы или её имитацию.
Наконец, бизнес и продуктовые метрики, то, с чего начинала моя команда. С одной стороны, именно в них мы видим конверсию исследовательской деятельности в реальную ценность для бизнеса. С другой – это видение подвержено множеству искажений и не поможет найти бутылочное горлышко на пути ценности. Что, если исследования великолепны, но по каким-то причинам разработка не следует их рекомендациям? А если наоборот: исследования не дают никакой информации и ценности, а разработка генерирует её самостоятельно? И в первом, и во втором случае бизнес-метрики могут и проседать, и расти.
Собственное решение
Итак, мне не подошло ни одно из традиционных решений, потому что я намеревалась не просто вписаться в успех продукта, но реально продемонстрировать влияние Product Discovery на Delivery. Мы должны точно понимать, меняем ли продукт, а если нет, что нам мешает. Работая в плотной связке с продактами, я сформулировала для нашей команды 7 эффективных метрик, которые помогают оценивать качество исследований и степень их влияния на продукт, в том числе, конвертацию в задачи Delivery. Разберём их поэтапно. И начнём с тех, что говорят о качестве самого исследования и нашей способности донести его результаты до команды продукта.
Качество исследования и применение результата
Успех исследования
Это первая метрика. Мы с дискавери командой долго дискутировали над тем, что нужно вложить в это понятие, и пришли к тому, что успешное исследование должно давать ответы на вопросы или явно валидировать гипотезы, которые мы получили на входе. Также важно, чтобы ответы были однозначны и имели прикладную ценность. Мы не исследуем что-то лишь ради любопытства и интереса, а копаем в том направлении, где можно что-то сделать.
Неуспешные исследования есть в опыте каждого. Проблемы тут могут быть самые разные: от ошибок в выборе аудитории до неэффективных гайдов. Ошибаться нормально, главное фиксировать такие кейсы и работать с ними.
Мы используем эту метрику как оценку исследования, а не исследователя. Неуспешные исследования не влияют на чей-то грейд или премии, и это важный момент. В таких условиях признать неуспех не так страшно, и мы можем продуктивно анализировать ошибки и не повторять их в будущем. Это главная ценность этой метрики.
Применение результата
Следующая метрика — применение результата. Тут тоже все довольно просто: мы либо применили в деле всё, что накопали в исследовании, либо какую-то часть. Либо не сделали ничего. Так тоже бывает.
Важно делать это видимым как для самой дискавери-команды, так и для бизнес-команды, оценивающей эффективность. Эту видимость нам и дает метрика. Если результаты не применяются, мы ищем причины со стороны качества исследования (см. выше), подходов заказчиков к работе с гипотезами и бэклогом, и других внутренних и внешних факторов, ограничивающих движение инсайтов с дискавери в бэклоге разработки. Если мы можем устранить блокеры, например, повысив качество исследований или изменив систему приоритизации бэклога разработки, мы делаем это. Если же мы сталкиваемся с непреодолимыми барьерами, а в Контур.Маркировке такими является пласт инфраструктурных задач по поддержке требований законодательства, то мы учитываем это при работе с исследовательской стратегией => берем в работу те исследования, с результатами которых точно сможем эффективно работать. Мы не исследуем в стол.
Новые гипотезы
И финальная метрика в этом блоке — число новых гипотез. Мы измеряем их в абсолютных значениях. Просто указываем число новых гипотез как со стороны исследователя, так и со стороны заказчика.
Мы считаем, что в исследованиях важен широкий взгляд, поэтому стремимся не только валидировать входящие гипотезы, но и прирастать знанием о пользовательском мире, на основании которого неизбежно рождаются новые гипотезы. Таким образом, дискавери команда работает не только на проверку гипотез, приходящих извне, но и генерирует свои.
Вот первые три метрики, которыми мы оперируем в основном в оценке эффективности исследования и работы заказчиков.
Влияние на разработку
А дальше самое интересное. Метрики, демонстрирующие влияние на разработку.
Чтобы смысл выбранных метрик был очевиден, стоит посмотреть на один из кейсов в работе Контур.Маркировки, который наглядно демонстрирует это влияние и сделает хорошо видимыми наши метрики.
С точки зрения обывателя, маркировка – это просто «ещё какой-то кьюаркод». Фактически же маркировка оперирует двумерными штрихкодами Data Matrix, которые могут объединяться в агрегирующие коды со множественным вложением, например, наборы.
Функциональность работы с наборами была реализована в Контур. Маркировке давно, тогда в виде mvp, и была сопоставима с функциональностью, которую предоставлял государственный сервис Честный знак. На заре маркировки наборов делали немного, сценарий не был сильно популярен в сервисе и всех всё устраивало.
Но всё изменилось с приходом в маркировку товаров лёгкой промышленности, которые нередко реализуются в виде наборов, в том числе, на маркетплейсах. Активность в сценарии резко возросла, появились и обращения в поддержку. Со временем стало понятно, что базовых возможностей недостаточно для быстрой и эффективной работы с большим объёмом наборов. Делать их было слишком сложно и долго. Мы понимали это и без специального исследования, поскольку активно работаем с обратной связью пользователей, поступающей из разных каналов.
Цикл работы с созданием набора начинался задолго до нашего продукта: с регистрации набора в нацкаталоге и получения GTIN, потом нужно было отдельно заказать коды на наборы, на единичные товары, нанести на товары этикетки, наполнить наборы данными о единицах, подать отчёт о нанесении и ввести в оборот. Устать и запутаться можно лишь на перечислении шагов, а ведь нашим клиентам приходилось встраивать эти 7-8 шагов в свои бизнес-процессы и повторять их порой ежедневно.
Решение о редизайне фичи было принято, и команда имела предварительный план реализации. Правда, работы предстояло много.
Наш продакт решил сделать паузу и провалидировать концепцию на реальных пользователях — мы начали исследование, в котором собрали масштабную фактуру по проблеме и….
… узнали, что необязательно делать все задуманное. Глубоко изучив реальный пользовательский сценарий, мы поняли, что в работе с созданием карточки набора в Национальном каталоге нет особых сложностей и делают это не так часто. А ещё, что пользуясь лазейкой, любезно предусмотренной ГИС МТ, производители не наносят этикетки на вложенные в набор единицы, когда набор неделим (а это почти всегда так).
И, конечно, наборы не одинаково востребованы в разных товарных группах. Например, автошины в наборы обычно не собирают.
Выглядит так, будто исследование показало, что мы можем не делать половину бэклога. На самом деле исследование сфокусировало нас и позволило расставить приоритеты: что действительно болит и болит сильно, а в каких моментах пользователи не заметят наших усилий.
Начинали решать не конкретную проблему, а вообще весь этот сценарий пытаться как-то уложить в задачу. Естественно, из-за этого она становилась сильно больше… А исследование как раз достаточно чётко показывало, где ключевая проблема, и что конкретно её сейчас надо решить. Всё остальное, что погранично, это не 100% уже важно…
продакт-менеджер Контур.Маркировки
Сфокусировавшись на ключевых задачах, мы существенно сэкономили ресурсы. Если исходный бэклог на редизайн функциональности наборов оценивался в 39SP, то скорректированный исследованиями уже в 13SP, то есть эффект от учёта инсайтов дискавери это — сокращение затрат на разработку в 3 раза! И, что не менее важно, мы быстрее доставили пользователям ценность. Теперь наборы в Контур.Маркировке можно создавать примерно вдвое быстрее.
Пример работы с наборами помогает нам увидеть применение сразу нескольких метрик влияния дискавери на деливери.
Добавление задачи
Первая метрика в блоке влияния на разработку — добавление новой задачи в бэклог.
Иногда это происходит, иногда нет. Например, при первом заходе в исследование наборов мы узнали, что для их реализации на маркетплейсах пользователям требуется клеить код маркировки не только на упаковку набора, но и на дополнительную упаковку для маркетплейса. Скопировать код было сложно, и мы принесли в бэклог задачу на реализацию автоматического дубликатора этикеток. Он уже работает и помогает дополнительно монетизировать сервис.
Изменение приоритетов
Нередко бывает, что аспекты, затронутые исследованием, уже отражены в задачах в бэклоге, но исследование, как в примере с наборами, помогает уверенно определить их приоритет.
Отмена задачи
Если же мы поняли, что ценности в какой-то функциональности или изменении не будет вовсе, задача может быть отменена.
Релиз на прод
И наконец, метрика, которая позволяет достроить воронку до конца — это наличие задачи на проде. Сделали ли мы то, что намеревались? Потому что можно бесконечно перекраивать бэклог, но по каким-то причинам не доводить до реализации.
Итак, мы обсудили все метрики, которыми оперируем для оценки эффективности исследований и их влияния на разработку. Это довольно наглядная и эффективная система, в совокупности они дают нам полную картинку.
Барьеры
Однако, как у всего в этом мире, у нашего набора метрик есть недостатки:
По части метрик есть вероятность получить недостоверную картинку за счёт социально желательных ответов. Не всегда удобно заявлять, что исследование коллеги неуспешно или признаваться, что ты сам не сделал ничего, чтобы применить результат.
Некоторые из метрик мы не можем оценить сразу по завершении исследований. Например, в день демо мы точно ещё не применяли результат. К оценке таких метрик приходится возвращаться, а это требует усилий и может приводить к искажениям отложенных решений.
Так как речь идёт о субъективных оценках участников процесса, мы не можем определять статус метрик автоматически и можем лишь облегчить сбор и анализ данных.
Применение результата
Как всё это работает у нас? Метрики мы фиксируем прямо в таск-трекере там же, где двигаем задачи дискавери. Это совместная работа заказчика и исследователя. Если что-то отклоняется от нормы, фиксируем комментарии и обсуждаем, без этой аналитической и коммуникационной работы цифры просто не имеют смысла.
Ну и, наконец, правда жизни. Что же у нас получается? Не буду разбирать все наши результаты, посмотрим на фокусное — влияние исследований на разработку.
За прошлый неполный год 52% исследований принесли в разработку новые задачи и 41% повлияли на приоритеты. Много это или мало? И что, собственно, с того?
По большому счету ничего. У этих метрик нет бенчмарков, норму определяете вы сами, опираясь на цели и особенности продукта, внешние и внутренние ограничения. Например, мы понимали, что наша норма сильно ниже 100%.
Во-первых, в нашем процессе имеют место не только продуктовые, но и другие виды исследований, например, маркетинговые. По их итогам нечасто нужно что-то разрабатывать, результаты применяются по-другому.
Во-вторых, как я говорила ранее, в Контур.Маркировке в силу специфики продукта и зависимости от законодательных трендов много задач-обязательств, которые вытесняют задачи развития.
На все эти вещи нужно делать поправку при определении вашей нормы.
Здесь метрики не самоцель, это инструмент для поиска точек роста.
Год назад мы исследовали не всегда то, с чем реально могли работать. Увидев это через метрики, мы осознанно пошли в построение исследовательской стратегии, которая учитывает цели продукта, ресурс разработки и внешние факторы. В итоге цифры заметно подросли: 67% исследований принесли в разработку новые задачи и 53% повлияли на приоритеты.
Метрики помогают нам вовремя менять курс, брать в работу исследования, результаты которых мы сможем быстро взять в разработку, а значит, скоро увидим движение и в продуктовых метриках.
Кроме того, мы используем метрики для поиска точек роста в команде. Причём речь идёт не только о росте компетенций исследователя и повышения качества исследований, но и про коммуникацию между разными ролями команды и компетенции заказчиков. Это может быть контринтуитивно, но заказчик сильно влияет на результаты в метриках: от качества входящего запроса и тактики работы с результатами зависит многое. Мне, как лиду, сигналы из метрик позволяют распределять задачи в соответствии с компетенциями исследователей и собирать эффективные пары заказчик-исследователь.
Анализируя данные метрик по параметрам применения результата, попадания в бэклог и на прод, мы видим воронку доставки ценности исследований в продукт. Становятся видны узкие места, которые могут расширяться как за счёт процессных изменений, так и за счёт кадровых. Например, мы можем увидеть, что исследуем быстрее, чем команда разработки может реализовывать фичи. Ситуацию можно сбалансировать, сократив ресурс дискавери или расширив команду разработки. Конкретные решения зависят от ситуации.
Точками роста для процесса дискавери в моей команде стали:
метрики процесса, которые позволяют вовремя отыскать узкие места,
работа над этими проблемными точками,
и, наконец, не ситуативное, а масштабное планирование дискавери.
Поделитесь своим опытом, что помогает вам выстраивать эффективные исследовательские процессы и отслеживать ваше влияние на разработку и бизнес?
Больше про UX-исследования — в телеграм-канале Сдоба.