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

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

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

Но какую часть вашего бэклога должны составлять запросы пользователей? Если ответ 100%, то это не совсем верный ответ. Возможно, выглядит странно, то это так.
Если вы не любите читать длинные тексты, то ответ такой: если ваш продукт зрелый, и давно на рынке вы не должны уделять много внимания запросам пользователей.

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

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

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

Я выделил две зоны: новой технологии и классической (насыщенной). Когда технология только представлена, очень важно отслеживать требования от пользователей, поскольку это новый способ работы. С другой стороны, если технология уже существует давно, то нужно меньше времени тратить на запросы в пользу новых исследований и разработок.

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

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

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

Начальный этап (introduction) — инноваторы (Innovators)
Рост (growth) — первые пользователи (Early adopters)
Зрелость (mature) — ранее большинство (Early Majority)
Угасание (decline) — позднее большинство (Late Majority), опоздавшие (Laggards)

Для перехода от первых пользователей к потоку клиентов надо перескочить «провал» (Geoffrey A. Moore “Crossing the Chasm”).

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

	Новый продукт	Зрелый продукт
Новая технология	Фокус на запросы пользователей	Одинаково, но с уклоном в R&D
Классическая технология (насыщенный рынок)	Одинаково, но с уклоном в R&D	Фокус только на инновации

Выбор приоритета запроса пользователя