Это текст уже публиковался в англоязычной секции. Однако, я подумал, что читать, а также комментировать, может быть удобнее на русском.
Неважно опытный ли вы менеджер продукта, или только в начале карьеры, вы всегда будете держать в голове большой список запросов от ваших клиентов. Что нужно делать в первую очередь, как обрабатывать эти запросы?
Приоритезация запросов базируется на нескольких принципах. В качестве основы используется соответствие требований стратегии продукта и профилю клиента. Например, если ваш софт ориентирован на малые организации, то делать интеграцию с 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 | Фокус только на инновации |
Автор: MikhailZakharov
