Например, нам может понадобиться встретиться с юристом компании и обсудить правовые ограничения и разные способы, которые можно использовать, чтобы урегулировать эти вопросы. Мы знаем, что если наше решение — даже если клиент от него в восторге — не соответствует законодательству, оно обречено на неудачу.
Теперь стейкхолдер не клиент, который указывает нам, что делать, и, следовательно, нуждается в управлении с нашей стороны, а партнер, который помогает нам понять и учесть ограничения, чтобы мы могли найти работающее решение.
Агентская модель бизнеса
Предназначение агентства — будь то дизайнерское агентство или агентство по разработке ПО — предоставить вам услуги по дизайну или услуги по разработке ПО соответственно.
Возможно, вы не думали об этом в таком ключе, но функциональная команда действительно очень похожа на агентскую модель. Главное отличие в том, что функциональная команда работает на основе внутреннего подряда, а агентская модель — на основе внешнего подряда, или аутсорсинга.
В таких агентствах, как правило, нет должности «менеджер по продукту», но есть «менеджеры по взаимодействию», которые занимаются «управлением отношениями с клиентом» (в большинстве случаев с теми самыми стейкхолдерами, которых должна обслуживать функциональная команда).
Поэтому не стоит удивляться, что компании, использующие агентства для выполнения работ по дизайну и разработке ПО, сталкиваются с теми же проблемами, что и при использовании функциональных команд.
В этом случае люди, работающие в агентстве, не ощущают себя наемниками — они на самом деле ими являются.
Исходя из своего опыта, могу сказать, что сотрудники агентств, как и функциональных команд, способны на большее, и обычно никому из них не нравится та модель, согласно которой они работают. Но реальность такова, что если они не захотят создавать «функцию», которую заказывает им «клиент», то заказ получит другое агентство, более сговорчивое.
Существует несколько агентств, которые стараются предоставлять своим клиентам услуги настоящих продуктовых команд с широкими полномочиями, и я горячо одобряю эту тенденцию. Но, к сожалению, это зависит от того, насколько высокую степень доверия к агентству питает клиент.
И еще одно соображение. Часто в агентствах по дизайну и разработке ПО вы можете найти исключительно хороших специалистов, которых можно нанять в вашу компанию, так как они обладают опытом создания продуктов самых разных типов.
Но необходимо понимать, что переход к использованию продуктовой команды с широкими полномочиями приведет к серьезным изменениям в корпоративной культуре. Во многих случаях люди из агентств приносят с собой те же проблемы, которые привели функциональные команды к поражению. Бывало, что мне радостно говорили: «Теперь я смогу стать вашим клиентом!» Я всегда старался мягко объяснить, в чем именно они не правы.
Глава 73. Обмен идеями и знаниями
В продуктовых командах с широкими полномочиями, которые работают над решением сложных проблем, используемые методы исследования очень часто генерируют инсайты.
Мы встречаемся с пользователями и клиентами, обычно раз в неделю, и проверяем наши идеи, связанные с созданием продукта. Мы глубоко вникаем в контекст и потребности клиентов.
Мы анализируем данные об использовании нашего продукта и актуализируем сведения, полученные в результате тестирования наших идей.
Мы постоянно изучаем новые передовые стимулирующие технологии, чтобы обдумать возможность их использования в решении проблем, которые стоят перед нами, новыми и более эффективными способами.
Мы отслеживаем отраслевые данные и накопленный опыт в поисках релевантных тенденций.
Мы также постоянно стараемся найти новые идеи в других подразделениях компании, занимающихся маркетингом, продажами, финансами, обеспечением клиентского успеха.
Когда мы находим важные или потенциально релевантные инсайты, мы хотим поделиться этими знаниями с нашими коллегами по бизнесу. Для этого есть несколько причин.
Во-первых, инсайты могут помочь и им тоже.
Во-вторых, у них могут появиться дополнительные идеи, когда они рассматривают полученную информацию со своей точки зрения.
В-третьих, они могут нам помочь объяснить динамику, чтобы более эффективно использовать инсайты.
В-четвертых, важно, чтобы компания усвоила разницу между отрицательной реакцией на прототип в процессе продуктового исследования и неудачей продукта на рынке.
«Неудача» в процессе исследования, по сути, неудачей не является: ее можно рассматривать как быстрое и недорогое обучение. «Неудача» на рынке — это действительно провал продукта, так как исправлять ошибки очень долго и дорого. Нужно, чтобы компания в целом понимала это отличие. Мы до сих пор не можем полностью избежать неудач, но можем существенно уменьшить частоту, с которой они случаются.
В более общем смысле вам нужен такой тип взаимоотношений, при которых вы свободно и щедро обмениваетесь информацией и опытом. Делясь инсайтами и знаниями со своими бизнес-партнерами, вы предлагаете им идти вместе с вами по пути инноваций и развития бизнеса.
Мне нравится приглашать ключевых бизнес-лидеров на некоторые из наших пользовательских или клиентских тестирований.
Я большой сторонник обмена важнейшими данными со всеми подразделениями организации, а также обмена работающими идеями наряду с теми, которые не работают.
И не скупитесь на признание и доверие, когда оказывается, что инсайт, исходящий от одного из ваших ключевых лидеров или руководителей высшего звена, имеет решающее значение для какой-либо инновации или существенного продвижения к цели. В одной компании я даже сделал значки «заместитель менеджера по продукту» и раздал их, чтобы привлечь внимание к вкладу других сотрудников во время общего собрания.
Просто позаботьтесь о том, чтобы инсайты были оценены по достоинству и чтобы обмен ими происходил в обоих направлениях.
Глава 74. Держаться на плаву
Большая часть этой книги посвящена тому, как сильные команды решают сложные проблемы способами, которые нравятся нашим клиентам и при этом работают на благо бизнеса.
Однако верно и то, что каждая команда должна делать некоторый объем работ для того, чтобы просто держаться на плаву, то есть вести бизнес как обычно.
Когда вы занимаетесь бизнесом, у вас всегда есть какая-то работа, выполнение которой не подлежит обсуждению, если вы хотите оставаться в бизнесе. Вот наиболее типичные примеры:
• Устранение критически важных ошибок.
• Решение вопросов соблюдения законодательства.
• Внедрение незначительных изменений, чтобы удовлетворить меняющиеся потребности в отчетности.
• Добавление инструментария для сбора аналитических данных об использовании продукта.
Все эти работы не эффектные, но обычно относительно непыльные.
Вы можете заниматься данными вопросами в собственных целях (например, устранение значимых ошибок или создание инструментария для аналитики) или выполнять запросы какого-либо лица вроде вашего юрисконсульта (например, новая проблема, связанная с соблюдением законодательства) или финансового партнера (например, потребность в отчетности).
Менеджер по продукту, как правило, является лицом, ответственным за понимание вопросов, связанных c работой по поддержанию на плаву, за сбор необходимых данных и за включение этих работ в список задач и приоритетов (бэклог). Как правило, нам не нужно проводить продуктовое исследование по какому-либо из данных пунктов. Если мы это делаем, значит, мы рассматриваем тот или иной вопрос как обычную работу по продукту.
Итак, каким образом это связано с деловым сотрудничеством?
Источником проблем часто является один или несколько наших деловых партнеров. Они могут не знать оптимального способа удовлетворить определенную потребность, но обычно остро ощущают эту потребность и способны предоставить любой необходимый контекст. Если продуктовая команда не способна решить эти вопросы, то бизнес-партнер реально окажется в затруднительном положении и ситуация может стать довольно напряженной.
