Skip to main content
три корзины

Руководство по продуктовому планированию: три корзины фич


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

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

Поместите свою идею или концепцию в одну из трех корзин:

  • Изменяющие метрики. Это задачи, которые значительно изменят ваши целевые бизнес и продуктовые метрики. В большинстве здоровых продуктовых организаций, решение инвестировать в продукт или функциональность является следствием конкретных целей и стратегии. Вовлеченность. Рост. Прибыль. Как правильно, очень немногие задачи могут изменить метрики. Ваша задача понять какие из идей опережают время, потому что в конечном счете решение о том, был ли ваш продукт успешным, а роадмап удачным, будет зависеть от значений метрик.
  • Запросы клиентов. Это функциональность, которая чаще всего запрашивается вашими клиентами. Здесь нет никакой магии. Прислушивайтесь к своим клиентам и знайте, какие функции они больше всего хотели бы видеть в вашем продукте. Необязательно реализовывать все предложения, но профессионалы должны внимательно и с эмпатией выслушивать прямые вопросы и анализировать их. Ничто так не раздражает клиентов как запуск новой функциональности, вместо того чтобы сделать ту, которую они у вас активно запрашивали.
  • Удовлетворение клиентов. Это функциональность о которой клиенты не просили, но которая приведет их в восторг. Обычно это фичи, которые включают несколько ингредиентов: выслушивание клиентов, чтобы понять их боль, использование знаний о технологиях, чтобы понять что может быть сделано для решения боли клиентов, и инновационный дизайн, который дает элегантный и очаровательный опыт использования.

Не поймите меня неправильно — есть некоторые фичи, которые могут относиться к нескольким категориям, но очень редко появляется фича, которая на самом деле попадает во все три.

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

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

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

Большинство интернет-компаний не часто выпускают большие монолитные релизы — вместо этого они часто выпускают небольшие изменения и дополнения. (В LinkedIn мы выпускаем небольшие релизы каждую неделю.) Приведенная выше логика, однако, может так же легко применяться к серии 1–2-недельных итераций, выполняемых в течение трехмесячного роадмапа.

Найдите минутку и подумайте об основных релизах популярных продуктов для широкой аудитории, продуктах которые вы уважаете как профессионал. Вы обнаружите, что в этих релизах хорошо представлены задачи из всех трех корзин.
(Неплохой пример — iPhone 3.0.)


Это перевод оригинальной статьи Adam Nash — Guide to Product Planning: Three Feature Buckets