Продолжение начатого.

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

• Менеджер продуктов заинтересован в том, чтобы продукт использовался клиентами (product adoption). Инженеры в этом заинтересованы слабо, особенно если продукт делается для внутренних нужд. Очень часто сами клиенты не заинтересованы в том, чтобы переходить на новую версию продукта, т.к. придётся переучиваться.
• Менеджер продуктов ищет баланс между функциональностью продукта и простотой его использования. Инженеры обычно не заинтересованы в том, чтобы продукт был удобен в использовании, т.к. юзабилити не даётся дёшево. Очень часто и клиент не заинтересован в простоте использования, т.к. человек, ставящий свою подпись под требованиями к продукту – далеко не всегда пользователь этого продукта. С другой стороны, люди, напрямую работающие с продуктом, больше заинтересованы в простоте использования, нежели функциональности. Найти баланс между этими противоречивыми требованиями – одна из самых сложных задач продуктового менеджера.
• Менеджер продуктов обязан знать место продукта в бизнесе компании. Инженеры почти никогда не знают и не хотят знать это. Людям из Sales and Marketing интересна только та часть информации, которая позволяет продвинуть и продать продукт. Менеджер продуктов – это почти единственный человек в организации, обладающий пониманием того, как будет развиваться продуктовая линейка. И ещё одна из ключевых проблем состоит в том, что нужно объяснить видение развития продуктов всем сторонам – инженерам, бизнесу, клиентам – и заручиться их поддержкой. К мнению клиента, разумеется, нужно прислушиваться в первую очередь, но нельзя основывать свои решения только на мнении клиента.

Ситуация усугубляется наличием жёстких сроков, из-за которых менеджер продуктов не в состоянии добиться достаточного участия всех сторон:

• подавляющее количество инженеров, если им дать выбор между “сделать больше” и “сделать приятно для пользователя”, выберут первое. Их нельзя за это винить: делать что-то новое почти всегда интереснее, чем улучшать старое.
• продавцы обязательно выберут “продать больше”, нежели “обеспечить обратную связь (provide feedback) с продуктоводом”. Я видел только троих людей-исключений из этого правила.
• маркетологи, как правило, предпочтут броскую упаковку
• ещё остаются такие области как документация, учебные материалы, QA, поддержка и процессы, связанные с жизнью продукта. Ну кто поверит, что в нормальном user-centric development QA занимает по времени почти столько же, сколько разработка? И что документация должна писаться параллельно с разработкой, а не после неё? И что план запуска проекта (или выпуска продукта) должен быть готов на 50% до того, как начнётся разработка?

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

Filed under: Бизнес