12 методов приоритизации продуктовых целей: RICE, WSJF, KANO и прочие

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

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

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

Ниже — 12 наиболее распространенных методов, о которых мы расскажем:

• RICE (Reach — охват, Impact — влияние, Confidence — достоверность, Effort — усилия)
• ICE (Impact — влияние, Confidence — уверенность, Ease — легкость реализации)
• Value vs Effort («ценность против усилия»)
  
• Модель Кано
• Story mapping («карта историй»)
• MoSCoW
• Opportunity scoring («оценка возможностей»)
• Product tree («дерево продукта»)
• Cost of delay («стоимость задержки»)
• Buy a feature («купи функцию»)
• Weighted scoring («взвешенная оценка»)
• WSJF (Weighted Shortest Job First, «сначала — более важная и короткая работа»)
  

Эта система оценки измеряет каждую фичу или инициативу по четырем параметрам: охват (reach), влияние (impact), достоверность (сonfidence) и усилия (effort).

Что означает каждый из параметров и как его можно оценить количественно:

Сколько пользователей затронет эта фича за определенный период?

Пример: Пользователей в квартал, транзакций в месяц.

Какое влияние эта фича окажет на пользователя?

• 3 — огромное влияние.
• 2 — высокое влияние
• 1 — среднее влияние
• 0,5 — слабое влияние
  

Пример: Насколько эта фича повлияет на коэффициент конверсии?

Насколько мы можем быть уверены в своей оценке параметров reach и impact? Как много данных у нас есть, чтобы подтвердить свою оценку?

• 100% — высокая достоверность
• 80% — средняя достоверность
• 50% — низкая достоверность
  

Сколько времени потребуется инвестировать в эту инициативу (продукт, дизайн, разработка)? Параметр оценивается в человекомесяцах.

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

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

Плюсы метода приоритизации RICE:

• Чтобы начать применять этот метод, продуктовой команде придется научиться ставить SMART-цели.

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

Минусы метода приоритизации RICE:

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

Если вы ищете метод быстрой приоритизации, модель ICE подойдет вам даже лучше, чем RICE.

Говоря словами Ануйя Адии, автора «Гроузхакинга для чайников»: воспринимайте ICE как MVP в мире приоритизации.

Это отличный старт, если вы только начинаете формировать привычку приоритизировать продуктовые инициативы, но при этом методу не хватает объективности.

Фреймворк ICE был популяризирован Шоном Элисом, которого принято считать создателем термина «гроузхакинг». Изначально ICE использовался для оценки и приоритизации экспериментов в сфере гроузхакинга, но затем стал популярен и в коммьюнити менеджеров продуктов.

ICE это акроним из следующих слов:

• Impact – Какое влияние внедрение этой инициативы окажет на пользователя?
• Confidence – Насколько мы уверены, что эта инициатива подтвердит нашу гипотезу и позволит добиться желаемого результата?
• Ease – Насколько легко ее внедрить? Какие потребуются затраты и ресурсы?

Каждый из этих факторов оценивается по шкале от 1 до 10, а среднее арифметическое из трех параметров дает общую оценку по методу ICE.

Вы можете использовать этот шаблон, чтобы рассчитать оценку по ICE:

Один из минусов модели состоит в том, что разные люди могут оценивать одну и ту же инициативу совершенно по-разному. Модель ICE дает систему относительной приоритизации, а не точных подсчетов, основанных на данных.

Чтобы минимизировать неоднородность оценок, убедитесь, что верно определяете каждый параметр в системе ICE. Договоритесь, что то именно означает Impact 5, Confidence 7, Ease 3 и т. д. внутри вашей команды.

Плюсы метода приоритизации ICE:

• Вы сможете быстро решать, что будет работать, а что нет
• Вы сэкономите время и деньги

Минусы метода приоритизации ICE:

• У вас не будет достаточно информации, чтобы выбрать правильную фичу
• Разные люди могут ставить разные оценки, в зависимости от своего восприятия

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

Важно помнить, что финальный показатель — это только субъективная оценка. Выдвинутые мнения и предположения (конечно, с опором на данные, насколько это возможно) должны помочь ответить на важнейший вопрос: «Поможет ли это достичь поставленных целей и метрик? Можем ли мы воплотить это своими силами?».

Такие способы оценки как value vs. effort помогают продуктовым командам легко и быстро определить приоритеты.

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

Плюсы метода приоритизации «Ценность против усилия»:

• Гибкость. Для одних компаний усилие — это время разработчиков, для других — цена внедрения. Этот фреймворк применим для любой компании, индустрии, типа продукта.
• Это хороший инструмент, чтобы выровнять ожидания. Проводя количественную оценку и числовую оценку функций, продуктовые команды могут договориться о том, какие инициативы имеют больший вес, чем другие. Это оставляет туманные догадки и предположения вне обсуждения приоритизации.
• В условиях ограниченных ресурсов метод помогает сосредоточиться только на тех вещах, которые окажут наибольшее влияние на их бизнес и продуктовые цели. Метод легко использовать, потому что он не требует сложных расчетов или формул. Все, что нужно — простые согласованные оценки, которые складываются в общий скоринг.
  

Минусы метода приоритизации «Ценность против усилия»:

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

Модель Кано представляет собой систему координат, где на горизонтальной оси отражены потребности клиента, которые могут быть разделены на три пункта:

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

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

На горизонтальной оси слева размещаются потребности, которые вообще не удовлетворены, справа те, которые удовлетворены полностью.

Вертикальная ось отражает уровень удовлетворенности пользователя. Шкала функциональности показывает, насколько хорошо реализована фича, от «не реализована вообще» до «полностью реализована».

Как это выглядит в сборе:

Пример из ресторанного бизнеса:

• Обязательная (или базовая) потребность — чтобы ресторан был чистым, а блюда подавались вовремя. Без этого пользователи не смогут быть удовлетворены.
• Нормальная (или производительная) потребность: в ресторане вкусно кормят.
• Восхищающая (или привлекательная) потребность: в ресторане предлагают бесплатные угощения с заказом.
• Безразличная потребность: в ресторане есть терминал самообслуживания.

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

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

Опросник должен включать такие вопросы:

• Если бы у вас был доступ к такой функции, что бы вы чувствовали?
• Если бы у вас не было доступа к такой функции, что бы вы чувствовали?
  

И такие варианты ответов:

• Мне это нравится
• Я ожидаю этого
• Мне все равно
• Я смог бы с этим мириться
• Мне это не нравится

Пример такого опросника:

Затем мы собираем все функции (присутствующие или отсутствующие) в таблицу оценки:

• Привлекательная – эта фича не ожидается, но нравится клиентам
• Обязательная – обязательная функция, клиенты недовольны когда ее нет
• Результативная – пользователям нравится наличие и не нравится отсутствие этой функции
• Безразличная – клиентам безразличны к данной функциональности или готовы потерпеть ее отсутствие/наличие
• Спорная – противоречивый и конфликтующий фидбек от клиентов
• Неодобряемая – клиентам нравится отсутствие функциональности и не нравится когда она присутствует

Плюсы приоритизации по модели Кано:

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

Минусы приоритизации по модели Кано:

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

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

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

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

Наконец вы рисуете линию через все истории, разделяя их на спринты и релизы.

Плюсы метода приоритизации «Карта историй»:

• Этот метод помогает быстро и эффективно понять, что должно входить в MVP.
• Метод фокусируется на пользовательском опыте. Придется научиться писать юзер-сториз.
• Это совместная работа. В формировании историй участвует вся команда.

Минусы метода приоритизации «Карта историй»:

• Метод не учитывает внешние факторы, например сложность или ценность для бизнеса.

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

• Must-Have: Это те функции, которые необходимы для работоспособности продукта. Они базовые и не подлежащие обсуждению. Если одной из этих функций нет, продукт не может быть запущен, и поэтому это самая time-sensitive категория.

Пример: «Необходимо, чтобы пользователь имел доступ к своему аккаунту».

• Should-Have: Это важные, но не критические функции.

Пример: ВАЖНО, чтобы пользователь имел возможность сбросить пароль».

• Could-Have: функции, которая не является ни обязательной, ни важной для реализации в установленные сроки. Их реализация заметно повысит удовлетворенность клиентов, но не окажут большого влияния, если они не будут учтены.

Пример: «Пользователю было бы ПОЛЕЗНО иметь возможность сохранять свою работу прямо в облаке из приложения».

• Won’t-Have: Наименее критичные функции, задачи или требования (первыми будут выкинуты из скоупа, если команда столкнется с ограничениями ресурсов). Фичи, которые могут пойти в будущие релизы.

Модель MoSCoW динамична и оставляет пространство для пересмотра приоритетов. Фича, которая получила приоритет «Won’t-Have» однажды может превратиться в Must-Have.

Плюсы приоритизации по методу MoSCoW:

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

Минусы приоритизации по методу MoSCoW:

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

Этот способ расстановки приоритетов, также известный как метод анализа возможностей, строится концепции инноваций, ориентированных на результат (Outcome Driven Innovation) Энтони Улвика — та же концепция лежит в основе Jobs To Be Done.

Теория Улвика гласит, что клиенты «нанимают» продукты и услуги, чтобы выполнить определенную работу. И, хотя клиенты не всегда умеют находить способ решения своих проблем, важно получить от них обратную связь, которую команда будет использовать, чтобы создать продукт или фичу, отвечающую потребностям заказчика.

Оценка возможностей предполагает построение графика Удовлетворенности (Satisfaction) и Важности (Importance) для измерения и ранжирования возможностей. Вы должны составить список идеальных результатов, а затем задать клиентам следующие вопросы:

• Насколько клиенту важна эта фича или результат ее внедрения? Попросите его ранжировать все пункты.
• Насколько клиент удовлетворен текущим решением?

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

Плюсы приоритизации по методу Оценка возможностей:

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

Минусы приоритизации по методу Оценка возможностей:

• Пользователи могут переоценить или недооценить важность тех или иных функций при опросе.

Дерево продукта — коллаборативная инновационная игра, придуманная Брюсом Холманом. Основное внимание в ней уделяется определению продукта, который будет соответствовать запросам клиентов и принесет компании наибольшую пользу. Игра помогает выкинуть из бэклога лишнее и не оставить без внимания инновационные идеи.

• Для начала нарисуйте большое дерево с несколькими крупными ветками на доске или бумаге.
• Ствол дерева — это функции, которые уже есть в продукте.
• Нижние ветки — это функции, которые станут доступны в следующем релизе.
• Остальные ветки — для фич, которые пока недоступны.
• Попросите участников игры (клиентов, членов команды) написать возможные функции на стикерах. Это будут листья вашего дерева.
• Затем попросите их разместить листья на дереве.
  

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

Плюсы приоритизации по методу «Дерево продукта»:

• Наглядно показывает, как сбалансированы функции в продукте.
• Требует совместной работы, позволяет узнать мнение клиентов, не проводя формальный опрос.

Минусы приоритизации по методу «Дерево продукта»:

• Метод не дает каких-либо количественных значений для ранжирования функций, а только помогает визуализировать текущую ситуацию.
• Функции не разделены на группы, что делает игру времязатратной.

Джошуа Арнольд определяет Cost of Delay как способ определить, как время влияет на желаемые результаты. В частности, этот метод поднимает такие вопросы:

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

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

Допустим, у вас есть функция, и каждая неделя задержки поставки обходится в 30 000 долларов. На ее создание уйдет три месяца.

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

Плюсы метода приоритизации по методу «Стоимость задержки»:

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

Минусы метода приоритизации по методу «Стоимость задержки»:

• Критерии определения стоимости основываются на предположениях, что может привести к внутренним разногласиям.

Купить функцию — игра, в которой могут участвовать клиенты и стейкхолдеры (в зависимости от продукта и задач). Когда вы играете в нее с пользователями, метод помогает сделать количественную оценку стоимости функции или идеи для конечных потребителей.

Игра выглядит так:

• Выберите список функций, идей или обновлений и оцените стоимость каждой. Оценка должна формироваться из времени, денег и усилий, которых потребует создание.
• Соберите вместе группу людей (до восьми человек) и установите количество денег, которые они могут «тратить».
• Попросите участников «купить» функции, которые им нравятся. Некоторые клиенты вкладывают все свои деньги в одну функцию, которая им нравится, другие распределяют на несколько различных функций.
• Попросите участников объяснить, почему они потратили деньги именно так.
• Составьте ранжированный список функций, основываясь на том, сколько денег на них потрачено.

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

Плюсы метода приоритизации «Купить функцию»:

• Метод подойдет идеально, если вы согласны со Стивом Джобсом («Люди не знают, чего они хотят, пока вы им это не покажете»), но при этом хотите воспользоваться мудростью своих клиентов.
• Он заменяет скучные опросники для клиентов забавным упражнением, которое заставит этих клиентов подумать, зачем им нужна та или иная функция.

Минусы метода приоритизации «Купить функцию»:

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

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

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

Вес, присвоенный каждому фактору (из 100%), определяет его относительный вклад в финальную оценку.

Как использовать этот фреймворк:

• Начните с стратегического обзора последующих релизов.
• Составьте список фич из этих релизов. Не нужно оценивать каждую функцию из бэклога. Определите и сгруппируйте самые близкие для темы релиза фичи.
• Определите критерии оценки и их вес. Составьте лист параметров и присвойте каждому от 0% (наименьший вклад в общую оценку) до 100% (наибольший вклад в общую оценку). Убедитесь, что все стейкхолдеры согласны с каждым критерием.
• Пройдите по списку и присвойте каждой функции оценку от 1 до 100. Чем выше оценка, тем вообще влияние, которое функция имеет на критерий.

Пример таблицы оценок:

Оценка каждый фичи умножается на вес драйвера и добавляется к общему скорингу приоритетности. Например в примере: 90*20% + 90*10% + 50*30% + 20*40% = 50 общей приоритетности.

Плюсы метода приоритизации «Взвешенная оценка»:

• Предоставляет количественные данные о каждой фиче и позволяет оценить ее важность.
• Если у вас очень длинный список функций, позволяет выбрать самые важные.

Минусы метода приоритизации «Взвешенная оценка»:

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

WSJF — это инструмент, который используется в Scaled Agile Framework (SAFe) для того, чтобы помочь командам приоритизировать инициативы.

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

Чтобы подсчитать общий балл Cost of Delay, каждый компонент нужно оценить по шкале от 1 до 10. Сумма трёх чисел и определит Cost of Delay (см. пример ниже).

Затем потребуется определить шкалу для оценки объёма работы, которую надо выполнить для каждой вашей идеи или инициативы. Шкала может отличаться от шкалы Cost of Delay, главное чтобы она была единой для всех инициатив.

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

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

Например, если вы оценили для одной инициативы Cost of Delay в 9, а Job Size в 1, балл будет 9 или 91.

Если у другой инициативы при этом Cost of Delay = 7, Job Size = 4, ее балл — всего 1.75, или 74.

Как видите, в топе окажутся инициативы с высокой оценкой Cost of Delay и низкой оценкой Job Size.

Плюсы метода WSJF:

• Позволяет задать правильные вопросы для определения приоритетов в разработке ПО для крупных компаний.

• Исключает когнитивные искажения в процессе расстановки приоритетов.

• Его легко выстроить в соответствии с потребностями вашего бизнеса, так как вы можете создать шкалу, соответствующую вашим целям.

Минусы метода WSJF:

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

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

Идеальный метод приоритизации для вашего продукта должен делать несколько обязательных вещей:

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

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

Подписывайтесь на мой телеграмм канал @dailykuznetsov где я публикую короткие заметки о финансах, обществе и управлении продуктами

Статью подготовили Иван Кузнецов и Надежда Коротченко. Иван 9 лет занимается финтехом в ролях от менеджера проектов до CEO, а сейчас развивает собственные проекты и консультирует продуктовые компании. Надежда несколько лет была редактором, главным редактором и затем издателем ihodl.com, а сейчас руководит проектами в диджитал-агентстве.