Когда цифровые конкуренты обгоняют все быстрее, а попытки изменений упираются в устаревшие процессы и сопротивление ключевых игроков, становится понятно, что необходимы не отдельные улучшения, а системная трансформация. В этой книге Марти Каган, автор бестселлера «Вдохновленные», и его партнеры из Silicon Valley Product Group показывают, как любая традиционная организация шаг за шагом может перейти на продуктовую операционную модель и стать современной технологичной компанией.
На основе реальных кейсов Adobe, Datasite, Trainline и других компаний вы получите четкий план трансформации: как выстроить сильное продуктовое лидерство, создать команды с реальными полномочиями, сформировать работающую продуктовую стратегию и преодолеть сопротивление внутри организации.
Коллектив авторов:
Марти Каган, Ли Хикман, Кристиан Идиоди, Крис Джонс, Джон Мур
Оригинальное название:
Transformed: Becoming a Product-Driven Company
В тексте неоднократно упоминаются названия социальных сетей, принадлежащих Meta Platforms Inc., признанной экстремистской организацией на территории РФ.
Copyright © 2024 by John Wiley & Sons, Inc.
All Rights Reserved. This translation published under license with the original publisher John Wiley & Sons, Inc. via Igor Korzhenevskiy of Alexander Korzhenevski Agency (Russia)
© Издание на русском языке, перевод, оформление. ООО «МИФ», 2026
Эта книга посвящена Брюсу Уильямсу (1950–2016). Именно Брюс вдохновил меня на то, чтобы покинуть зону комфорта, где я занимался разработкой продуктов для других компаний, выйти в самостоятельное плавание и основать Silicon Valley Product Group (SVPG).
Этот уникальный человек помог улучшить жизнь бесчисленному количеству людей, но, кроме того, он был мне другом, о котором только можно мечтать. Брюс предоставил мне все – от офисного помещения до экспертных советов по дизайну, продажам, маркетингу, издательскому делу, финансам и многому другому.
Без Брюса, скорее всего, я бы так и остался продуктовым лидером и не смог бы написать ни одной книги, не насладился бы немыслимым ранее качеством жизни, которое открылось мне в компании SVPG. Я благодарю Брюса за то, что он побудил меня принять лучшее карьерное решение в моей жизни.
Я желаю, чтобы каждому человеку повезло иметь в своей жизни Брюса Уильямса
У этой книги три
Во-первых, мы хотим рассказать вам о том,
Во-вторых, мы хотим
В-третьих, мы хотим
Вначале мы расскажем, почему мы написали книгу «Трансформация» и как она связана с предыдущими работами: «Вдохновленные» и «Создающие ценность».
Далее мы изложим основные причины, по которым компании начинают такой долгий и затратный процесс, как подобная трансформация.
Затем мы перейдем к описанию типичных траекторий трансформации, которые обычно приводят к одним и тем же предсказуемым и разочаровывающим результатам.
Важно, что вы получите реалистичное понимание того, что требуется для успешной трансформации. Многие люди будут говорить вам, что это легко: достаточно взять их на работу, и они все организуют. В действительности все обстоит совсем иначе.
Но нам важно убедить вас в том, что добиться успеха – реально. И еще мы хотим, чтобы вы поняли, на что будет способна ваша компания, когда вы разовьете эти новые мускулы.
И наконец, мы поможем преодолеть распространенную проблему: вы знаете, что пора меняться, но в компании нет руководителей с опытом работы в новой модели.
Эта книга написана для тех, кто пытается помочь своей компании перейти к продуктовой операционной модели.
К ним относятся:
• Участники продуктовых команд, которые пытаются перейти к продуктовой модели.
• Продуктовые лидеры, пытающиеся провести свою компанию через эти изменения.
• Топ-менеджмент компании, особенно генеральный и финансовый директора, которые хотят знать, что включает в себя переход к продуктовой модели, чтобы решить, готовы ли они этим заниматься, и если да, то какова будет их роль.
• Другие руководители компании, ключевые стейкхолдеры и сотрудники, на которых повлияет продуктовая модель и которые захотят принять конструктивное участие.
• Тренеры по работе с продуктом, которые стремятся помочь компаниям успешно перейти к продуктовой модели.
Один из самых частых вопросов: «Если мы не технологическая компания, то зачем нам продуктовая модель?»
Это очень распространенное заблуждение. Когда мы, специалисты по продукту, говорим о «технологической компании», то имеем в виду не то
Tesla продает автомобили. Netflix продает развлечения. Google продает рекламу. Airbnb продает место, где вы отдыхаете. В Amazon начинали с продажи книг, а теперь продают практически всё.
Дело не в том,
Продуктовая операционная модель предназначена для компаний, где считают, что их бизнес должен опираться на технологии. И сегодня это самый широкий круг компаний практически во всех отраслях.
Как эта книга связана с предыдущими книгами «Вдохновленные» и «Создающие ценность»?
Мы написали «Вдохновленные», чтобы поделиться лучшими практиками и техниками, которые используют передовые продуктовые команды, работающие в продуктовой модели.
Затем мы написали книгу «Создающие ценность», в которой раскрыли наиболее эффективные практики и методы, которые используют ведущие продуктовые лидеры, чтобы создать для своих продуктовых команд условия, необходимые для процветания продуктовой модели.
И тем не менее самый распространенный вопрос, который мы слышим: «Наша компания работает совсем не так, как вы описываете. Возможно ли вообще для такой компании, как наша, перейти на продуктовую модель и как нам поменяться?»
Цель нашей книги – ответить на этот вопрос.
На протяжении последних 20 лет мы в SVPG помогаем компаниям осуществлять эти изменения.
Мы видим, что часть компаний – как правило, молодые и основанные в эпоху интернета – фактически родились из этой новой модели продуктовых компаний в сфере технологий. Для них такой способ работы естественен.
Однако для подавляющего большинства компаний в мире описанные нами методы работы очень непривычны.
Один генеральный директор охарактеризовал процесс трансформации как «переход с правостороннего движения на левостороннее, но поэтапный».
В этих компаниях знают, что им необходимо трансформироваться, чтобы конкурировать в эпоху быстро меняющихся технологий, но понимают, что объемы необходимых изменений весьма значительны и представляют много сложностей.
Если вы читали книги «Вдохновленные» или «Создающие ценность», то уже знаете, из чего состоит продуктовая модель, однако в прошлых книгах не говорилось о том, как внедрить необходимые изменения в бизнес-процессы.
А если вы не читали другие наши книги, то найдете здесь все необходимое для понимания принципов продуктовой модели и сможете заложить фундамент для необходимой трансформации.
К сожалению, в технологической отрасли не очень хорошо обстоят дела со стандартизацией терминов. Мы часто используем разные слова для обозначения одного и того же понятия, а в некоторых случаях даже разные определения одного и того же термина.
Нам бы не хотелось усугублять это положение, но мы должны отчетливо представлять, что имеется в виду, когда говорим в этой книге о ключевых понятиях.
Наиболее фундаментальная концепция, которую мы используем и которую необходимо четко понимать, – это общая
Не мы изобрели этот термин. Он используется в нескольких лидирующих продуктовых компаниях, а ряд других выбирают сокращенную форму
Продуктовая операционная модель – это не процесс и даже не единый способ работы. Это
В нашей книге мы используем данный термин для обозначения способа работы, который, как мы можем наблюдать, последовательно применяют лучшие продуктовые компании.
По сути, операционная продуктовая модель – это последовательное создание технологических решений, которые нравятся вашим клиентам и при этом работают на пользу вашему бизнесу.
С финансовой точки зрения речь идет о том, чтобы получить максимальную отдачу от инвестиций в технологии.
Важно подчеркнуть, что
Также хотим отметить момент, который мы подчеркиваем в каждой из наших книг.
Компанию с продуктовой операционной моделью иногда называют
Аналогичным образом, хотя компания с продуктовой операционной моделью является примером
Еще сложнее обозначить ту модель, от которой вы хотите уйти.
Основной вопрос, позволяющий выявить вашу предыдущую модель, можно сформулировать так: кто на самом деле сидит за рулем?
Во многих компаниях при составлении стратегии люди постоянно говорят про «бизнес» и используют то, что принято называть
Близким родственником ИТ-модели является
Если за рулем находятся ключевые специалисты из разных направлений, то такую модель часто называют
Если ведущую роль играет отдел продаж, то вы часто будете слышать термин
В этой книге мы просто называем модель, от которой вы уходите,
Во второй части этой книги, «Что такое трансформация», вы найдете подробное определение, что значит работать в продуктовой модели.
Также в нашей книге мы рассмотрим еще несколько важных терминов и понятий, связанных с продуктами, и дадим им определение по ходу повествования.
Этот, казалось бы, простой вопрос возникает очень часто, но в нем содержится несколько уровней, а причины, по которым люди задают этот вопрос, могут сильно различаться.
Иногда сотрудника беспокоит, что его работа не предполагает контакта с клиентом, как в случае с приложением для онлайн-продаж или потребительским устройством. Возможно, он работает над внутренним инструментом, используемым коллегами для обслуживания клиентов. А может быть, он работает над платформенным сервисом, который применяется для создания других типов продуктов. Или это система в стиле бэк-офиса, которая собирает критически важные данные. А может быть, он создает девайсы, а не чисто программное обеспечение. У нас есть разные термины для этих типов работы, но будьте уверены, что все это продукты, в создании которых способна помочь продуктовая модель.
Иногда возникает сомнение, является ли то, над чем вы работаете,
Порой же люди задают этот вопрос, потому что на самом деле они ничего не разрабатывают. Многие виды продуктов не являются технологическими, и создают их не инженеры. Возможно, человек заведует взаимодействием со сторонним поставщиком и ему хочется знать, применима ли продуктовая модель и к нему тоже. В этом случае – нет. Продуктовая модель предназначена для решения специфических задач среди тех, кто
Если вы решили прочитать эту книгу, то, скорее всего, у вас уже есть свои причины приступить к трансформации.
Но если ставки настолько высоки, а усилия требуются настолько значительные, полезно четко сформулировать свою цель.
Как правило, мы видим, что в компаниях руководствуются одним или несколькими из трех основных факторов.
Почти не осталось отраслей, которые избежали бы атаки новых конкурентов, предлагающих клиентам очевидно более привлекательные решения.
На данный момент новейшая прорывная технология, генеративный искусственный интеллект, уже меняет конкурентную среду во многих отраслях. Как это обычно бывает, одни компании используют новую технологию для решения давних проблем своих клиентов революционными способами, о которых раньше никто и не мечтал, а другие остаются позади.
Прорывные инновации появляются в таких разных сферах, как финансовые услуги, здравоохранение, розничная торговля, автомобилестроение, логистика, реклама и даже освоение космоса.
В некоторых отраслях стоимость перехода на новую платформу выше, существуют более серьезные регуляторные барьеры либо присутствует определенная степень государственной защиты, поэтому процесс внедрения прорывных инноваций занимает больше времени, но даже там игроки рынка не чувствуют себя в достаточной мере спокойно.
В этих компаниях понимают, что в борьбе за клиентов они используют оружие и стратегии, которые работали раньше, а сегодня уже не могут сравниться с новыми инструментами и возможностями противников.
В других компаниях впечатлены финансовыми результатами, которых достигают те, кто проявил способность на постоянной основе внедрять инновации в интересах своих клиентов.
Они видят, как растет стоимость компаний нового поколения, а также какие награды ждут тех, кто успешно трансформировался, и перспектива таких достижений мотивирует инвесторов, руководителей, продуктовых лидеров и сотрудников идти по аналогичному пути.
Некоторые компании выбирают продуктовую модель, потому что их разочаровали огромные вливания в технологическое развитие компании, не давшие ощутимой отдачи.
Их тяготит постоянный перерасход средств, досадно низкие результаты, большие затраты времени на внедрение обновлений, жалобы клиентов и бесконечный поток обвинений и оправданий.
Возможно, руководители читали о компаниях, где тратят меньше денег, а получают гораздо больше, и им хочется узнать, возможно ли применить эти методы в своей организации.
В некоторых случаях один или несколько дополнительных факторов подталкивают руководителей компании к ощущению необходимости взять курс на преобразования:
• Возможно, самые способные технические специалисты покидают компанию, разочаровавшись в текущей бизнес-политике.
• Возможно, был нанят руководитель, который пришел из сильной продуктовой компании, и он побуждает остальных рассмотреть этот подход.
• Возможно, ожидания клиентов изменились и, хотя пока они сохраняют лояльность, все громче слышно их недовольство и продуктами, и темпами их совершенствования.
Какими бы ни были мотивы, по сути компании трансформируются, поскольку в них появляется
В большинстве компаний, с которыми мы сотрудничаем по вопросам трансформации, уже пытались провести преобразования – как минимум раз, – прежде чем поняли, что потратили кучу времени и денег в никуда.
История, о которой пойдет речь ниже, до боли нам знакома. Мы убрали имена, но обстоятельства совершенно реальны. Посмотрите, похожа ли ваша ситуация на то, что мы описываем.
Итак, данная компания доминировала на рынке финансовых операций с момента своего основания в 2000 году. Она всегда была ориентирована на клиента и гордилась тем, что может предоставить именно то, что клиенту требуется. В итоге это привело к появлению длинной серии «специальных предложений» для удовлетворения предполагаемых потребностей различных индивидуальных клиентов.
Изначально эта нацеленность на необходимость сделать все для заключения сделки приносила реальный успех в делах. Быстрое удовлетворение потребностей клиентов стало фирменным стилем бренда как внутри компании, так и за ее пределами.
Но успех не длился вечно.
Несмотря на увеличение численности персонала и практику переработок, сроки создания новых возможностей заметно снизились. В то же время на рынке появилось несколько новых участников. Каждый из них развивался, быстро набирая обороты. В результате продажи нашей компании стали отставать, а доля рынка – падать.
В ответ на это организация перешла на агрессивную стратегию поглощений, быстро покупая и интегрируя дополнительные решения. Однако приобретения не только не вывели ее на новый уровень прибыльности, но и принесли немало проблем.
Совет директоров отреагировал решительными изменениями на самом верху.
Новый генеральный директор компании пришла с впечатляющим послужным списком в коммерческой сфере. Быстро пройдя путь по карьерной лестнице в международной консалтинговой компании и став самым молодым старшим партнером в ее истории, она[1] занимала различные руководящие должности в многочисленных финансовых организациях.
Как начинающий генеральный директор она понимала, что на кон поставлена вся ее карьера. Нельзя было допустить провала, поэтому она с энтузиазмом взялась за дело. Компания по-прежнему занимала значительную долю рынка, имела узнаваемую торговую марку и приносила прибыль. Но наш новый директор понимала, что необходимы кардинальные перемены, о чем и сообщила совету директоров. Ее напутствовали поручением возродить бренд.
Она использовала отработанную схему действий, которую применяла в различных отраслях за годы работы консультантом по управлению. Сначала было решено диагностировать имеющиеся проблемы.
За прошедшие годы компания превратилась в разветвленную организацию с офисами по всему миру, включая США, Индию и Европу. В результате возникли глубокие культурные различия.
После нескольких лет роста за счет поглощений компания, по сути, представляла собой конгломерат из нескольких подразделений с недостаточной интеграцией, большим техническим долгом (то есть накопившимися недоделками в программном обеспечении) и разочарованными клиентами.
Предыдущие связи позволили новому генеральному директору быстро прибегнуть к услугам консалтинговых служб, которые помогли оперативно выявить ряд устаревших практик, оставшихся от предыдущих этапов.
Предстояли значительные перемены. Они включали в себя новую централизованную организационную структуру, перевод технических подразделений в штат, более целенаправленную бизнес-миссию и создание нового продуктового подразделения, в которое вошли продуктовые менеджеры и дизайнеры. Для руководства преобразованиями был нанят новый директор по цифровым технологиям (CDO).
Параллельно решались многочисленные задачи, и не в последнюю очередь – привлечение технических кадров. Наем команды из 600 инженеров в сложных рыночных условиях предполагал высокие зарплаты, и за 12 месяцев компания вышла за рамки бюджета, но все еще не достигла требуемых показателей. Чтобы сократить расходы, вместо того чтобы нанимать квалифицированных менеджеров по продукту, компания решила переименовать команду бизнес-аналитиков. Обоснованием послужило то, что продукты сложны и требуют глубокого опыта работы в данной области.
Однако перемены оказались более радикальными и дорогостоящими, чем предполагала компания. Отдел продаж, который долгое время считался единственным ответственным за заботу о клиентах, был недоволен изменениями и обратился с жалобой непосредственно к генеральному директору. И хотя новый директор по цифровым технологиям положительно отзывался о найме новых инженеров и появлении нескольких продуктовых команд, дело продвигалось медленно, а затраты продолжали расти.
За спиной руководителей новые инженеры возмущались уровнем технического долга. Каждая из поглощенных компаний продолжала работать на своей технической базе, унаследованной от прошлого юридического лица. Серьезных попыток интегрировать все это разношерстное программное обеспечение не предпринималось. Многие сотрудники ушли. Те, кто остался, едва могли поддерживать многочисленные системы в рабочем состоянии. Инженеры не видели другого выхода, кроме как немедленно все перенести на новую платформу.
В частном порядке руководители с пониманием отнеслись к такой инициативе, но у них не было особого желания взваливать на себя еще одну серьезную задачу и выделять время для масштабного переноса. Поэтому новым инженерам было рекомендовано перестроить программный код там, где это возможно, но при этом постараться найти способ ускорить разработку по «дорожной карте».
Увы, после двух лет преобразований скорость рабочих процессов лишь снизилась. Генеральный директор решила, что основная проблема заключается в инженерных разработках и данному направлению нужна помощь для обеспечения предсказуемых и надежных результатов.
ИТ-директор (CIO) рекомендовал перейти на новый, более формальный и структурированный процесс разработки, и команды прошли переобучение этому процессу в надежде повысить предсказуемость, хотя и с более длинными и менее частыми циклами выпуска.
Но при еще меньшем количестве релизов возникло новое поле битвы: подразделения стали бороться за то, кто сможет впихнуть большее количество функций (иногда называемых фичами), чтобы удовлетворить потребности клиентов и оправдать их затраты на обновление версий продукта. Кроме того, возникли значительные накладные расходы на новые процессы.
Поскольку теперь к каждому редкому релизу было приковано все внимание, руководство наняло команду технических менеджеров, которые следили за процессом разработки, добавив новых правил и контроля.
Тем временем затраты продолжали расти, а релизы появлялись все реже и реже. На этом безрадостном фоне конкуренты процветали. Первоначальные надежды совета директоров на успех были уже практически забыты.
Кроме того, многие из недавно нанятых инженеров уволились, сославшись на некомпетентность руководства. Удерживать клиентов становилось все труднее, многие пользователи были разочарованы очевидным отсутствием прогресса.
Решив, что терять нечего, группа ключевых специалистов из продуктового и технического отделов решили обратиться напрямую к генеральному директору.
По их мнению, текущие технологии не давали компании удовлетворять потребности клиентов, а уровень бюрократии был настолько высок, что они не видели возможности продвинуться вперед.
Ни один из вариантов не подходил для решения накопившихся проблем. Давала о себе знать технологическая бесхозяйственность прошлых лет.
Потратив десятки миллионов долларов на трансформацию, генеральный директор задавалась вопросом, каков же итог этих инвестиций. После четырех лет мучений и трат она стала объектом разочарования остальных топ-менеджеров, и ей сообщили о лишении поддержки совета директоров.
Трансформация компании сначала буксовала, а затем окончательно провалилась.
Пожалуй, самый важный урок, который мы усвоили за 20 лет помощи компаниям в трансформации продуктовой модели, – это критически важная роль, которую должен играть генеральный директор в том, чтобы преобразование стало успешным.
Пожалуйста, не поймите неправильно. Генеральному директору не обязательно иметь опыт работы с продуктовой моделью. И он не должен тратить на саму трансформацию много рабочего времени.
Но тем не менее эта роль критически важна.
Конечно, каждый генеральный директор скажет, что поддерживает преобразование своей компании всем сердцем.
Но большинство не понимает, что это значит, пока не дойдет до дела.
Проблема вот в чем: преобразования затрагивают компанию гораздо шире, чем просто превращение бывшего технологического отдела в новое направление.
Суть в том, что трансформация включает в себя и отдел продаж, и отдел маркетинга, и финансовую службу, и кадровую, и юридическую, и развитие бизнеса, и корпоративную этику, и производство.
В этой книге мы рассмотрим, как и почему преобразования влияют на каждую из этих областей. Но сразу заметим, что не все руководители и стейкхолдеры с энтузиазмом отнесутся к переходу на новый стиль работы.
Большинство из них захотят хотя бы попробовать подход, который может в перспективе дать более высокие результаты. И многие из этих людей понимают, что успешная работа в продуктовой модели становится все более ценной строчкой в резюме.
Также важно понимать, что даже у самого увлеченного стейкхолдера или руководителя могут возникнуть вопросы или вполне обоснованные возражения, которые необходимо обязательно рассмотреть.
Но часть сотрудников будет оказывать пассивное сопротивление, а кое-кто даже активное. Эти люди будут защищать свое текущее положение и обязанности, а кроме того, по понятным причинам привычные проблемы всегда пугают меньше, чем новые и неизвестные.
Все эти встревоженные стейкхолдеры в конце концов подчиняются генеральному директору, и именно к нему они пойдут, чтобы выяснить, действительно ли все это важно и необходимо.
Как говорил легендарный бизнес-тренер Билл Кэмпбелл, «компанию волнует то, что волнует ее лидера».
Слишком часто генеральный директор делегирует ответственность за преобразования ИТ-директору, директору по цифровым технологиям или директору по трансформации. И хотя эти люди могут влиять на решения и действия
Если вы генеральный директор, возможно, вы впервые слышите, что трансформация – это нечто, выходящее за рамки информационных технологий. В таком случае вам необходимо принять во внимание данный факт.
В большинстве компаний действительно начинают преобразование с того, что сосредотачиваются на необходимых изменениях в продукте, дизайне и разработке. И это правильно, потому что до тех пор, пока не откроются эти возможности, все остальное будет преждевременным.
Нужно развить новые компетенции, привить персоналу новые навыки и принципы работы и, что самое важное, изменить корпоративную культуру.
Печально, когда компания осознаёт
Скажем прямо,
Если ваш генеральный директор не хочет или не может поддерживать переход к продуктовой модели, то вы сэкономите время, деньги и нервы, реалистично оценив свой уровень готовности.
Но есть и хорошая новость: компания, которой удалось успешно перейти на продуктовую модель, улучшает рабочую ситуацию для всех, а не только для продуктового и инженерного направлений.
Сотрудники испытывают больше гордости за продукцию своей компании. Маркетологам есть что продвигать и позиционировать. Отдел продаж наращивает сделки. Все видят финансовый эффект. Крепнет моральный дух коллектива, снижается процент увольнений.
Все это говорит о том, что у генерального директора есть весомые причины активно поддерживать процесс трансформации и помогать ему.
Надеюсь, что к этому моменту вы уже начали понимать, что мы имеем в виду, когда говорим, что трансформация – это тяжело.
Наша книга призвана подготовить вас к тому, что ждет впереди.
Здесь вы
На протяжении всей книги будут появляться истории трансформации – примеры успешных преобразований, а также примеры новаторства – инновационных решений, созданных в компаниях, которые уже провели трансформацию.
Примеры трансформации призваны вселить в вас уверенность, что, несмотря на трудности, успех
Примеры инноваций призваны вдохновить вас теми возможностями, которые перед вами откроются после перехода к продуктовой модели.
Кроме наглядных примеров, в книге есть следующие части.
Часть II «Что такое трансформация» мы начнем с исчерпывающего определения того, что на самом деле подразумевается под трансформацией в продуктовую операционную модель.
Следующие две части посвящены новым навыкам и способностям, которые вам нужно будет развивать, чтобы перейти к продуктовой модели.
В части III, согласно ее названию, мы сначала обсудим компетенции продуктовой модели, которые вам понадобятся для трансформации. Если вы думаете, что в вашей компании уже есть нужные специалисты, вы почти наверняка ошибаетесь и ваши начинания обречены на провал. Следите, чтобы вас не обманули те, кто просто приписал себе эти компетенции.
Далее, в части IV «Ключевые понятия продуктовой модели», мы представим основные понятия продуктовой модели, а также принципы, на которых она основана и которые лежат в ее фундаменте. Большинство компаний очень быстро понимают, что не имеют представления об этом, а это первый шаг к тому, чтобы оно появилось.
В части VI «Продуктовая модель на практике» мы обсудим, как продуктовое направление конструктивно и эффективно сотрудничает с клиентами, отделом продаж, маркетинговым и финансовым отделами, стейкхолдерами и топ-менеджментом компании.
Далее, в части VIII «Техники трансформации», мы обсудим методы трансформации, которые помогут вашей организации пройти через изменения подобного масштаба. Перемены всегда трудны, но есть несколько ключевых техник и тактик, призванных облегчить трансформацию. Мы начнем с оценки текущего состояния организации, а затем опишем различные тактики. Мы также расскажем о важности постоянного евангелизма, то есть популяризации новой продуктовой модели в коллективе.
Возможно, вы уже поняли, что тут есть некая загвоздка. Разве компания, которая никогда не работала по-новому и в которой, скорее всего, нет руководителей с таким опытом, может перейти на новые рельсы?
Книги и различные виды тренингов могут вам помочь (если авторы этих книг и эти тренеры знают, о чем говорят), но, как правило, этого недостаточно. Мы рассмотрим, как перейти к новой модели, если ваши руководители никогда раньше не работали таким образом.
Далее, в части X «Работа с возражениями», мы обсудим различные проблемы, которые обычно возникают у каждого из ключевых стейкхолдеров: отдела продаж, маркетинга, отдела заботы о клиентах, финансовой и кадровой службы, ИТ-директора, руководителей проектов, гендиректора и совета директоров. А также рассмотрим вопросы, которые возникают непосредственно внутри продуктового направления.
Все это – обоснованные возражения и опасения, и люди обычно высказывают их из лучших побуждений просто потому, что видят проблему и еще не знают, как она будет решена. Мы рассмотрим каждое из этих возражений, а затем обсудим, как их преодолеть.
В части XI «Заключение» мы попытаемся сложить все элементы картины воедино и подвести итог важнейшим моментам, рассмотренным в книге, – включая то, какие закономерности объединяют примеры трансформации и в чем секрет ее успеха.
Успешную трансформацию трудно осуществить, она требует решения сложных вопросов там, где нередко люди, вовлеченные в процесс, не хотят этого слышать.
Исходя из этого, мы начнем с горькой пилюли, предназначенной для продуктовых лидеров[2].
Несомненно, что руководство компании должно играть важную роль в ее преобразовании.
Однако неожиданностью для многих продуктовых лидеров является то, что им предстоит проделать
Вызывает недоумение, когда продуктовые лидеры считают, что, как только руководство поменяет курс организации, все станет хорошо. Они направляют свою энергию на то, чтобы заставить измениться других, а не на то, чтобы измениться самим.
Они жалуются на слабых менеджеров по продуктам.
Они жалуются на то, что их не наделяют нужными полномочиями.
Они жалуются на инженеров, которые не горят желанием работать в новом ключе.
Они жалуются на то, что стейкхолдеры не доверяют им.
Они жалуются на руководителей компаний, которые требуют подробных «дорожных карт» продукта.
При этом они, похоже, не понимают, что каждая из этих проблем – следствие их собственных действий (или бездействия, в зависимости от ситуации).
Если продуктовый лидер не хочет брать на себя ответственность за повышение уровня квалификации своих сотрудников или исправлять ошибки при найме, то в продуктовых командах будут работать люди, не обладающие необходимым уровнем компетенций.
Разве удивительно, что командам будет не хватать полномочий?
Разве удивительно, что инженеры будут вести себя как равнодушные подрядчики?
Разве удивительно, что ключевые специалисты других направлений будут коситься на них с недоверием?
Разве удивительно, что генеральный директор не доверяет людям, ответственным за слабые продукты?
Если говорить в целом, то вам как продуктовому лидеру следует помнить о двух важных вещах, когда вы приступаете к преобразованиям. Во-первых, ваши возможности по-хозяйски влиять на происходящее прямо связаны с доверием, которое вам удалось завоевать; и во-вторых, часть вашей работы как продуктового лидера заключается в том, чтобы переубеждать людей и заражать их верой в новую модель.
Хотя руководство действительно должно многое изменить ради перехода к продуктовой модели, еще большие изменения требуются от продуктовых лидеров и продуктовых команд.
Мы намерены четко обозначить изменения, которые необходимы со
Существует много негативных образов, связанных с трансформацией.
Многие из нас были свидетелями неудачных преобразований, но мало кто был свидетелем настоящего успеха. Это делает уроки, извлеченные из успешных преобразований, необычайно ценными.
Один из вопросов, который мы слышим довольно часто: «Что такого наша компания сможет сделать после трансформации, чего мы не могли сделать раньше?»
Поскольку в продуктовой отрасли часто говорят о «работе на результат», мы считаем, что это правильный вопрос.
И в этой книге особое внимание уделяется возможностям и результатам тех компаний, которые прошли трансформацию, особенно их способности реагировать на угрозы и пользоваться новыми перспективами.
Итак, предположим, что руководители компании искренне считают, что им необходима трансформация.
Многие из вас слышали такие слова: «Хотя переход на “гибкую методику” Agile необходим, но его недостаточно».
Или: «Суть трансформации заключается в переходе от функциональных команд к продуктовым командам с широкими полномочиями».
Или: «Цель – превратиться в компанию, ориентированную на продукт».
Хотя каждый из этих комментариев описывает определенный аспект трансформации, ни один из них не дает внятного, целостного представления о том, что на самом деле подразумевается под
Поэтому в этой книге мы используем другой подход.
Вместо поверхностных ярлыков (Agile, «команды, наделенные полномочиями», «продуктоориентированная компания») мы погрузимся на более глубокий уровень и выясним, что
В этой книге мы рассмотрим продуктовую модель как преобразование организации по трем различным параметрам:
1. Изменение подхода к разработке.
2. Изменение алгоритма решения проблем.
3. Изменение подхода к определению приоритетов.
Несмотря на то что Agile существует уже много лет, большинство компаний по-прежнему делают ежемесячные или ежеквартальные (а то и реже) «ударные» релизы.
Получило распространение такое явление, как
Однако компания и клиенты нуждаются в надежной услуге, в которой они могут быть уверены.
Это означает, что обновления должны быть частыми и небольшими. Это означает использование технологий в полном объеме, чтобы вы знали, как они работают, а также как их использовать. Это означает, что нужно отслеживать собственные технологические процессы, чтобы обнаруживать проблемы раньше, чем это сделают ваши клиенты. А кроме того, это значит, что вы сможете продемонстрировать пользу от новых функций, прежде чем широко внедрять их.
Если вы не применяете практики непрерывной разработки и внедрения, то как минимум следует выпускать
Когда в компании говорят о переходе от функциональных команд к продуктовым командам с широкими полномочиями, в основном имеется в виду изменение алгоритма решения проблем.
Вместо того чтобы ключевые специалисты разных направлений определяли приоритеты в списке будущих решений (функций и проектов) и предоставляли их в виде «дорожной карты» функциональной команде, появляется продуктовая команда, которой выдают список проблем и наделяют полномочиями для их решения. А задачей команды становится найти такое решение, которое создаст новую ценность, будет пригодно для использования, рентабельно и жизнеспособно.
Смысл в том, чтобы поручить поиск наилучшего решения людям, которые находятся ближе всего к технологиям и к пользователям, взаимодействующим с этими технологиями.
На практике это означает развитие навыков быстрого тестирования идей продукта, чтобы обнаружить решение, которое стоит разрабатывать (это называется
Важно отметить, что это изменение подразумевает новые отношения с ключевыми стейкхолдерами компании: продуктовая команда больше не подчиняется им, а сотрудничает на равных, и теперь ей предстоит найти решение, которое понравится клиентам и при этом будет работать на благо бизнеса.
Когда ваши сотрудники овладевают навыками исследования продукта, чтобы стабильно и оперативно решать сложные проблемы на радость клиентам и одновременно на пользу бизнесу, – это скачок в развитии компании, по любым меркам. Но возникает вопрос: «А как вы определили, что это и есть главная проблема, которую нужно решить?»
В предыдущих моделях этим, как правило, занимаются стейкхолдеры. В продуктовой модели появляется новая и критически важная компетенция – продуктовый лидер.
Каждая компания в своей деятельности сталкивается с чередой угроз и стоит перед широким полем возможностей. Какие угрозы вы воспринимаете всерьез и какие возможности решаете использовать? Порой это вопрос жизни и смерти всего бизнеса.
Сильная продуктовая компания имеет убедительное видение продукта и продуктовую стратегию, основанную на глубинном анализе (инсайтах), позволяющем определять приоритетные проблемы, без которых не получится достигнуть бизнес-целей.
Несколько важных замечаний.
Во-первых, все эти три аспекта – изменение подхода к разработке, алгоритма решения проблем и подхода к определению приоритетов – зависят от сильного продуктового лидерства (как в управлении продуктом, так и в дизайне и разработке продукта), и мы надеемся, что вы начинаете понимать, почему эта роль так сложна. Люди, работающие в продуктовых командах, нуждаются в наставничестве и в том, чтобы понимать стратегический контекст своей работы.
Во-вторых, на высоком уровне вы можете рассматривать каждую из этих трех граней как последовательные этапы, и часто используют именно такой подход к трансформации компании. Но в действительности каждая из этих трех граней представляет собой спектр, и вы можете и должны добиваться прогресса на разных гранях параллельно. Подробнее об этом поговорим в части VIII «Техники трансформации».
Итак, поведем итог.
• Изменение методов разработки и внедрения означает переход от больших ежеквартальных релизов к череде небольших, последовательных и частых релизов. Это ключ к тому, чтобы снизить затраты времени выхода на рынок.
• Изменение алгоритма решения проблем означает отказ от «дорожных карт» и команд по разработке функций, подчиненных стейкхолдерам, и переход к командам по разработке продуктов, которым дали полномочия самостоятельно решать поставленные задачи, а затем позволили проводить исследование продукта для обнаружения технологических решений, которые будут ценными для пользователей, пригодными для применения, рентабельными и жизнеспособными. Это означает, что вы решаете проблемы как для клиента, так и для вашего бизнеса. Данное изменение – ключ к постоянному улучшению сроков окупаемости.
• Изменение того, как вы определяете приоритеты в решении проблем, как правило, является самым важным, поскольку от этого зависит, какие возможности вы решите использовать и как вы получите максимальную отдачу от своих инвестиций – сюда входит видение (образ) продукта и его стратегия. Изменения в этой области являются ключевыми для получения максимальной отдачи от инвестиций в технологии.
Надеемся, этот план поможет вам более комплексно подойти к вопросу о преобразованиях, которые необходимо провести вашей компании, и точнее определить, на каком этапе этого пути вы находитесь.
В следующих трех главах мы подробно рассмотрим каждую из этих граней и расскажем,
Хотя эти понятия могут быть несколько техническими, от вас не требуется глубокое понимание технологий, чтобы увидеть их важность и ценность для вашего бизнеса и ваших клиентов.
Инвестиции в технологии – это создание ценности для ваших клиентов и вашей компании.
Есть несколько важных аспектов создания этой ценности, но в конечном счете основной специалист, от которого зависит создание продукта, – это ваш инженер.
Для многих компаний, работающих с технологиями, инженеры являются самой крупной статьей расходов.
В большинстве предыдущих моделей каждая технологическая операция обычно рассматривается как проект.
Каждый проект финансируется, укомплектовывается персоналом, планируется, выполняется и реализуется. Проект заканчивается после сдачи, и люди переходят к другим задачам.
Не забывайте, что все, что мы разрабатываем, представляет ценность на двух уровнях: во-первых, это продукт, который мы производим, а во-вторых, это опыт, который мы получаем. В проектной операционной модели теряется большинство того, чему мы научились.
Когда мы снова захотим поработать над этой областью, то потратим время и деньги на повторное изучение того, за что уже однажды заплатили. Или, что более вероятно, мы не будем восстанавливать эти знания и это дорого обойдется.
Кроме того, команды, существующие с программным обеспечением, которое сами разработали, относятся к нему иначе, чем команды, знающие, что по завершении проекта больше его не увидят. Вот почему в проектной модели так распространен технический долг.
Можно сравнить это с ремонтом дома на продажу и для себя. В первом случае достаточно просто переклеить обои. Это быстро, дешево, а когда стены начнут шататься, это будет головная боль нового владельца.
Неслучайно именно так работает аутсорсинг, и мы часто говорим, что если вы хотите работать с таким подходом, то наймите консалтинговую компанию: она умеет это делать лучше вас.
Но в продуктовой модели такой способ работы слишком затратен в плане времени и денег, и, что еще важнее, он почти никогда не обеспечивает тех инноваций, что нужны вашим клиентам и вашей компании.
Вот почему трансформация начинается с изменения
В продуктовой модели продуктами руководят непрерывно – они совершенствуются каждую неделю (а в сильных продуктовых компаниях – несколько раз в день), как правило, в течение нескольких лет.
Вы можете менять работу команд, добавляя новые возможности, получая дополнительную прибыль, снижая операционные расходы или решая любые другие задачи, стоящие перед компанией. Но, как правило, команда продолжает вкладываться в продукт до тех пор, пока компания не решит прекратить расширение и не перейдет к поддержанию текущего дохода, либо пока не будет принято решение о полном прекращении выпуска данного продукта.
В этой модели непрерывного развития вам нужны небольшие, бесплатные и надежные средства выпуска.
Компании, производящие успешные продукты, уже много лет назад поняли, что, хотя это может показаться нелогичным, статистика очень четко показывает: чем больше вы разрабатываете и чем больше изменений вносите, тем лучше для вас – и особенно для ваших клиентов. Словом, выпускать обновления нужно как можно чаще[5].
Если вы искренне заботитесь о том, чтобы обеспечить надежный сервис для своих клиентов, гораздо проще обеспечить небольшое количество изменений и не рисковать появлением неожиданных проблем, чем сгруппировать большое количество изменений в один релиз и пытаться выпустить все сразу (в индустрии это называется «ударный» релиз).
Подчеркнем еще раз: если каждая из ваших продуктовых команд не выпускает обновление хотя бы раз в две недели, то вы не сможете заботиться о своих клиентах на необходимом уровне[6].
Кроме того, при внедрении новых возможностей необходимо следить, чтобы они функционировали – так вы будете знать, что продукт работает корректно, и понимать, как ваши клиенты используют его на самом деле. Вам также необходимо постоянно держать руку на пульсе, чтобы обнаруживать любые проблемы раньше клиентов. Для многих важных изменений необходимо продемонстрировать, что новая функция приносит необходимую пользу, прежде чем широко внедрять ее (стандартный способ это сделать – провести A/B-тестирование).
Вы можете возразить, что на ваш тип продукта это не распространяется или что ваши клиенты сами просят обновлять продукт
Вы почти наверняка слышали об Agile. Основная причина, по которой многие компании перешли на Agile-процессы за последние 20 лет, заключается в том, что эти методы должны были создать давление на продуктовые команды и заставить их перейти на последовательные, небольшие и частые релизы.
Переход на небольшие и частые релизы и впрямь может потребовать значительных инвестиций – в основном в тестирование и автоматизацию внедрения. Но компании, которым удалось при помощи методов Agile перейти к
Однако важно понимать, что для последовательных, небольших и частых релизов Agile-методы необязательны.
На самом деле, многие опытные продуктовые команды по всему миру освоили методику последовательного внедрения очень маленьких релизов (так называемая
Напротив, есть организации, которые тратят много времени и денег на Agile-коучей, на ритуалы, роли, методы и процессы, но итогом этих значительных инвестиций по-прежнему остаются ежеквартальные продукты и связанные с этим неудобства для клиентов.
Будем откровенны, поскольку этот момент крайне важен. Если ваша компания по-прежнему выпускает релизы ежегодно, ежеквартально или даже ежемесячно, то неважно, сколько Agile-ритуалов вы соблюдаете и сколько у вас трудится так называемых Agile-тренеров. Это не Agile ни в каком значении слова, вы упускаете все преимущества этого метода и не работаете на пользу своих клиентов и собственного бизнеса.
Многие компании потратили миллионы долларов на переход к Agile-процессам в надежде, что именно это и означает трансформацию, но значимых результатов как не было, так и нет. Если это ваш случай, то мы уверены, что вы разочарованы до глубины души.
Но на самом деле, независимо от того, подняли вы флаг Agile или нет, каждую продуктовую команду необходимо довести до уровня, когда она сможет выпускать частые, небольшие, надежные релизы не реже чем раз в две недели.
Если ваши сотрудники не могут этого выполнить, придется привлекать опытных руководителей, инженеров или настоящего тренера по разработке продукта, чтобы показать им, как это сделать.
Разработка, тестирование и внедрение – важный процесс вне зависимости от того, какой продукт вы решили создать, однако многие компании идут по пути простого наращивания функций.
Они превратились в настоящий конвейер по производству функций, но при этом не видно ни их ценности для клиентов, ни благотворного влияния на бизнес.
На самом деле в большинстве современных компаний доля по-настоящему прибыльных функций и проектов в «дорожных картах» удручающе мала. Большинство отраслевых аналитиков оценивают их в диапазоне от 10 до 30%.
Если вы сравниваете список возможностей, которые нужны вашей компании, с тем эффектом, который они приносят, и не чувствуете ожидаемой отдачи, то пришла пора менять алгоритм решения проблем.
Все дело в том, что эти продуктовые команды настроены на
Руководство и стейкхолдеры видят каждый свои специфические рабочие потребности и составляют список функций и проектов, которые, по их мнению, помогут выполнить обязательства перед бизнесом. Они передают эти приоритеты продуктовым командам, которые затем должны предоставить «дорожную карту» продукта с указанием сроков и результатов.
Почему же лишь немногие из этих функций приносят желаемую прибыль?
Дело в том, что каждая из этих функций – это
В рамках модели функциональной команды каждая функция из «дорожной карты» продумывается дизайнером этой команды, а затем создается инженерами этой команды. Но за то, принесет ли эта функция пользу вашим клиентам или компании, отвечает тот, кто попросил включить ее в «дорожную карту».
Как правило, это стейкхолдер, который осознает свои собственные потребности, но не обладает глубоким пониманием фоновых технологий, столь важных для технологических продуктов, и едва ли имеет роскошь постоянного личного общения с пользователями и клиентами о том, что их волнует и какие задачи им нужно решить.
В результате в модели функциональной команды вы не можете возложить на эту команду ответственность за бизнес-результаты. Она существует только для одного –
Однако и стейкхолдеры, принявшие решение о разработке данной функции, тоже не захотят брать на себя ответственность за неудачу. Они почти наверняка будут утверждать, что готовая функция оказалась не такой, как они надеялись, либо скажут, что ее разработка заняла больше времени, чем ожидалось. Именно поэтому между ключевыми специалистами направлений и функциональными командами обычно царит взаимное недоверие.
Еще одно серьезное последствие такого метода работы заключается в том, что в итоге вы получаете множество «бесхозных» фич – они не создают реальную ценность и просто ждут того дня, когда их возьмут в доработку, но это случается редко. В результате очень быстро накапливается технический долг, который может выйти из-под контроля и в конечном счете привести к кардинальному замедлению работы команды. В худшем случае это может поставить бизнес на край пропасти.
По какой бы причине вы ни потеряли способность стабильно генерировать ценность – внедрять инновации ради своих клиентов, – появление более успешного конкурента становится лишь вопросом времени. Рано или поздно, но он предложит вашим клиентам более привлекательное решение, и такое происходит сплошь и рядом.
Вы можете снижать цены, проводить хитрые маркетинговые кампании и акции, но эти меры в лучшем случае лишь оттягивают неизбежное. В конце концов, кто-то другой сможет обслуживать ваших клиентов так, как вы уже не сможете.
Давайте сравним вышеописанную модель с тем, как работает продуктовая команда, наделенная полномочиями. В этом случае вместо того, чтобы выдавать ей «дорожную карту» функций и проектов, подлежащих разработке, продуктовая команда получает
Нет ничего сложного в том, чтобы сесть за стол переговоров с соответствующими стейкхолдерами и пойти в обратном направлении: от конкретных функций, которые они запрашивают, к основной проблеме клиента или бизнеса, а затем обсудить, как будет измеряться успех и каков желаемый результат.
Вместо того чтобы просто внедрять функции, которых требуют другие отделы, продуктовая команда, наделенная полномочиями, должна предложить решение, которое окажется полезно
Это означает, что решение будет
Почему же продуктовая команда, наделенная полномочиями, превосходит функциональную команду, то есть ту, что разрабатывает отдельные фичи?
На то есть очевидные причины, такие как повышение морального духа благодаря чувству ответственности и надежным знаниям, полученным при тестировании потенциальных решений в непосредственном контакте с пользователями. Но основная причина заключается в том, что сильные продуктовые компании понимают:
В функциональной команде разработчики просто создают то, что их просят, а дизайнеры делают так, чтобы это выглядело красиво. Но, по сути, эти люди – не хозяева продукта, а наемники. Еще хуже, если вы отдаете разработку на аутсорсинг, тогда технические специалисты становятся
Но в продуктовой команде инженеры заняты не только разработкой, а дизайнеры – не только внешним видом продукта. Они также отвечают за помощь
Текст предоставлен ООО «Литрес».
Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.
Мы уже давно выступаем за расширение представлений о том, кто такой сильный лидер, поэтому в данной книге повсеместно используется местоимение «она» при описании типовых ситуаций. Но, разумеется, эта книга предназначена для любого человека. Всех, кто искренне вкладывает душу в развитие нашей продуктовой отрасли, мы считаем своими соратниками.
Небольшое уточнение по терминам. Менеджеры по продукту, дизайнеры продукта, ведущие технические специалисты, а также другие инженеры, аналитики данных и специалисты по пользовательскому опыту (UX-исследователи) – все это относится к
Самым вопиющим примером того, что называют фальшивым Agile, является подход SAFe (Scaled Agile Framework), но даже команды, использующие простую методику Scrum и выпускающие продукты только раз в месяц или квартал, упускают реальные преимущества Agile.
Что такое
Рекомендуем книгу Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations (Форсгрен Н., Хамбл Дж., Ким Дж. Ускоряйся! Наука DevOps: как создавать и масштабировать высокопроизводительные цифровые организации. – М.: Альпина PRO, 2022).
Вы услышите множество распространенных отговорок, почему ваша компания не может этого сделать, и мы рассмотрим их в части X «Работа с возражениями».