Привет! Меня зовут Александр Токмаков, я Product Lead в СберМаркете. Сегодня я хочу обсудить с вами приоритизацию. Я считаю, что это один из главных скиллов в работе продакта, а если ты работаешь в крупной компании — точно главный.

Например, у нас более 50 продуктовых команд и в 2022 году мы провели 700+ экспериментов. Если на таком масштабе система приоритизации даёт сбой, можно уйти совсем не в ту сторону. Зато, если все работает правильно, положительный эффект оказывается действительно ощутимым. Именно поэтому я полюбил приоритизировать, разобрался во фреймворках и выработал свою систему, которая показывает крутой результат: >30% наших фичей улучшают продукт.

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

1. Фреймворки приоритизации. Какие существуют и для каких ситуаций лучше подходят.

2. Что мы используем в нашей команде. Какие практики внедрили и какие результаты это даёт.

3. Типичные ошибки в приоритизации (на моем опыте и опыте коллег) и как их можно пофиксить. Поехали!

Вступление

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

Представьте, что вы продакт менеджер в сервисе такси, и вам нужно приоритизировать разработку трёх фич.

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

Итак, барабанная дробь, и побеждает…(кликните, чтобы увидеть ответ) никакая :)

Потому что для приоритизации нам не хватает критически важного контекста:

1. Цель для бизнеса. Что хотим улучшить: конверсию, удержание (retention), средний чек или ROI?

2. Есть ли пользовательская проблема? Может быть пользователей все устраивает?

3. Сколько будет по времени разрабатываться та или иная фича? 

Без этих вводных обоснованное сравнение сделать нельзя, поэтому при таких условиях ни один из трех вариантов не является оптимальным.

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

Но как эффективнее всего это сделать? Тут в игру вступают фреймворки.

Фреймворки приоритизации

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

1. Источник данных. Внешние vs внутренние. Когда вы работаете с таким большим продуктом, как СберМаркет, вы очень много оперируете внутренней информацией — то есть знаете, как пользователи уже сейчас взаимодействуют с приложением. 

2. Вид данных. Количественный vs качественный. Если вы небольшой продукт, то скорее всего будете работать с качественными данными. Это частый кейс, например, для B2B. В случае с B2C-рынком, к которому относится СберМаркет, вы будете работать в основном с количественными данными. Очень часто используется А/Б тест, где на цифрах проверяется валидность той или иной гипотезы. 

Дисклеймер: Фреймворки, которые мы используем в СберМаркете, сложно будет в явном виде применить для enterprise B2B-продукта, хотя некоторые идеи точно окажутся полезными. Если же у вас продукты для B2C, C2C, B2B2C и acquisition SMB, то вы попали в нужное место.

Используя два параметра данных, можно нарисовать систему координат. По оси Y сверху расположим фреймворки, которые полагаются на количественные данные, а снизу — на качественные. По оси X — слева на внешние данные, а справа на внутренние. 

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

Kano Model — внешние + количественные данные

Этот фреймворк пришел из маркетинга. Суть проста — проводится опрос клиентов для разделения еще не существующих фич на 4 группы:

• необходимые — без них никто просто не воспользуется продуктом, о высокой удовлетворенности речь даже не идет; 

• качественные — их улучшение приводит к линейному росту удовлетворенности;

• привлекательные — неожиданные приятные бонусы, без которых можно было бы обойтись, но их наличие порадует пользователей;  

• незначительные — не влияющие на ценность продукта. 

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

Value vs Cost — внутренние + количественные данные

Простой и интуитивно понятный метод определения приоритетов. Фичи оцениваются по их ценности и стоимости реализации. Ценность измеряется в условных единицах, и может опираться на любые параметры, которые вы оптимизируете — от снижения оттока клиентов до увеличения среднего чека. Стоимость можно оценить, например, в человеко-часах. 

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

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

MoSCoW — внешние + качественные данные

Фреймворк MoSCoW позволяет определить, что важно для стейкхолдеров и клиентов с помощью разделения фич на четыре категории: Must (критически необходимые), Should (важные), Could (полезные, но не критичные), и Won’t (необязательные).

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

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

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

Какие фреймворки мы используем в СберМаркете

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

ICE & RICE

Это два похожих, но немного отличающихся фреймворка.

RICE придумали в компании Intercom для улучшения собственных внутренних процессов принятия решений. Хотя команда разработчиков знала и использовала множество других моделей приоритизации, они не могли найти метод, который бы идеально подходил именно для их уникального набора фич.

Методологию ICE популяризовал Шон Эллис, который известен тем, что помогал расти таким компаниям, как DropBox и Eventbrite, а также введением термина Growth Hacking. Изначально ICE-баллы предназначались для определения приоритетности экспериментов по росту, но их можно использовать и для обычных продуктовых фич.

На карте фреймворков ICE & RICE можно разместить в правой части по центру:

Давайте разберем, из чего же состоят эти аббревиатуры.

• Impact — это эффект, который мы ожидаем от этой фичи, когда мы ее выкатим. Измеряется обычно шкалой либо от 1 до 10, либо шагами 0,25, 0,5, 1, 2, 3. У нас в СберМаркете Impact — это шкала прироста GMV. Мы считаем его с помощью калькулятора, который был создан нашими продактами совместно с финансовым отделом. Так, любой член команды (обычно это продукт менеджер или аналитик) может быстро подсчитать эффект от внедрения фичи. Сейчас мы сознательно не рассматриваем те, которые приносят <20 млн GMV.

• Confidence — это то, насколько мы доверяем и верим, что этот Impact случится. Обычно измеряется в прогрессивной шкале от 0 до 10.

Чуть подробнее остановимся на самом холиварном параметре — Confidence. Почему он холиварный? Потому что он различается от компании к компании, от команды к команде и от продакт-менеджера к продакт-менеджеру. То есть, если мы возьмем одну задачу и предложим ее двум разным менеджерам, у них будет разный Confidence по одной и той же задаче. 

Почему так происходит? У всех разная насмотренность, опыт и интерпретация имеющихся данных.

Мы в СберМаркете присваиваем Confidence баллы от 1 до 10:

•  1 — есть только уверенность продакт-менеджера и больше ничего;

• 10 —  эта инициатива уже в А/Б тесте и показала результат. 

Промежуточные этапы очень сильно варьируются в зависимости от того контекста, который вы имеете. В своей команде мы используем в работе фичи, где Confidence выше 5.
Что еще влияет на повышение балла, кроме А/Б тестов? На самом деле, факторов очень много — все они перечислены на картинке ниже:

Набрать высокий балл по Confidence для фичи довольно непросто, как и для нас собрать всю необходимую информацию. Поэтому для получения данных в Med-Low и Medium сегменте в СберМаркете есть выделенная команда UX-research менеджеров. Об их работе мы подробно расскажем в следующих статьях.

• Ease (Effort) — это то, насколько просто это сделать в реализации или обратное от усилий, которых нам стоит приложить для того, чтобы это сделать.

• В СберМаркете мы закладываем, что работа будет выполняться командой 1-1-1 (1 разработчик фронт, бек и QA). Обычно мы измеряем Ease/Effort в прогрессивной шкале в неделях: 0,5 (1 неделя), 1 спринт, 2 спринта (месяц), 3 спринта (1,5 месяца), 6 спринтов (квартал) и > 6 спринтов. Тут можно использовать такой же подход как и в Planning Poker. Подробнее про него можно почитать здесь — это классный метод, помогающий избежать когнитивных искажений.

На этом параметры ICE заканчиваются. Подводя итог, этот фреймворк больше подходит командам с небольшим и относительно молодым продуктом, по которому еще не накопилось много внутренних данных и аудитория будет кратно расти. Еще ICE отлично применим для Growth Hacking Team, где чувствительность к охвату не такая большая. 

Теперь давайте посмотрим на картинку ниже, которая описывает уже RICE — тот фреймворк, который используем мы.

Как вы видите, он похож на ICE, но есть дополнительное измерение:

• Reach — охват, то есть это то, сколько людей потенциально будет пользоваться этой фичей. Считаем в % от 1 (10%) до 10 (100%).

Этот параметр очень сильно зависит от:

1. Инфраструктуры которая у вас есть: систем аналитики, уровня логгирования и проработки таксономии.

2. Уровня навыков в команде: есть ли в ней продуктовый аналитик или его роль выполняет продакт-менеджера.

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

В наших командах есть продуктовые аналитики, которые создают дашборды и кастомный калькулятор для подсчета Reach в зависимости от экрана, где происходит изменение, и специального коэффициента доступности. Он формируется на основании прошлых тестов, которые могут выступать “оценкой снизу”. 

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

Мы очень тщательно подходим к оценке Reach в нашей команде, т.к. считаем, что в зрелом продукте очень важно делать изменение, которое принесет пользу максимальному количеству пользователей.

Итого: ICE и RICE одинаково хороши для любых продуктов. По сути  — это классический подход отношения результат/усилия (как, например Value vs Cost), где есть добавленные критерии по потенциальной популярности и уровню веры. Но, конечно, фреймворк — это еще не все. Качество приоритизации растет во многом вместе с возможностями команды и наличием классной инфраструктуры.

Практика

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

Как бы мы в СберМаркете считали RICE по ней? 

Далее мы считаем результат по формуле: перемножаем Reach, Impact и Confidence и делим это на Effort. Получается 10 — средний результат. 

Если бы мы провели бы дополнительные UX интервью, дизайн спринт или GHT тест и подняли Confidence до 8, то результат бы 16 — достаточно высокий, чтобы делать в большем приоритете. Так мы оцениваем RICE конкретно у себя.

В итоге, мы собираем таблицу приоритизации —  магия случается именно здесь. Когда вы сделаете это упражнение с двадцатью, пятьюдесятью, ста инициативами и отсортируете по коэффициенту, вы сразу увидите топ — то, что вам нужно делать уже завтра, в следующем спринте или в следующем квартале. 

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

Распространённые ошибки

Расскажу про 3 ошибки, которые я совершал и продолжаю совершать, потому что эти ошибки не в поле профессионализма, а скорее в поле природы человека. Исключить их очень сложно, но мы можем снизить риски их возникновения.

Ошибка #1 Оценивать задачи в одиночку

В одиночку легко завысить или занизить коэффициент определенным задачам, то есть поддаться когнитивным искажениям. Как продакт, вы скорее всего будете повышать коэффициенты тем задачам, которые придумали сами, и понижать тем, которые "принесли" вам CEO, руководитель по маркетингу или коллега. 

История одной неудачи

До СберМаркета я работал в разных сервисах, в том числе в сервисе такси. Поделюсь кейсом оттуда.

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

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

Подсчитали коэфф по RICE.

• Reach — 7 из 10. Провалидировали по данным. У 70% пользователей были повторяющиеся маршруты. 

• Impact — 3 из 3. Если мы сделаем такое улучшение, то двинем конверсию на от 2% до 5%.

• Confidence — 5, мы верили, стейхолдеры верили, пользователи на решенческом интервью встретили фичу с энтузиазмом.

• Effort — делать MVP-вариант, 2 спринта. 

Вердикт: Надо делать!

В реальности же было так: 

• Reach  — <10%, выборка оказалась очень маленькой. Мы столкнулись с ограничениями GPS и временных интервалов. Сегодня пользователь возвращался домой в одно время, завтра он мог сделать это позже или раньше на 30-40 минут.

• Impact —  конверсия в итоге упала. Позже мы провели дополнительные интервью и выяснили —  люди не понимали, что происходит. Приложение долго висело на лоадере и после неожиданно для них выдавало результат. Они думали: «Приложение, наверное, сломалось» и просто уходили.

• Confidence — теперь мы ответили себе на вопрос: а почему наши ключевые конкуренты это еще не сделали? =)

• Effort —  реализация требовала бо́льших ресурсов и вычислений на лету, чем нам казалось вначале.

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

Как пофиксить эту проблему?

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

Если у вас небольшая дискавери-команда, посоветуйтесь с инженерами, особенно с QA. Если разработка не может — с другими менеджерами. 

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

Ошибка #2 Разделять задачи на продуктовые и непродуктовые

Мы знаем, что продуктовые задачи - это классно. Обычно они структурированные, с понятной целью и ожидаемыми результатами. Например, вырастить конверсию на X%, средний чек на Y рублей и т.д.

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

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

Как пофиксить проблему?

Решение: также приоритизировать энейблеры по RICE. 

Очень часто это требует оверкоммуникации со стейкхолдерами, топ менеджментом и CEO. Но чтобы идти подготовленным, для начала лучше пройтись по чек-листу — у нас в СберМаркете он выглядит вот так:

Еще помогает декомпозиция RICE на подпараметры. Из примера выше вам надо занести в Impact не положительный, а возможный отрицательный эффект  — от штрафов/пени и т.д., и так же приоритизировать это относительно других задач.

Очень хорошо может работать разделение на подпараметры в Confidence, особенно если у вас есть из отделов Strategy, Customer Success, PR и других, которые могут вам дать дополнительный контекст. Если такие задачи попадают в топ бэклога, то вам легко объяснить команде, зачем нужно это сделать.

Ниже изобразил, какие подпараметры могут быть.

Ошибка #3 Закрывать бэклог от коллег

Это очень частая ошибка — я вижу ее в том числе у ребят, которые начинают карьеру. Как это выглядит? Мы что-то положили себе в бэклог — собрали со слезами, по́том и кровью, что-то отприоритизировали, но не показываем наружу: другим менеджерам, стейхолдерам, CEO.

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

Как решаем?

1. Использовать RACI модель. У нас в продукте в явном виде описаны зоны ответственности продуктовых команд по RACI модели, и мы всегда знаем круг людей, с которыми нужно обязательно проконсультироваться и которых нужно проинформировать от приоритизации до подведения результатов инициативы.

Лайфхак: очень хорошо работает простая механика -> создаем задачу в бэклоге (у нас это тикет в Jira) и сразу добавляем в watchers всех по RACI модели.

Что такое RACI

RACI — это аббревиатура, которая включает в себя четыре роли:

• responsible (ответственный за работу) — тот, кто непосредственно выполняет задание;

• accountable (ответственный за результат) — тот, кто принимает работу и несет ответственность за результат;

• consulted (консультирующий) — тот, кто оказывает консультативную помощь;

• informed (информируемый) — тот, кто в курсе принимаемых решений и хода выполнения задачи.

2. Иметь открытый бэклог и выстраивать каденции внутри компании.
   В СберМаркете лучшие процессы в моей карьере. У нас есть открытый бэклог в Jira, в которой заведены абсолютно все инициативы в компании. В сервисе удобно ознакомиться, подписаться на любой проект и оперативно видеть изменения:

• еженедельно в пятницу каждый менеджер актуализирует статус инициативы и пишет подробности в комментарии;

• ежемесячно мы проводим live демо, на котором рассказываем про инициативы, которые оказались успешными, и про планы ближайшего месяца;

• ежеквартально мы презентуем результаты квартала и рассказываем про планы следующего;

• раз в полгода мы формулируем продуктовую стратегию (6pager документ), в котором рассказываем, каким видим приложение и сайт к концу года.

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

Коммуникация экономит и деньги компании, и наши силы.

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

Выводы

Приоритизация —  это путь. Она не бывает раз и навсегда, это бесконечный процесс. 

Это командная работа. Общайтесь с командой, делайте это вместе, потому что так результаты будут точно лучше. 

Приоритизировать можно все что угодно — это только вопрос инвестиции времени, которое вы готовы на это потратить.

И последнее —  открытость во благо. Это принцип СберМаркета.  Мы стараемся везде использовать открытые данные, общаться со всеми членами команды из компании, если это принесет value. Будьте открыты во благо.

В конце прикрепляю чеклист — проверьте себя. 

Удачи вам в приоритизации! Если остались вопросы, буду рад ответить в комментариях.

Продуктовая команда СберМаркета ведет соцсети с новостями и анонсами. Если хочешь узнать, что под капотом высоконагруженного e-commerce, следи за нами в Telegram и на  YouTube. А также слушай подкаст «Для tech и этих» от наших it-менеджеров.