Если все фичи в процессе разработки продукта кажутся одинаково важными, то выбрать самую приоритетную из них порою очень сложно. Тогда на помощь менеджеру продукта могут прийти полезные фильтры для определения приоритетов.
Я хорошо представляю, как тяжело выбирать фичи для разработки, когда ваш product backlog просто ломится от “вкусных” фич. Но нам, менеджерам продуктов, приходится совершать этот выбор ежедневно. Потому что наша основная задача — дать пользователю value, как можно скорее и как можно больше. И мы не можем сидеть сложа руки. Наша задача — быстро принимать решения в условиях некоторой неопределенности.
Вопрос звучит просто: какая фича самая важная для нас сейчас? Но если они почти все важные? Этот вопрос слабо помогает нам в принятии решения.
Рассмотрим набор фильтров, которые помогут глубже понять степень важности или степень влияния фичи на ваш продукт. А это понимание поможет принять правильное в данный момент и в данном месте решение.
Итак, поехали:
Фича соответствует нашей долговременной стратегии или нет. Например, для нас стратегическая фича — интеграция с Jira. Эта фича позволит нам уйти от прямой конкуренции с Jira и занять новую нишу — софт для менеджеров продуктов. Пример тактической функции — поддержка нового стандарта GDRP, который должен быть внедрен до 25 мая 2018 года, иначе мы рискуем попасть на большой штраф.
Фича может улучшать какие-то конкретные показатели, например, увеличивать конверсию из регистраций в покупку подписки. А может, вообще не влиять в случае с фиксом багов или с переходом на новую библиотеку по обработке фотографий.
Фича может улучшать UX и делать жизнь пользователя в вашем продукте лучше, а может, наоборот, усложнять его жизнь, но при этом повышать доход.
Сравните: фича, которая касается onboarding и которую увидят и прочувствуют абсолютно все новые пользователи, и фича, которая понадобится пользователям только на 7 день после регистрации. Например, экспорт в PDF time tracking отчета.
Фича shortcuts или hot keys нужна часто тем пользователям, которые активно пользуются Hygger, в отличие от фичи «Смена типа доски с Канбан на Спринт», которая нужна только один раз, когда клиент импортирует свои данные в Hygger из Jira или Trello.
Тут все просто: нужно оценить трудозатраты на разработку фичи. Если есть функции с маленькими затратами, но с большим value, то их надо делать первыми. Мы их еще называем Quick Wins. Но нельзя забывать и про большие функции с большим value. Их желательно разбивать на более мелкие куски и делать постепенно. Ибо они могут дать хороший value вашему продукту.
Себестоимость фичи складывается не только из времени разработки. Для фичи надо написать документацию, снять и смонтировать видео, сделать рассылку, настроить ивенты в аналитике, сделать Dashboard в BI туле, провести вебинар и так далее.
Если фичу просит vip клиент, логотип которого вы гордо показываете всем посетителям на лендинге, то не спешите говорить «нет».
Если в вашем продукте не будет ожидаемой по модели Кано функции, то пользователь просто уйдет. Например, если бы в Hygger не было комментариев у задач, вряд ли бы у нас были пользователи.
Пример желаемой по Кано функции — объем доступной памяти на Dropbox. Чем больше памяти доступно пользователю, тем выше его удовлетворенность. Как правило, это линейные свойства продукта, то есть, чем этого больше, тем лучше. Другие примеры:
Если ваша фича является восхищающей по Кано, то она станет «пасхалкой» для пользователя. То есть, это всегда что-то неожиданное, то, чего пользователь совсем не ожидает от вашего продукта. Например, в случае с Hygger, это может быть 2-х уровневое комментирование задач или возможность с помощью тачпада перемещаться по доске в разных направлениях.
Если этой функции не будет в вашем продукте, ну и ладно — пользователи даже не заметят этого. Но, с другой стороны, пользователи могут быть настолько впечатлены функцией, что поделятся своим открытием с другими.
Если фича есть у конкурентов, это значит только то, что она есть у конкурентов. А вдруг ей никто не пользуется, и конкурент собирается ее скоро «выпилить»? Но иногда фича у конкурентов становится ожидаемой по Кано, и нам приходится ее повторять у себя. А лучше делать новые и классные фичи первыми!
Вы готовы отдавать фичу в разработку? Не спешите, убедитесь, что она детально изучена и описана так, что ее четко и ясно поймут ваши программисты и тестировщики. Степень детализации выбирать вам — вы как product manager лучше знаете ваших людей. Если понимаете друг друга с полуслова — отлично, можно не писать «Войну и мир». Работаете с банковским продуктом, у вас в команде есть свои бизнес-аналитики — прекрасно, пусть они моделируют фичу в UML хоть во всех 7 диаграммах.
Оцените в процентах вероятность того, что фича действительно оправдает возложенные на нее ожидания.
Идеально, если все фичи измеримые. Это дает нам возможность численно оценить их вклад в успех продукта.
Если проблема выявлена на юзабилити-тестировании (UX-тестировании), то это придает нам уверенности в том, что мы решаем реальные проблемы пользователей, а не «галлюцинируем», как в случае с гипотезами, которые мы сами формулируем.
Конечно, наблюдение проблемы у 5 человек — это одно, а гипотеза на основе анализа поведения 1000000 пользователей — это другое. Тогда и не стоит это сравнивать, а надо формулировать гипотезы и проверять их asap.
Команда со временем накапливает технические долги, которые надо отдавать. Это может быть временный, не очень красивый код, который решает задачу, но топорно. Это может быть заглушка для функции, которая может быть вызвана в очень исключительной ситуации.
Если такие долги не отдавать, то со временем могут «накапать» очень большие проценты и на рефакторинг кода может уйти намного больше времени, чем эти долги позволили выиграть на старте.
Далеко не факт, что в вашем продукте будут нужны все эти фильтры. Как правило, менеджер продукта выбирает 3-7 критериев и использует их для скоринга фич. В результате, каждая фича получает числовое значение, и их уже можно сравнивать в одной плоскости.
Мы в Hygger.io используем метод Lean Prioritization. Он легковесен и эффективен, поэтому мы им пользуемся практически каждый день.
Это метод, представляющий собой 2×2 матрицу, которая помогает в принятии решений и определяет, что важно, что рискованно, и куда направлять свои усилия. Матрица активно применяется и для определения приоритетов в разработке продуктов.
Если не поддерживать бэклог постоянно, он быстро может стать свалкой для десятков, сотен и даже тысяч фич и багов.
Используя Lean Prioritization для работы с матрицей можно просто нарисовать большой знак плюс «+» на доске и задать значения «Value» и «Efforts» вдоль вертикальной и горизонтальной осей. Однако, многие согласятся, — эффективнее и удобнее будет использовать специальный онлайн инструмент, особенно, если у вас распределенная команда.
В Hygger это Backlog Priority Chart, где, помимо параметров Value и Efforts, предлагаются 4 сегмента: Big Bets, Quick Wins, Time Sinks и Maybes, каждый из которых представляет собой степень приоритетности:
Наверняка, список способов для определения приоритетности продуктовых фич может быть расширен. А по каким критериям вы оцениваете фичи? Возможно, у вас есть решение, которое может помочь другим?
Я хорошо представляю, как тяжело выбирать фичи для разработки, когда ваш product backlog просто ломится от “вкусных” фич. Но нам, менеджерам продуктов, приходится совершать этот выбор ежедневно. Потому что наша основная задача — дать пользователю value, как можно скорее и как можно больше. И мы не можем сидеть сложа руки. Наша задача — быстро принимать решения в условиях некоторой неопределенности.
Вопрос звучит просто: какая фича самая важная для нас сейчас? Но если они почти все важные? Этот вопрос слабо помогает нам в принятии решения.
Рассмотрим набор фильтров, которые помогут глубже понять степень важности или степень влияния фичи на ваш продукт. А это понимание поможет принять правильное в данный момент и в данном месте решение.
Итак, поехали:
1. Стратегическая/тактическая
Фича соответствует нашей долговременной стратегии или нет. Например, для нас стратегическая фича — интеграция с Jira. Эта фича позволит нам уйти от прямой конкуренции с Jira и занять новую нишу — софт для менеджеров продуктов. Пример тактической функции — поддержка нового стандарта GDRP, который должен быть внедрен до 25 мая 2018 года, иначе мы рискуем попасть на большой штраф.
2. Влияет на метрику/не влияет (долги, баги)
Фича может улучшать какие-то конкретные показатели, например, увеличивать конверсию из регистраций в покупку подписки. А может, вообще не влиять в случае с фиксом багов или с переходом на новую библиотеку по обработке фотографий.
3. Улучшает UX/портит UX
Фича может улучшать UX и делать жизнь пользователя в вашем продукте лучше, а может, наоборот, усложнять его жизнь, но при этом повышать доход.
4. Нужна многим клиентам/нужна единицам
Сравните: фича, которая касается onboarding и которую увидят и прочувствуют абсолютно все новые пользователи, и фича, которая понадобится пользователям только на 7 день после регистрации. Например, экспорт в PDF time tracking отчета.
5. Нужна часто клиентам/нужна редко
Фича shortcuts или hot keys нужна часто тем пользователям, которые активно пользуются Hygger, в отличие от фичи «Смена типа доски с Канбан на Спринт», которая нужна только один раз, когда клиент импортирует свои данные в Hygger из Jira или Trello.
6. Время и стоимость разработки: высокие/низкие
Тут все просто: нужно оценить трудозатраты на разработку фичи. Если есть функции с маленькими затратами, но с большим value, то их надо делать первыми. Мы их еще называем Quick Wins. Но нельзя забывать и про большие функции с большим value. Их желательно разбивать на более мелкие куски и делать постепенно. Ибо они могут дать хороший value вашему продукту.
7. Время и стоимость внедрения: высокие/низкие
Себестоимость фичи складывается не только из времени разработки. Для фичи надо написать документацию, снять и смонтировать видео, сделать рассылку, настроить ивенты в аналитике, сделать Dashboard в BI туле, провести вебинар и так далее.
8. Требует vip клиент/требует не платящий клиент
Если фичу просит vip клиент, логотип которого вы гордо показываете всем посетителям на лендинге, то не спешите говорить «нет».
9. Ожидаемая/нет
Если в вашем продукте не будет ожидаемой по модели Кано функции, то пользователь просто уйдет. Например, если бы в Hygger не было комментариев у задач, вряд ли бы у нас были пользователи.
10. Желаемая/нет
Пример желаемой по Кано функции — объем доступной памяти на Dropbox. Чем больше памяти доступно пользователю, тем выше его удовлетворенность. Как правило, это линейные свойства продукта, то есть, чем этого больше, тем лучше. Другие примеры:
- больше расстояние между креслами в самолете
- больше разных кодеков поддерживает видео-плеер и т.д.
11. Восхищающая/нет
Если ваша фича является восхищающей по Кано, то она станет «пасхалкой» для пользователя. То есть, это всегда что-то неожиданное, то, чего пользователь совсем не ожидает от вашего продукта. Например, в случае с Hygger, это может быть 2-х уровневое комментирование задач или возможность с помощью тачпада перемещаться по доске в разных направлениях.
Если этой функции не будет в вашем продукте, ну и ладно — пользователи даже не заметят этого. Но, с другой стороны, пользователи могут быть настолько впечатлены функцией, что поделятся своим открытием с другими.
12. Есть у конкурентов/инновация
Если фича есть у конкурентов, это значит только то, что она есть у конкурентов. А вдруг ей никто не пользуется, и конкурент собирается ее скоро «выпилить»? Но иногда фича у конкурентов становится ожидаемой по Кано, и нам приходится ее повторять у себя. А лучше делать новые и классные фичи первыми!
13. Идея проработана/не проработана
Вы готовы отдавать фичу в разработку? Не спешите, убедитесь, что она детально изучена и описана так, что ее четко и ясно поймут ваши программисты и тестировщики. Степень детализации выбирать вам — вы как product manager лучше знаете ваших людей. Если понимаете друг друга с полуслова — отлично, можно не писать «Войну и мир». Работаете с банковским продуктом, у вас в команде есть свои бизнес-аналитики — прекрасно, пусть они моделируют фичу в UML хоть во всех 7 диаграммах.
14. Уверенность в том, что выстрелит: высокая/низкая
Оцените в процентах вероятность того, что фича действительно оправдает возложенные на нее ожидания.
15. Измерима/нет
Идеально, если все фичи измеримые. Это дает нам возможность численно оценить их вклад в успех продукта.
16. Проблема выявлена на UX
Если проблема выявлена на юзабилити-тестировании (UX-тестировании), то это придает нам уверенности в том, что мы решаем реальные проблемы пользователей, а не «галлюцинируем», как в случае с гипотезами, которые мы сами формулируем.
Конечно, наблюдение проблемы у 5 человек — это одно, а гипотеза на основе анализа поведения 1000000 пользователей — это другое. Тогда и не стоит это сравнивать, а надо формулировать гипотезы и проверять их asap.
17. Технический долг
Команда со временем накапливает технические долги, которые надо отдавать. Это может быть временный, не очень красивый код, который решает задачу, но топорно. Это может быть заглушка для функции, которая может быть вызвана в очень исключительной ситуации.
Если такие долги не отдавать, то со временем могут «накапать» очень большие проценты и на рефакторинг кода может уйти намного больше времени, чем эти долги позволили выиграть на старте.
Lean Prioritization или как мы приоритезируем в Hygger
Далеко не факт, что в вашем продукте будут нужны все эти фильтры. Как правило, менеджер продукта выбирает 3-7 критериев и использует их для скоринга фич. В результате, каждая фича получает числовое значение, и их уже можно сравнивать в одной плоскости.
Мы в Hygger.io используем метод Lean Prioritization. Он легковесен и эффективен, поэтому мы им пользуемся практически каждый день.
Это метод, представляющий собой 2×2 матрицу, которая помогает в принятии решений и определяет, что важно, что рискованно, и куда направлять свои усилия. Матрица активно применяется и для определения приоритетов в разработке продуктов.
Если не поддерживать бэклог постоянно, он быстро может стать свалкой для десятков, сотен и даже тысяч фич и багов.
Используя Lean Prioritization для работы с матрицей можно просто нарисовать большой знак плюс «+» на доске и задать значения «Value» и «Efforts» вдоль вертикальной и горизонтальной осей. Однако, многие согласятся, — эффективнее и удобнее будет использовать специальный онлайн инструмент, особенно, если у вас распределенная команда.
В Hygger это Backlog Priority Chart, где, помимо параметров Value и Efforts, предлагаются 4 сегмента: Big Bets, Quick Wins, Time Sinks и Maybes, каждый из которых представляет собой степень приоритетности:
- Quick Wins — это идеи с действительно высоким проказателем value и низким efforts. Это как спелые плоды, которые низко висят и их пора срывать. Чем раньше вы разберетесь с ними, тем больше результата получите.
- Big Bets — это идеи с высокими value и efforts. Вы можете сделать их после Quick Wins. Они займут больше рабочего времени, чем Quick Wins, но принесут такой же профит. Старайтесь разбивать такие фичи на более мелкие.
- Maybes — эти фичи с более низким значение value для клиентов, но их легко реализовать. Они часто заполняют рабочее время, когда есть небольшой «простой» в работе или между более крупными фичами.
- Time Sinks — это идеи с низким value, но значительным показателем efforts. Несмотря на то, что они несут какую-то пользу для клиентов, такие фичи не должны быть приоритетными на данный момент времени.
Наверняка, список способов для определения приоритетности продуктовых фич может быть расширен. А по каким критериям вы оцениваете фичи? Возможно, у вас есть решение, которое может помочь другим?
