Стоит ли использовать продуктовый подход, если нет продукта?

Стоит ли использовать продуктовый подход, если нет продукта?

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

Однако многие, кто заменяет (у себя или у клиента) проектный менеджмент на продуктовый, не утруждают себя анализом границ применимости, а «приклеивают» управление продуктами и к месту, и не к месту.

Приведу примеры, связанный с информационными технологиями: предположим, у нас есть идея какой-то ИТ-системы, закрывающей очень существенную потребность определённой аудитории или устраняющей очень неприятную «боль», при этом аудитория является внешней по отношению к нашей организации и, как нам кажется, готовой платить за закрытие потребности и устранение боли. Мы до конца не понимаем, что за ИТ-система получится, как именно она будет закрывать и устранять, куда она будет развиваться, как её позиционировать, как монетизировать. На верхнем уровне идея нам ясна, а в реализации, понятное дело, будет миллион вопросов и миллиард вариантов. Пригодился бы в таком случае продуктовый подход, применённый к разработке ИТ-системы? Очень вероятно.

Теперь посмотрим на другую ИТ-систему: почти готовую, сторонней разработки, нами приобретённую и теперь кастомизируемую для автоматизации внутренних бизнес-процессов нашей компании. Да, здесь тоже есть разработка и развитие, и даже немножко неопределённости. Стоит ли в этом случае применять продуктовый подход? Совсем не очевидно, ведь продукта как такового у нас нет. Однако очень многие зачем-то пытаются играть в продуктовый менеджмент и в таких вот кейсах.

Попробуем разобраться, разумно ли это.

Сначала нам потребуется дать определение продуктовому подходу. Как это часто бывает (см. IT Service Management, Agile, DevOps, Kanban и проч.), найти годное, разумное и универсальное определение будет нелегко. Так уж повелось, что в области менеджмента используются концепции, которые мало кто пытается определить; вместо этого разные авторы и эксперты делают вид, что определения не нужны, либо что всем и так всё понятно, либо определяют через примеры (то есть: никак не определяют). Для целей настоящей заметки нам будет достаточно вот такого определения:

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

При этом продуктовый подход помогает постоянно находить ответы на следующие вопросы:

Какую бизнес-модель использовать, как её изменять? Как монетизировать?

На какую целевую аудиторию направлять продукт? Как позиционировать и менять позиционирование продукта?

Какую функциональность нужно добавить или изменить? Какие свойства продукта нужно создать или изменить? Когда это лучше всего сделать?

Какую функциональность не нужно добавлять или изменять? Какие свойства не нужно создавать или изменять?

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

динамически появляющиеся и меняющиеся возможности;

активное и постоянное развитие;

(возможно) высокая неопределённость.

Вернёмся к двум примерам, которые я приводил в начале заметки. Для первой ИТ-системы (той, что направлена на внешних клиентов) перечисленные критерии полностью применимы. Для второй (которая направлена на внутренних клиентов) — скорее нет, чем да; возможно, сработает лишь один критерий из трёх, активное и постоянное развитие.

Продолжим рассуждения. Что происходит сразу же, как только какая-либо организация начинает «внедрять» продуктовый подход? Известно что: нужно что-то назвать продуктом и назначить владельца продукта (product owner). Снова вернёмся к нашим примерам. В первом из них выделение продукта пройдёт, скорее всего, просто и безболезненно — все, кому нужно, будут достаточно хорошо представлять себе что именно мы понимаем под данным продуктом. Равно как и назначение владельца продукта будет означать, что у данного персонажа появляются значимые в рамках организации ответственность и полномочия, зачастую сильно завязанные на P&L и личный финансовый доход.