У этой книги три большие цели.

Во-первых, мы хотим рассказать вам о том, что такое продуктовая операционная модель и что значит работать таким образом.

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

В-третьих, мы хотим вдохновить вас — главным образом с помощью ряда впечатляющих примеров инновационных продуктов — визуализировать то, на что вы будете способны, если успешно трансформируете свою организацию.

Вначале мы расскажем, почему мы написали книгу «Трансформация» и как она связана с предыдущими работами: «Вдохновленные» и «Создающие ценность».

Далее мы изложим основные причины, по которым компании начинают такой долгий и затратный процесс, как подобная трансформация.

Затем мы перейдем к описанию типичных траекторий трансформации, которые обычно приводят к одним и тем же предсказуемым и разочаровывающим результатам.

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

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

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

Эта книга написана для тех, кто пытается помочь своей компании перейти к продуктовой операционной модели.

К ним относятся:

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

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

Наиболее фундаментальная концепция, которую мы используем и которую необходимо четко понимать, — это общая продуктовая операционная модель.

Не мы изобрели этот термин. Он используется в нескольких лидирующих продуктовых компаниях, а ряд других выбирают сокращенную форму «продуктовая модель».

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

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

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

С финансовой точки зрения речь идет о том, чтобы получить максимальную отдачу от инвестиций в технологии.

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

Также хотим отметить момент, который мы подчеркиваем в каждой из наших книг. Все, что вы здесь прочтете, было придумано до нас. Мы просто пишем о том, что наблюдаем в работе лучших продуктовых компаний. При этом мы не перегружаем вас подробностями, а фокусируемся на общих тенденциях и ключевых принципах. Фактически мы играем роль куратора и популяризатора.

Компанию с продуктовой операционной моделью иногда называют продуктоцентричной компанией или продуктоориентированной компанией. Нам не нравятся эти термины, потому что они порой имеют неприятный побочный эффект: людям начинает казаться, что в этой компании всем заправляют специалисты по продукту.

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

Еще сложнее обозначить ту модель, от которой вы хотите уйти.

Основной вопрос, позволяющий выявить вашу предыдущую модель, можно сформулировать так: кто на самом деле сидит за рулем?

Во многих компаниях при составлении стратегии люди постоянно говорят про «бизнес» и используют то, что принято называть моделью информационных технологий, или ИТ-моделью (в смысле «информационные технологии существуют, чтобы обслуживать бизнес»).

Близким родственником ИТ-модели является проектная модель, в которой огромную роль играет финансовый директор, поскольку финансирование и подбор персонала, как правило, имеют проектную основу.

Если за рулем находятся ключевые специалисты из разных направлений, то такую модель часто называют моделью функциональных команд (потому что каждый стейкхолдер заведует своей областью функций).

Если ведущую роль играет отдел продаж, то вы часто будете слышать термин «продукт, основанный на продажах», а если ведущую роль играет маркетинг, то, как правило, будут говорить о «продукте, основанном на маркетинге».

В этой книге мы просто называем модель, от которой вы уходите, предыдущей моделью, а ту, к которой вы стремитесь, — продуктовой операционной моделью или просто продуктовой моделью.

Во второй части этой книги, «Что такое трансформация», вы найдете подробное определение, что значит работать в продуктовой модели.

Также в нашей книге мы рассмотрим еще несколько важных терминов и понятий, связанных с продуктами, и дадим им определение по ходу повествования.

Если вы решили прочитать эту книгу, то, скорее всего, у вас уже есть свои причины приступить к трансформации.

Но если ставки настолько высоки, а усилия требуются настолько значительные, полезно четко сформулировать свою цель.

Как правило, мы видим, что в компаниях руководствуются одним или несколькими из трех основных факторов.

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

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

Прорывные инновации появляются в таких разных сферах, как финансовые услуги, здравоохранение, розничная торговля, автомобилестроение, логистика, реклама и даже освоение космоса.

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

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

В других компаниях впечатлены финансовыми результатами, которых достигают те, кто проявил способность на постоянной основе внедрять инновации в интересах своих клиентов.

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

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

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

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

В некоторых случаях один или несколько дополнительных факторов подталкивают руководителей компании к ощущению необходимости взять курс на преобразования:

В большинстве компаний, с которыми мы сотрудничаем по вопросам трансформации, уже пытались провести преобразования — как минимум раз, — прежде чем поняли, что потратили кучу времени и денег в никуда.

История, о которой пойдет речь ниже, до боли нам знакома. Мы убрали имена, но обстоятельства совершенно реальны. Посмотрите, похожа ли ваша ситуация на то, что мы описываем.

Итак, данная компания доминировала на рынке финансовых операций с момента своего основания в 2000 году. Она всегда была ориентирована на клиента и гордилась тем, что может предоставить именно то, что клиенту требуется. В итоге это привело к появлению длинной серии «специальных предложений» для удовлетворения предполагаемых потребностей различных индивидуальных клиентов.

Изначально эта нацеленность на необходимость сделать все для заключения сделки приносила реальный успех в делах. Быстрое удовлетворение потребностей клиентов стало фирменным стилем бренда как внутри компании, так и за ее пределами.

Но успех не длился вечно.

Несмотря на увеличение численности персонала и практику переработок, сроки создания новых возможностей заметно снизились. В то же время на рынке появилось несколько новых участников. Каждый из них развивался, быстро набирая обороты. В результате продажи нашей компании стали отставать, а доля рынка — падать.

В ответ на это организация перешла на агрессивную стратегию поглощений, быстро покупая и интегрируя дополнительные решения. Однако приобретения не только не вывели ее на новый уровень прибыльности, но и принесли немало проблем.

Совет директоров отреагировал решительными изменениями на самом верху.

Новый генеральный директор компании пришла с впечатляющим послужным списком в коммерческой сфере. Быстро пройдя путь по карьерной лестнице в международной консалтинговой компании и став самым молодым старшим партнером в ее истории, она[1] занимала различные руководящие должности в многочисленных финансовых организациях.

Как начинающий генеральный директор она понимала, что на кон поставлена вся ее карьера. Нельзя было допустить провала, поэтому она с энтузиазмом взялась за дело. Компания по-прежнему занимала значительную долю рынка, имела узнаваемую торговую марку и приносила прибыль. Но наш новый директор понимала, что необходимы кардинальные перемены, о чем и сообщила совету директоров. Ее напутствовали поручением возродить бренд.

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

За прошедшие годы компания превратилась в разветвленную организацию с офисами по всему миру, включая США, Индию и Европу. В результате возникли глубокие культурные различия.

После нескольких лет роста за счет поглощений компания, по сути, представляла собой конгломерат из нескольких подразделений с недостаточной интеграцией, большим техническим долгом (то есть накопившимися недоделками в программном обеспечении) и разочарованными клиентами.

Предыдущие связи позволили новому генеральному директору быстро прибегнуть к услугам консалтинговых служб, которые помогли оперативно выявить ряд устаревших практик, оставшихся от предыдущих этапов.

Предстояли значительные перемены. Они включали в себя новую централизованную организационную структуру, перевод технических подразделений в штат, более целенаправленную бизнес-миссию и создание нового продуктового подразделения, в которое вошли продуктовые менеджеры и дизайнеры. Для руководства преобразованиями был нанят новый директор по цифровым технологиям (CDO).

Параллельно решались многочисленные задачи, и не в последнюю очередь — привлечение технических кадров. Наем команды из 600 инженеров в сложных рыночных условиях предполагал высокие зарплаты, и за 12 месяцев компания вышла за рамки бюджета, но все еще не достигла требуемых показателей. Чтобы сократить расходы, вместо того чтобы нанимать квалифицированных менеджеров по продукту, компания решила переименовать команду бизнес-аналитиков. Обоснованием послужило то, что продукты сложны и требуют глубокого опыта работы в данной области.

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

За спиной руководителей новые инженеры возмущались уровнем технического долга. Каждая из поглощенных компаний продолжала работать на своей технической базе, унаследованной от прошлого юридического лица. Серьезных попыток интегрировать все это разношерстное программное обеспечение не предпринималось. Многие сотрудники ушли. Те, кто остался, едва могли поддерживать многочисленные системы в рабочем состоянии. Инженеры не видели другого выхода, кроме как немедленно все перенести на новую платформу.

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

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

ИТ-директор (CIO) рекомендовал перейти на новый, более формальный и структурированный процесс разработки, и команды прошли переобучение этому процессу в надежде повысить предсказуемость, хотя и с более длинными и менее частыми циклами выпуска.

Но при еще меньшем количестве релизов возникло новое поле битвы: подразделения стали бороться за то, кто сможет впихнуть большее количество функций (иногда называемых фичами), чтобы удовлетворить потребности клиентов и оправдать их затраты на обновление версий продукта. Кроме того, возникли значительные накладные расходы на новые процессы.

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

Тем временем затраты продолжали расти, а релизы появлялись все реже и реже. На этом безрадостном фоне конкуренты процветали. Первоначальные надежды совета директоров на успех были уже практически забыты.

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

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

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

Ни один из вариантов не подходил для решения накопившихся проблем. Давала о себе знать технологическая бесхозяйственность прошлых лет.

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

Трансформация компании сначала буксовала, а затем окончательно провалилась.

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

Пожалуйста, не поймите неправильно. Генеральному директору не обязательно иметь опыт работы с продуктовой моделью. И он не должен тратить на саму трансформацию много рабочего времени.

Но тем не менее эта роль критически важна.

Конечно, каждый генеральный директор скажет, что поддерживает преобразование своей компании всем сердцем.

Но большинство не понимает, что это значит, пока не дойдет до дела.

Проблема вот в чем: преобразования затрагивают компанию гораздо шире, чем просто превращение бывшего технологического отдела в новое направление.

Суть в том, что трансформация включает в себя и отдел продаж, и отдел маркетинга, и финансовую службу, и кадровую, и юридическую, и развитие бизнеса, и корпоративную этику, и производство.

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

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

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

Но часть сотрудников будет оказывать пассивное сопротивление, а кое-кто даже активное. Эти люди будут защищать свое текущее положение и обязанности, а кроме того, по понятным причинам привычные проблемы всегда пугают меньше, чем новые и неизвестные.

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

Как говорил легендарный бизнес-тренер Билл Кэмпбелл, «компанию волнует то, что волнует ее лидера».

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

Если вы генеральный директор, возможно, вы впервые слышите, что трансформация — это нечто, выходящее за рамки информационных технологий. В таком случае вам необходимо принять во внимание данный факт.

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

Нужно развить новые компетенции, привить персоналу новые навыки и принципы работы и, что самое важное, изменить корпоративную культуру.

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

Скажем прямо, генерального директора должны воспринимать как главного пропагандиста новой операционной модели.

Если ваш генеральный директор не хочет или не может поддерживать переход к продуктовой модели, то вы сэкономите время, деньги и нервы, реалистично оценив свой уровень готовности.

Но есть и хорошая новость: компания, которой удалось успешно перейти на продуктовую модель, улучшает рабочую ситуацию для всех, а не только для продуктового и инженерного направлений.

Сотрудники испытывают больше гордости за продукцию своей компании. Маркетологам есть что продвигать и позиционировать. Отдел продаж наращивает сделки. Все видят финансовый эффект. Крепнет моральный дух коллектива, снижается процент увольнений.

Все это говорит о том, что у генерального директора есть весомые причины активно поддерживать процесс трансформации и помогать ему.

Надеюсь, что к этому моменту вы уже начали понимать, что мы имеем в виду, когда говорим, что трансформация — это тяжело.

Наша книга призвана подготовить вас к тому, что ждет впереди.

Здесь вы не найдете волшебного рецепта или алгоритма по проведению трансформации. Многие люди будут стараться продать вам нечто подобное, но, к сожалению, мы никогда не видели, чтобы эти универсальные, без меры упрощенные подходы приносили результат.

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

Примеры трансформации призваны вселить в вас уверенность, что, несмотря на трудности, успех совершенно реален. Этими историями с вами поделится человек, возглавлявший продуктовое направление в каждой из компаний-примеров.

Примеры инноваций призваны вдохновить вас теми возможностями, которые перед вами откроются после перехода к продуктовой модели.

Кроме наглядных примеров, в книге есть следующие части.

Часть II «Что такое трансформация» мы начнем с исчерпывающего определения того, что на самом деле подразумевается под трансформацией в продуктовую операционную модель.

Следующие две части посвящены новым навыкам и способностям, которые вам нужно будет развивать, чтобы перейти к продуктовой модели.

В части III, согласно ее названию, мы сначала обсудим компетенции продуктовой модели, которые вам понадобятся для трансформации. Если вы думаете, что в вашей компании уже есть нужные специалисты, вы почти наверняка ошибаетесь и ваши начинания обречены на провал. Следите, чтобы вас не обманули те, кто просто приписал себе эти компетенции.

Далее, в части IV «Ключевые понятия продуктовой модели», мы представим основные понятия продуктовой модели, а также принципы, на которых она основана и которые лежат в ее фундаменте. Большинство компаний очень быстро понимают, что не имеют представления об этом, а это первый шаг к тому, чтобы оно появилось.

Компетенции новой продуктовой модели и ее понятия — та база, на которой строится вся трансформация.

В части VI «Продуктовая модель на практике» мы обсудим, как продуктовое направление конструктивно и эффективно сотрудничает с клиентами, отделом продаж, маркетинговым и финансовым отделами, стейкхолдерами и топ-менеджментом компании.

Далее, в части VIII «Техники трансформации», мы обсудим методы трансформации, которые помогут вашей организации пройти через изменения подобного масштаба. Перемены всегда трудны, но есть несколько ключевых техник и тактик, призванных облегчить трансформацию. Мы начнем с оценки текущего состояния организации, а затем опишем различные тактики. Мы также расскажем о важности постоянного евангелизма, то есть популяризации новой продуктовой модели в коллективе.

Возможно, вы уже поняли, что тут есть некая загвоздка. Разве компания, которая никогда не работала по-новому и в которой, скорее всего, нет руководителей с таким опытом, может перейти на новые рельсы?

Книги и различные виды тренингов могут вам помочь (если авторы этих книг и эти тренеры знают, о чем говорят), но, как правило, этого недостаточно. Мы рассмотрим, как перейти к новой модели, если ваши руководители никогда раньше не работали таким образом.

Далее, в части X «Работа с возражениями», мы обсудим различные проблемы, которые обычно возникают у каждого из ключевых стейкхолдеров: отдела продаж, маркетинга, отдела заботы о клиентах, финансовой и кадровой службы, ИТ-директора, руководителей проектов, гендиректора и совета директоров. А также рассмотрим вопросы, которые возникают непосредственно внутри продуктового направления.

Все это — обоснованные возражения и опасения, и люди обычно высказывают их из лучших побуждений просто потому, что видят проблему и еще не знают, как она будет решена. Мы рассмотрим каждое из этих возражений, а затем обсудим, как их преодолеть.

В части XI «Заключение» мы попытаемся сложить все элементы картины воедино и подвести итог важнейшим моментам, рассмотренным в книге, — включая то, какие закономерности объединяют примеры трансформации и в чем секрет ее успеха.

Существует много негативных образов, связанных с трансформацией.

Многие из нас были свидетелями неудачных преобразований, но мало кто был свидетелем настоящего успеха. Это делает уроки, извлеченные из успешных преобразований, необычайно ценными.

Один из вопросов, который мы слышим довольно часто: «Что такого наша компания сможет сделать после трансформации, чего мы не могли сделать раньше?»

Поскольку в продуктовой отрасли часто говорят о «работе на результат», мы считаем, что это правильный вопрос.

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

Итак, предположим, что руководители компании искренне считают, что им необходима трансформация. Что это значит на самом деле?

Многие из вас слышали такие слова: «Хотя переход на “гибкую методику” Agile необходим, но его недостаточно».

Или: «Суть трансформации заключается в переходе от функциональных команд к продуктовым командам с широкими полномочиями».

Или: «Цель — превратиться в компанию, ориентированную на продукт».

Хотя каждый из этих комментариев описывает определенный аспект трансформации, ни один из них не дает внятного, целостного представления о том, что на самом деле подразумевается под трансформацией.

Поэтому в этой книге мы используем другой подход.

Вместо поверхностных ярлыков (Agile, «команды, наделенные полномочиями», «продуктоориентированная компания») мы погрузимся на более глубокий уровень и выясним, что на самом деле меняется в компании.

В этой книге мы рассмотрим продуктовую модель как преобразование организации по трем различным параметрам:

Инвестиции в технологии — это создание ценности для ваших клиентов и вашей компании.

Есть несколько важных аспектов создания этой ценности, но в конечном счете основной специалист, от которого зависит создание продукта, — это ваш инженер.

Для многих компаний, работающих с технологиями, инженеры являются самой крупной статьей расходов.

В большинстве предыдущих моделей каждая технологическая операция обычно рассматривается как проект.

Каждый проект финансируется, укомплектовывается персоналом, планируется, выполняется и реализуется. Проект заканчивается после сдачи, и люди переходят к другим задачам.

Не забывайте, что все, что мы разрабатываем, представляет ценность на двух уровнях: во-первых, это продукт, который мы производим, а во-вторых, это опыт, который мы получаем. В проектной операционной модели теряется большинство того, чему мы научились.

Когда мы снова захотим поработать над этой областью, то потратим время и деньги на повторное изучение того, за что уже однажды заплатили. Или, что более вероятно, мы не будем восстанавливать эти знания и это дорого обойдется.

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

Можно сравнить это с ремонтом дома на продажу и для себя. В первом случае достаточно просто переклеить обои. Это быстро, дешево, а когда стены начнут шататься, это будет головная боль нового владельца.

Неслучайно именно так работает аутсорсинг, и мы часто говорим, что если вы хотите работать с таким подходом, то наймите консалтинговую компанию: она умеет это делать лучше вас.

Но в продуктовой модели такой способ работы слишком затратен в плане времени и денег, и, что еще важнее, он почти никогда не обеспечивает тех инноваций, что нужны вашим клиентам и вашей компании.

Вот почему трансформация начинается с изменения способа разработки. А это значит, что нужно переключить внимание с проектов на продукты.

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

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

В этой модели непрерывного развития вам нужны небольшие, бесплатные и надежные средства выпуска.

Компании, производящие успешные продукты, уже много лет назад поняли, что, хотя это может показаться нелогичным, статистика очень четко показывает: чем больше вы разрабатываете и чем больше изменений вносите, тем лучше для вас — и особенно для ваших клиентов. Словом, выпускать обновления нужно как можно чаще[5].

Если вы искренне заботитесь о том, чтобы обеспечить надежный сервис для своих клиентов, гораздо проще обеспечить небольшое количество изменений и не рисковать появлением неожиданных проблем, чем сгруппировать большое количество изменений в один релиз и пытаться выпустить все сразу (в индустрии это называется «ударный» релиз).

Подчеркнем еще раз: если каждая из ваших продуктовых команд не выпускает обновление хотя бы раз в две недели, то вы не сможете заботиться о своих клиентах на необходимом уровне[6].

Кроме того, при внедрении новых возможностей необходимо следить, чтобы они функционировали — так вы будете знать, что продукт работает корректно, и понимать, как ваши клиенты используют его на самом деле. Вам также необходимо постоянно держать руку на пульсе, чтобы обнаруживать любые проблемы раньше клиентов. Для многих важных изменений необходимо продемонстрировать, что новая функция приносит необходимую пользу, прежде чем широко внедрять ее (стандартный способ это сделать — провести A/B-тестирование).

Вы можете возразить, что на ваш тип продукта это не распространяется или что ваши клиенты сами просят обновлять продукт пореже, но в главе 18 «Разработка продукта» мы обсудим причины, по которым постоянные обновления нужны и вам, и вашим пользователям, а также обозначим принципы, на которых строится этот способ работы и механизмы этой работы.

Разработка, тестирование и внедрение — важный процесс вне зависимости от того, какой продукт вы решили создать, однако многие компании идут по пути простого наращивания функций.

Они превратились в настоящий конвейер по производству функций, но при этом не видно ни их ценности для клиентов, ни благотворного влияния на бизнес.

На самом деле в большинстве современных компаний доля по-настоящему прибыльных функций и проектов в «дорожных картах» удручающе мала. Большинство отраслевых аналитиков оценивают их в диапазоне от 10 до 30%.

Если вы сравниваете список возможностей, которые нужны вашей компании, с тем эффектом, который они приносят, и не чувствуете ожидаемой отдачи, то пришла пора менять алгоритм решения проблем.

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

Руководство и стейкхолдеры видят каждый свои специфические рабочие потребности и составляют список функций и проектов, которые, по их мнению, помогут выполнить обязательства перед бизнесом. Они передают эти приоритеты продуктовым командам, которые затем должны предоставить «дорожную карту» продукта с указанием сроков и результатов.

Почему же лишь немногие из этих функций приносят желаемую прибыль?

Дело в том, что каждая из этих функций — это потенциальное решение какой-либо проблемы. Это может быть проблема клиентов — например, они не могут понять, как эффективно применять ваш продукт. Или это может быть проблема компании — например, поддержка продукта обходится вам слишком дорого.

В рамках модели функциональной команды каждая функция из «дорожной карты» продумывается дизайнером этой команды, а затем создается инженерами этой команды. Но за то, принесет ли эта функция пользу вашим клиентам или компании, отвечает тот, кто попросил включить ее в «дорожную карту».

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

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

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

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

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

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

Давайте сравним вышеописанную модель с тем, как работает продуктовая команда, наделенная полномочиями. В этом случае вместо того, чтобы выдавать ей «дорожную карту» функций и проектов, подлежащих разработке, продуктовая команда получает список проблем, которые нужно решить, и результатов, которых нужно достичь.

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

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

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

Почему же продуктовая команда, наделенная полномочиями, превосходит функциональную команду, то есть ту, что разрабатывает отдельные фичи?

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

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

Но в продуктовой команде инженеры заняты не только разработкой, а дизайнеры — не только внешним видом продукта. Они также отвечают за помощь в поиске правильного решения. Именно это и подразумевается под термином «продуктовые команды, наделенные полномочиями».

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

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

Мы делаем такой упор на роли разработчиков с расширенными возможностями, потому что компаниям, которые еще не прошли трансформацию, обычно требуется самый большой мировоззренческий сдвиг именно в отношении к инженерам. Доказательством тому служит степень распространенности аутсорсинга именно в направлении разработки программного обеспечения.

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

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

Если продуктовая команда с расширенными полномочиями выпускает функцию (фичу), но не видит эффекта, то она циклически дорабатывает эту функцию, либо меняет свой подход, пока не добьется своего.

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

Команда могла бы просто воплощать все, что приходит в голову, и смотреть, что из этого будет работать, но это займет гораздо больше времени и приведет к тому, что ваши клиенты столкнутся с множеством плохих решений. Вместо этого у продуктовой команды есть целый набор инструментов и методик для быстрого тестирования идей и подходов.

В основном команда создает прототипы, которые бывают разных форм, но все они создаются очень быстро и недорого. Каждый прототип предназначен для проверки тех или иных рисков и предположений.

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

Если в среднем для достижения необходимых бизнес-результатов (прибыльности) типичной функции требуется от трех до пяти циклов доработки, а на создание каждой из них уходит несколько месяцев, то можно прождать один-два года, прежде чем функция принесет желаемый доход. И это исключительно в том редком случае, если ключевые специалисты направлений готовы продолжать вносить эти необходимые итерации в «дорожную карту» продукта.

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

Если вы когда-нибудь задавались вопросом, как небольшим продуктовым командам с расширенными полномочиями удается стабильно опережать гораздо более крупные компании, тратящие в разы больше средств на свои функциональные команды, то это и есть ответ.

О том, как развить навыки, необходимые для изменения алгоритма решения проблем, мы расскажем в главе 17 «Исследование продукта».

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

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

Разница невелика, однако она коренным образом меняет динамику развития вашей организации.

Но будьте внимательны.

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

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

Так и есть — брать на себя ответственность за решение проблем клиентов гораздо сложнее, чем просто создавать функции, на которые вам указали. Нужно убедиться, что в ваших продуктовых командах работают люди нужного уровня и что они обеспечены необходимым обучением и снабжены контекстом для достижения успеха. Об этом будет часть III «Компетенции продуктовой модели».

Сильные, межфункциональные, наделенные полномочиями продуктовые команды, состоящие из менеджеров по продукту, дизайнеров и инженеров, которые работают вместе над решением проблем клиентов так, чтобы это нравилось им и при этом приносило прибыль компании, — вот основная концепция продуктовой модели. Подробнее о ней можно прочитать в главе 15 «Продуктовые команды».

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

Нет ничего сложного в том, чтобы взять существующие «дорожные карты» продуктов и для каждой функции или проекта определить, в чем заключается основная проблема, которую нужно решить, и каков рациональный способ измерения успеха. Это простой и понятный переход от «дорожных карт» функций к «дорожным картам» результатов. (О «дорожной карте», основанной на результатах, см. врезку в главе 8.)

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

Но правда ли это самые важные проблемы, с которыми имеют дело ваши клиенты и ваша компания?

Каждая организация имеет определенный набор возможностей и сталкивается с определенным набором угроз.

Насколько тщательно она выбирает наилучшие возможности для реализации и насколько четко определяет угрозы, которые следует воспринимать всерьез?

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

Во многих таких компаниях роль арбитра выполняет финансовая служба, которая принимает решения на основе представленных бизнес-кейсов.

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

Однако в компаниях, где действительно заботятся об ответственном определении приоритетов, впоследствии сравнивают достигнутые результаты с данными обещаниями. Им известно, что ни один из этих подходов не обеспечивает стабильно правильные решения — прежде всего потому, что у них нет надежных данных. В книге «Вдохновленные» подробно рассказывается о том, почему так происходит и что вместо этого делают хорошие продуктовые команды.

Словом, планирование продукта — это принятие решения о том, с какими проблемами вам нужно разобраться. Изменение способа определения приоритетов — это третий аспект перехода к продуктовой модели.

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

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

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

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

Думаю, вы уже поняли, что нужен иной подход.

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

Вы увидите, как эта динамика прослеживается в каждой из трех подробных историй трансформации в этой книге — на практических примерах Trainline (часть V), Datasite (часть VII) и Adobe (часть IX), однако давайте начнем с теории.

Многие компании тратят время на то, чтобы реагировать — на новые возможности продаж, на предложения конкурентов, на запросы клиентов, на ценовое давление и т. д. Однако сильные продуктовые компании не руководствуются этими факторами, а лишь принимают их во внимание.

Этими компаниями движет видение (образ) продукта, который улучшит жизнь их клиентов.

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

Более того, отчетливое видение продукта будет вдохновлять организацию в долгосрочной перспективе (в большинстве случаев от трех до десяти лет).

Важно отметить, что образ продукта прежде всего — это про вашего пользователя. Как конкретно продукт сделает жизнь ваших клиентов лучше?

Здесь речь идет не о том, как вы будете наращивать прибыль, каковы ваши квартальные приоритеты и как вы будете структурировать продуктовые команды. Все эти темы важны, и мы обсудим их далее, но цель видения продукта — описать будущее, которое вы стремитесь создать.

У вас могут быть десятки и даже сотни продуктовых команд, но именно образ продукта объединяет их, чтобы совместными усилиями воплотить этот образ в жизнь[7].

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

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

Как сказал легендарный гендиректор Netscape Джим Барксдейл, главное, чтобы главное оставалось главным.

Или, если вам больше нравится русская пословица: «За двумя зайцами погонишься — ни одного не поймаешь».

Определившись с ключевыми направлениями, выберите те инсайты, на которые будете делать ставку.

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

Такой тип продуктовой стратегии, основанный на глубоком понимании и анализе взаимосвязей, обычно требует от компании разработки новых мускулов, зато в награду за сильную продуктовую стратегию она получит максимальную отдачу от инвестиций в технологии. Хорошая продуктовая стратегия дает эффект синергии.

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

По сути дела, в большинстве компаний, работающих по модели функциональных команд, продуктовая стратегия буквально сводится к тому, чтобы внедрить побольше фич для всех стейкхолдеров. Такой подход вообще не назовешь стратегией продукта.

В большинстве компаний, где стремятся к трансформации, понимают, что им необходимо вывести свои продуктовые команды на новый уровень. Нужно нанять более опытных разработчиков. Талантливых дизайнеров продукта. Компетентных продуктовых менеджеров.

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

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

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

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

О том, как развить необходимые навыки в отборе главных проблем, мы рассказываем в главе 16 «Продуктовая стратегия».

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

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

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

Задумайтесь на минуту о том, что это значит. По сути, мы перекладываем принятие решений и ответственность за поиск наилучшего решения проблемы на соответствующую продуктовую команду, а затем возлагаем на нее ответственность за результаты.

Это обусловливает потребность в совершенно новых продуктовых компетенциях.

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

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

Не стоит недооценивать сложность формирования этих новых компетенций. На них зиждется все, о чем мы пишем в этой книге.

Скажем прямо, если вы не готовы вложить много усилий в эти новые компетенции, ваши надежды на преобразования, скорее всего, останутся бесплодны.

Стоит признать, что описываемые новые навыки могут пугать тех сотрудников, которые строили свою карьеру на основе других компетенций.

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

Важно также подчеркнуть, что многих из ваших сотрудников вполне можно переучить и развить в сильных специалистов, обладающих необходимыми компетенциями. Но не стоит ожидать, что это получится сделать со всеми.

Все упирается в желание ваших сотрудников профессионально развиваться, а также в наличие продуктовых лидеров или тренеров, которые могут помочь им освоить эти новые компетенции.

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

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

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

Кроме того, мы хотим, чтобы вы уже сейчас задумались об изменении своих должностных инструкций и карьерных траекторий, чтобы отразить и закрепить эти новые компетенции в своей компании.

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

Мы хотим дать вам инструменты, позволяющие эффективно подходить к оценке компетентности персонала.

Типичная межфункциональная продуктовая команда требует трех специфических и очень разных наборов навыков.

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

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

Таким образом, чтобы найти эффективное решение, команда должна учесть четыре различных типа рисков[8].

Стоит сразу предупредить, что это самая сложная новая компетенция, которую всегда непросто развить.

Скорее всего, в вашей компании уже есть люди с должностью «продакт-менеджер». Но даже если это так, то вполне вероятно, что эти должности были просто переименованы из других, таких как «управляющий продуктом», «бизнес-аналитик» или «руководитель портфеля проектов».

Иными словами, подводные камни тут в том, что в предыдущей операционной модели вашей компании, скорее всего, существовала роль с таким же названием, «менеджер по продукту», но она включала в себя совершенно другую работу с совершенно другими навыками и обязанностями.

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

Как уже говорилось ранее, в предыдущих моделях стейкхолдеры косвенно отвечают (если вообще отвечают) за ценность и жизнеспособность разрабатываемых технологических решений. Но в продуктовой модели ответственность за обеспечение ценности и жизнеспособности продукта открыто ложится на продакт-менеджера.

Работа с риском ценности требует глубокого понимания ваших пользователей и клиентов, а с риском жизнеспособности — глубокого понимания вашего бизнеса.

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

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

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

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

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

Имейте в виду, что, как правило, инженеры-разработчики и дизайнер продукта не обладают этими знаниями (а если да, то их встречают аплодисментами), поэтому, чтобы продуктовая команда могла делать правильный выбор в процессе поиска эффективного решения, им необходимо, чтобы эти знания откуда-то поступали.

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

Чтобы осознать, какой уровень мастерства требуется для этой компетенции, поделимся с вами двумя откровенными наблюдениями:

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

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

С точки зрения продуктовой операционной модели в дизайнере нас интересуют два момента: как он выстраивает взаимодействие с продуктом и как участвует в его исследовании.

Первая проблема заключается в том, что в прежних моделях дизайнеры обычно обладают гораздо меньшим набором навыков. Обычно это графические или визуальные дизайнеры, и, хотя эти компетенции, безусловно, полезны, но, как сказал Стив Джобс, «дизайн — это не только внешний вид и ощущения от продукта. Дизайн — это то, как это работает».

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

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

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

Дизайн взаимодействия — это понимание того, как люди (пользователи и клиенты) контактируют с технологиями.

Вторая проблема заключается в том, что ваши нынешние дизайнеры, как правило, привлекаются в финале разработки продукта, чтобы «сделать все красиво» и как минимум придать продукту фирменный стиль, чтобы было видно, что все ваши продукты производятся одной и той же компанией.

В отличие от этого привычного подхода, вам понадобятся продуктовые дизайнеры, которые способны поучаствовать в поиске эффективного решения проблемы клиента.

Квалифицированные дизайнеры по продукту обучены напрямую взаимодействовать с пользователями и клиентами, чтобы проникнуть в их мысли — понять, что они думают о поставленной проблеме и о ваших потенциальных решениях. Они стремятся создать целостный опыт, который будет узнаваем и интуитивно понятен вашим пользователям и клиентам.

Более того, опытные дизайнеры продуктов не только продумывают опыт взаимодействия, но и умеют осознанно модифицировать его в нужную сторону.

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

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

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

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

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

Говоря об инженерах-разработчиках, мы должны иметь в виду их важное отличие от продуктовых менеджеров и дизайнеров.

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

Однако, как правило, разработчиков в каждой продуктовой команде несколько.

Количество технических специалистов и их необходимые навыки варьируются в разных типах продуктовых команд и зависят от применяемых технологий и объема ответственности.

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

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

Здесь нам нужно отдельно обсудить роль самых старших инженеров, которых мы называем техлидами, или ключевыми техническими специалистами[10]. Оговоримся, что это, как правило, не управленцы, а индивидуальные разработчики.

Если же говорить о разнице между инженерами в продуктовой модели и инженерами в предшествующих моделях, то здесь есть два аспекта.

Первый связан со сложностью решений, которые создают продуктовые компании, по сравнению с традиционными ИТ-компаниями.

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

Второй связан с целями: вам нужны инженеры лишь для того, чтобы реализовать решение, придуманное продуктовым менеджером и дизайнером, либо от них требуется помощь в поиске этого решения (а затем уже в реализации).

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

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

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

Есть расхожее, но ошибочное утверждение, мол, менеджер проекта отвечает на вопросы «что» и «почему», а инженер — на вопрос «как». Но это в корне противоречит сути продуктовых команд с широкими полномочиями и игнорирует источник реальных инноваций.

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

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

Справедливости ради часть технических специалистов, особенно младшего уровня, могут сосредоточиться только на программировании.

На успешный продукт можно рассчитывать, если в каждой из ваших продуктовых команд как минимум один техлид будет готов сотрудничать с продакт-менеджером и дизайнером, чтобы сообща искать эффективное решение поставленной проблемы.

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

Пусть это будет официально включено в должностную инструкцию ключевых технических специалистов (техлидов).

На практике это займет у сотрудника не так много времени, но тем не менее данная часть работы станет ежедневной (обычно менее часа в день)[11].

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

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

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

Что это значит на практике?

Как сказал легендарный топ-менеджер Энди Гроув, «что мешает хорошей работе? Есть только два ответа. Первый — люди не знают, как выполнять работу хорошо. Второй — они знают, но у них нет мотивации».

Давайте разберем оба варианта по порядку.

Сначала обсудим управленческие обязанности, которые в первую очередь включают в себя подбор персонала и наставничество.

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

Almosafer (входящая в Seera Group) — туристическая компания, базирующаяся в Саудовской Аравии и обслуживающая весь Ближневосточный регион. Компания специализируется на удовлетворении потребностей локального и регионального рынка, а также на туристических и религиозных визитах в регион со всего мира.

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

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

Эти глобальные поставщики туристических услуг предлагали способы экономии на масштабе и продвинутые технологические решения, однако мало учитывали местные потребности, обычаи и особенности поведения потребителей.

Таким образом, во многих регионах мира открылось окно возможностей для появления местного игрока, который бы, с одной стороны, владел локальной спецификой, а с другой, обладал современными навыками и технологиями для работы в этих рамках.

К 2018 году руководитель продукта Ронни Варгезе и руководитель по технологиям Каис Амори, а также другие топ-менеджеры Almosafer решили: для того чтобы действительно улучшить жизнь пользователей в своем регионе, им необходимо создать цифровую команду, способную находить и предлагать решения, превосходящие те, что предлагают мировые туристические сервисы. Поэтому они приступили к трансформации в сторону продуктовой модели.

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

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

В течение первого года компания сосредоточилась на двух основных направлениях: значительном улучшении качества обслуживания клиентов и создании технологической инфраструктуры и архитектуры, которые не только сократят операционные расходы, но и позволят компании внедрять инновации и обслуживать своих клиентов в будущем.

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

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

Группа была на пути к созданию одной из легендарных историй успеха.

А затем международные границы закрылись.

Как и во всем мире, пандемия COVID-19 в значительной степени поставила путешествия на стоп. Саудовская Аравия пострадала особенно сильно, поскольку большую часть туристов в этой стране составляли иностранцы.

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

Команды в составе компании выявили множество возможностей благодаря постоянному взаимодействию со своими клиентами — потребителями и предприятиями. Одну из таких возможностей они заметили ранее, но лишь во время пандемии она превратилась из интересного варианта в насущную потребность. Это был поиск способов безопасной организации досуга в семейном и дружеском кругу.

В Саудовской Аравии издавна существует культурная традиция под названием «истираха», что переводится как «место отдыха», но в целом означает большой двор или другую площадку под открытым небом, где можно приготовить еду на гриле, посидеть в прохладной тени и подышать свежим воздухом. Семьи и друзья собирались на «истираха» по особому случаю или чтобы просто побыть вместе.

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

Было и еще одно важное отличие: «истираха» бронируется не на ночь, как стандартные гостиницы, а с обеда до вечера того же дня.

Команда знала, что это будет особенно рискованный тип продукта. Подавляющее большинство продуктов представляют собой новые решения существующих проблем, а это было новое решение новой проблемы, необходимости поиска и бронирования «истираха».

Здесь требовалось не только эффективное решение, но и развитие рынка — по сути, весь регион должен был узнать об этом новом типе услуг.

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

Команда работала с тренером по продукту Хоуп Гурион (о ней будет рассказано далее в этой книге), чтобы быстро прийти к эффективному решению.

Еще одна проблема была в том, что продуктовой команде предстояло перестроить свою работу на удаленный формат. Поскольку они приобрели опыт и укрепили доверие в команде, то смогли быстро и эффективно перейти как к дистанционному взаимодействию сотрудников, так и к удаленным исследованиям с клиентами. То есть восстановили работу обе фазы создания продукта — и постановка проблемы, и исследование вариантов ее решения.

В этом новом продукте было много неизвестных компонентов. Никто даже не знал, сколько существует «истираха», не говоря уже о том, сколько владельцев готовы выставить их на продажу и сколько людей их забронируют.

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

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

Сегодня Almosafer занимает поистине удивительную долю рынка — более 70% в своем регионе.

Таких выдающихся результатов нельзя достичь только одной отдельной способностью или предложением. Это результат постоянного использования талантов и технологий ради истинной заботы о клиентах.

Almosafer — одна из подлинных историй успеха на Ближнем Востоке, и компания продолжает расширяться, охватывая все новые страны региона. У компании есть все возможности для дальнейшего роста и успеха.

Переход к продуктовой модели — это не только новые компетенции, но и несколько важнейших понятий: по сути, это новые виды деятельности, которые помогут вам постоянно создавать эффективные продукты.

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

Эта часть призвана объяснить ключевые понятия продуктовой модели.

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

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

Более того, обычно существует несколько возможных путей достижения одних и тех же целей.

Тем не менее для основных понятий продуктовой модели необходимо дать корректные определения, чтобы понимать, о чем идет речь.

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

Каждая из описанных нами концепций основана на наборе первичных принципов продуктовой модели.

Эти принципы представляют собой общие убеждения, которыми руководствуются во всех известных нам сильных продуктовых компаниях, вне зависимости от того, изначально там была продуктовая модель или произошла трансформация в нее. Неважно, маленькие это компании или большие. Неважно, обслуживают они индивидуальных потребителей или корпоративных. Неважно, создают они программное обеспечение или девайсы.

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

В основе продуктовой модели лежит межфункциональная продуктовая команда, наделенная широкими полномочиями. Большая часть содержания этой книги направлена на то, чтобы помочь этим продуктовым командам качественно выполнять свою работу.

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

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

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

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

Как мы уже говорили, в продуктовой модели недостаточно просто упорно работать, генерируя обилие фич. Вам нужно решать проблемы своих клиентов, причем так, чтобы это работало на ваш бизнес. Это означает достижение реальных результатов.

Как только вы убедитесь, что нашли решение, которое стоит воплощения, вам нужно разработать и внедрить его для нужд пользователей. Чтобы этот процесс шел последовательно, быстро и надежно, требуется набор навыков, называемых разработкой продукта.

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

Наконец, еще один набор первичных принципов продуктовой модели направлен на создание корпоративной культуры последовательных продуктовых инноваций.

И последнее, но очень важное замечание. Для создания новой культуры продукта требуется много работы, а вот разрушить ее легко. Вам нужно постоянно напоминать себе о важности принципов продуктовой модели. В компании всегда есть силы, которые стремятся сбить вас с курса. Защита от них начинается с того, что вы все время держите эти принципы в голове.

Фундаментальное понятие в продуктовой модели — это концепция расширенной, межфункциональной продуктовой команды. Именно здесь рождаются эффективные инновационные продукты, а большая часть продуктовой модели так или иначе направлена на то, чтобы формировать и подпитывать такие продуктовые команды.

Во-первых, давайте разберемся, что такое широкие полномочия.

Продуктовая команда, наделенная полномочиями, существует для того, чтобы решать проблемы в русле, которое приносит пользу вашим клиентам и при этом работает на ваш бизнес.

Что делает команду более сильной, так это сама постановка задач — будь то проблемы клиентов или проблемы компании. От команды требуется найти наилучшее решение сформулированной проблемы.

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

Во-вторых, давайте выясним, что значит межфункциональность.

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

Очень важно, чтобы команда, наделенная полномочиями, была по-настоящему межфункциональной, потому что неразумно ожидать от команды решения проблем и ответственности за результаты, если она не обладает необходимым набором навыков.

Обычно это означает наличие менеджера по продукту, продуктового дизайнера и группу инженеров-разработчиков.

Мы уже упоминали об этом ранее, но это настолько важно, что стоит повторить:

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

Если продуктовые команды занимаются решением сложных проблем, то продуктовая стратегия — это то, как вы определяете, какие именно проблемы являются приоритетными.

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

Вопрос в том, как выбрать лучшие возможности и как определить наиболее серьезные угрозы?

Как говорил Стив Джобс, «люди думают, что сосредоточиться — значит сказать “да” тому, на чем нужно сосредоточиться. Но это ошибка. На самом деле, нужно сказать “нет” сотне других хороших идей. Вы должны тщательно выбирать. Я бы сказал, что одинаково горжусь и тем, что я сделал, и тем, чего мы не сделали. Новаторство — это отказ от тысячи вариантов».

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

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

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

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

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

Если для того, чтобы сосредоточиться на главном, требуется настоящая дисциплина, то для того, чтобы выявить ключевые инсайты (значимые выводы из анализа данных), требуется настоящее мастерство. На них зиждется вся продуктовая стратегия.

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

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

Первое называется исследованием продукта, а второе — его разработкой.

Первый принцип продуктового исследования — стремиться решить проблему с минимальными затратами времени и сил. Именно поэтому исследование продукта — это ключ к ускорению окупаемости.

Разумеется, продуктовая команда может просто предположить некое решение, описать его инженерам, а затем поручить им создать и предоставить это решение.

По сути, именно так десятилетиями делали многие компании в ИТ-модели, основанной на отдельных функциях.

Но сегодня мы располагаем данными, собранными на протяжении тех же десятилетий, которые однозначно свидетельствуют: большинство решений, созданных таким образом (как правило, от 70 до 90%), в итоге не приносят необходимых бизнес-результатов.

Это расточительство не только с точки зрения прямых затрат (в особенности потому, что наибольшие расходы обычно приходятся на технических специалистов), но и с точки зрения упущенной выгоды.

Время от времени команде выпадает еще один шанс, но даже со второй попытки решение, реализованное таким образом, редко бывает успешным.

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

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

При создании продуктов всегда есть следующие риски:

Большинство компаний, переходящих к продуктовой модели, должны не только ввести в штат компетенцию ключевого технического специалиста (техлида), упомянутую ранее, но и вкладываться в свою квалификацию и инфраструктуру в том, что касается разработки, тестирования и внедрения программного обеспечения, на которое рассчитывают клиенты.

В успешных продуктовых компаниях часто можно услышать фразу: «Наше главное качество — надежность».

Спору нет, в современных продуктах и услугах, основанных на технологиях, поломка продукта может иметь немедленные и пагубные последствия для ваших пользователей и клиентов, для ваших доходов, для репутации вашего бренда и для ваших коллег (особенно сотрудников отдела продаж и отдела заботы о клиентах).

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

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

В таких случаях вам нужна возможность немедленно откатить последнее изменение, чтобы стабилизировать систему, быстро диагностировать проблему, создать новое решение, протестировать его, чтобы убедиться, что оно решает проблему, и нечаянно не вызвать другие проблемы (то есть провести регрессионное тестирование), а затем безопасно внедрить это решение.

Клиенты, как правило, с пониманием относятся к тому, что время от времени случаются сбои, и для них важнее то, как быстро и компетентно вы реагируете на нештатные ситуации.

Сегодня для большинства пользователей просто неприемлемо ждать неделями или месяцами. Успешные продуктовые компании должны уметь быстро и компетентно реагировать на насущные потребности клиентов и рынка.

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

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

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

Это означает, что как минимум каждая продуктовая команда выпускает свои новые разработки не реже чем раз в две недели. Для крупных продуктовых компаний это означает выпуск релизов несколько раз в день (так называемая непрерывная интеграция, непрерывное внедрение — CI/CD)[14].

Если вы не замечаете, что это происходит с вашими любимыми продуктами, то причина именно в том, что они выпускают фактически непрерывный поток очень маленьких релизов.

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

Итак, первая задача — когда вы создаете новую функцию, вам нужно проверить, что она будет работать в соответствии с ожиданиями. Никаких подводных камней тут нет, за исключением бесконечных повторений этой проверки. И поскольку в ближайшие месяцы и годы вам, скорее всего, предстоят тысячи циклов тестирования, логичное решение — вложить средства в его автоматизацию.

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

Основной метод, который используют продуктовые команды, чтобы убедиться в работоспособности новых функций без риска регрессий — это внедрение серии очень небольших изменений.

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

К тому же, если проблема возникает на фоне небольших и частых выпусков, ее гораздо проще выявить (ведь внесенные изменения можно по пальцам пересчитать).

Поэтому, если вы всерьез настроены заботиться о своих клиентах, придется инвестировать в свою способность выпускать очень частые и небольшие релизы.

На первый взгляд это может противоречить здравому смыслу, но если вы по-прежнему считаете, что высокая планка качества требует выпускать продукт медленно и редко, то стоит изучить теорию и опыт успешных продуктовых компаний, в которых частые и небольшие релизы обеспечивают большую пропускную способность (скорость), а также более высокое качество[15].

К сожалению, многие игроки рынка еще не достигли способности делать такие небольшие и частые релизы.

Вместо этого они готовят сотни и тысячи изменений, а затем — раз в месяц, раз в квартал или даже раз в год — кропотливо внедряют и пытаются интегрировать этот ворох разношерстных функций. Затем они пытаются проверить, работают ли все эти новые возможности так, как ожидалось, а дальше приступают к выявлению и устранению неизбежно возникающих проблем (регрессий).

Надеемся, вы начинаете понимать, что именно поэтому крупные («ударные») релизы печально известны задержками в несколько недель или даже месяцев, когда их приходится возвращать в стабильное, пригодное для выпуска состояние.

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

Более того, даже если новый релиз действительно работает так, как должен (а в этом большие сомнения), клиенты вынуждены переваривать сотни или даже тысячи изменений в продукте, которые разом обрушиваются на их головы. Это, скорее всего, потребует переобучения, переаттестации, новой интеграции и других значительных перерывов в работе — все ради того, чтобы справиться с изменениями, которые компания им навязала.

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

Вместо того чтобы игнорировать или отбрасывать обоснованные опасения клиентов, вы должны разработать, протестировать и выпустить свой продукт так, чтобы людям не пришлось мучиться с последствиями обновлений. С одной стороны, у вас есть все основания для скорейшего внедрения изменений в программное обеспечение, но с другой стороны, с помощью специальных инструментов вы можете контролировать, когда именно клиенты увидят и получат доступ к этим новым возможностям. Об этом мы расскажем на примере следующих принципов.

Поскольку в продуктовой модели вы берете на себя обязательства по решению проблем и несете ответственность за достижение результатов, очень важно понимать, как ваши продукты используются на самом деле (либо не используются вовсе).

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

При отсутствии всех этих данных ваш продукт развивается вслепую.

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

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

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

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

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

Благодаря тщательному мониторингу вы сможете быстро обнаруживать проблемы, причем нередко еще до того, как с ними столкнутся ваши клиенты.

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

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

Итак, у вас есть возможность внедрять небольшие, частые релизы, которые оснащены измерительными инструментами для получения необходимых телеметрических данных, и вы следите за дальнейшей судьбой этих обновлений.

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

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

Но даже если все работает стабильно, вы еще не знаете, как клиенты будут применять новую функцию в повседневной жизни.

Здесь возможны три варианта развития событий:

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

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

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

Это продуктовые команды, умеющие проводить исследование продукта, заранее оценивая риски, экспериментируя, создавая прототипы и проводя быстрое тестирование с пользователями и клиентами, чтобы определять, какие решения действительно стоит разрабатывать.

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

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

Многие компании, которые хотят трансформироваться, в ранний период развития неплохо справлялись с инновациями, но потом каким-то образом утратили эту способность.

К сожалению, такое случается сплошь и рядом, и успешные продуктовые компании всегда держат в уме такую перспективу.

Как предупреждает Джефф Безос, «верный процесс позволяет вам обслуживать клиентов. Но если вы невнимательны, он рискует превратиться в священную корову. В крупной организации это происходит очень легко. Помните, что процесс — это не главное. Всегда задавайте вопрос: мы владеем процессом или процесс владеет нами?»

Или, как отмечает Стив Джобс, «великие продукты создает не процесс, а содержание. Система заключается в том, что система отсутствует. Это не значит, что у нас нет процесса. Но он не главное».

А вот что говорит Рид Хастингс: «[Причина успеха Netflix в том, что у этой компании есть] культура, в которой люди важнее процесса, инновации важнее эффективности, а контроля совсем немного».

Или, как предупреждает Стив Бланк, «процесс хорош в идеальном мире, где известны и проблема, и решение. Процесс гарантирует, что вы сможете разрабатывать решения, которые масштабируются без нарушения работы других частей организации. Процессы снижают риск для организации в целом, но каждый слой процессов снижает гибкость и оперативность и, что самое важное, замедляет реакцию на новые возможности и угрозы».

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

По сути, вы можете пытаться управлять своим продуктовым направлением либо с помощью процессов, либо с помощью людей.

Если сотрудник совершает ошибку, вы можете добавить процесс, который призван предотвратить повторение этой ошибки, либо провести инструктаж, чтобы человек понял, как ему справиться с подобной ситуацией в будущем.

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

Коучинг включает в себя обучение навыкам и принципам, а также обмен стратегическим контекстом — более широкой картиной видения продукта и его стратегии.

Переход от командно-административной к продуктовой модели — это не только изменение компетенций и понятий, но и фундаментальное изменение культуры.

Для многих топ-менеджеров, особенно тех, кто строил свою карьеру на модели управления «сверху вниз», это большой скачок в развитии. Новая модель основана на доверии, а не на контроле.

Полезно осознать, что именно это является ключевым изменением.

Данный подход проявляется во многих аспектах: начиная с отказа от привычных списков функций, которые стейкхолдеры выдают продуктовым командам, и заканчивая расширением полномочий продуктовых команд, перед которыми отныне ставятся ответственные задачи для самостоятельного поиска лучших решений.

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

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

Не то чтобы они намеренно отказывались от цели инноваций, но, как говорит бизнес-тренер Хенрик Книберг, «100% предсказуемости = 0% инноваций».

В компаниях, ориентированных на предсказуемость, скажут вам, что сами стейкхолдеры и должны заботиться о ценности запрашиваемых ими функций. Но сильные продуктовые компании знают, что дело не в умных запросах, а в природе продукта, основанного на технологиях, — специалисты других направлений и клиенты просто не знают, что технически возможно реализовать в данный момент. Лишь разработчикам известно, что происходит на передовых технологических рубежах.

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

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

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

Хотя мы ни в коем случае не прославляем ошибки и провалы, основное внимание должно быть направлено на работу с рисками и быстрое обучение. Когда вы проводите эксперимент в рамках исследования продукта, нет такого понятия, как успех или провал. Есть только вопрос: «Чему мы научились?»

Ваша цель — узнать, что в процессе поиска продукта работает, а что нет, при этом затраты и время значительно сокращаются, а риск снижается. Таким образом, когда вы начнете тратить время и средства на разработку продукта, у вас будут доказательства и уверенность в том, что продукт не окажется провальным.

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

Примечание Марти: «Компания CarMax уже ощутила преимущества перехода на продуктовую модель, когда пандемия подвергла организацию настоящему испытанию. Это потребовало от нее задействовать все свои новые мускулы — в продуктовой стратегии, в исследовании продукта и в его разработке. Иногда требуется кризис, чтобы понять, на что действительно способна ваша компания».

Компания CarMax, основанная в 1993 году в Ричмонде, штат Вирджиния, является крупнейшим розничным продавцом подержанных автомобилей в США. За последние 30 лет компания построила прочный бизнес, добившись отношений доверия и честности между продавцами и покупателями автомобилей с пробегом.

Изначально CarMax была создана как дочернее подразделение розничной сети по продаже электроники Circuit City и быстро стала лидером в области продаж подержанных машин. Со временем топ-менеджмент заметил, что ожидания потребителей изменились, особенно в части желания совершать покупки через интернет, а кроме того, появились конкуренты, ориентированные на цифровые технологии. Руководство компании осознало, что для сохранения лидирующих позиций им придется переступить через себя.

Первоначальные усилия компании по переходу к продуктовой модели были сосредоточены на цифровом опыте, ориентированном на потребителя, и это направление возглавила Энн Йогер. Она инициировала переход к продуктовой модели вместе с командой сайта carmax.com. Это начинание быстро доказало свою ценность, а дальше были несколько лет организационного роста для создания продуктовых компетенций уже в масштабе компании.

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

Трансформация, проведенная за предыдущие годы, уже принесла ощутимые результаты, и CarMax завоевала репутацию инновационной компании в сфере розничной торговли автомобилями.

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

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

Автомобили, прошедшие отбор, были доступны для продажи клиентам CarMax с 7-дневной гарантией возврата денег и 30-дневной гарантией на саму машину.

Те же машины, что не соответствовали нужному уровню качества, продавались на аукционах другим дилерам.

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

В свете новых ограничений и широких макроэкономических последствий пандемии, к началу апреля 2020 года компания объявила о снижении продаж более чем на 75% по сравнению с предыдущим годом.

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

К счастью, CarMax уже начала переходить к многоканальной розничной торговле, когда покупатели совершают покупки не только в магазине, но и онлайн, а также комбинируя оба эти варианта в разных пропорциях. И теперь это уже было не просто возможностью для роста бизнеса, а жизненно важным функционалом.

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

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

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

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

Также у CarMax появилась возможность не только просматривать автомобили онлайн, но и выбирать, оформлять заказ, оплачивать и организовывать доставку либо самовывоз. А в отношении схемы «обмен с доплатой» потребовалось оперативно определять стоимость автомобиля, который покупатель предлагает со своей стороны.

Кроме того, когда автомобили, полученные по обмену с доплатой, не соответствовали стандартам качества CarMax, в компании больше не могли полагаться на личные аукционы с другими дилерами для продажи таких машин.

Новые процессы покупки и продажи автомобилей требовали обновления целого ряда сопутствующих продуктов, связанных со всеми этапами сделки. Сюда входили финансирование, «мгновенное предложение» по обмену с доплатой, электронное внесение первоначального взноса и оформление финансовых документов с помощью электронной подписи, организация доставки по адресу, включая бесконтактную, а также новое гарантийное предложение «полюби свою машину», по которому срок гарантии увеличился с 30 до 90 дней, а окно возврата — с 7 до 30 дней, что не имело прецедентов в автомобильной отрасли.

Все эти аспекты сделки по определению являются рискованными, поскольку связаны с крупной потребительской тратой, но некоторые из них имели особенно высокий риск.

Для CarMax, бизнес-модель которой основана на постоянной разнице в цене, было необходимо обеспечить точное и справедливое ценообразование как на приобретаемые, так и на продаваемые автомобили.

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

Чтобы устранить эти риски, продуктовые команды тестировали прототипы сначала в очень маленьких группах, затем на региональном уровне и, наконец, в масштабе всей страны.

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

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

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

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

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

Примечание Марти: «Всего за несколько лет компания Trainline превратилась в один из лучших в Европе примеров инновационных продуктов, основанных на технологиях, и полностью перевернула свой бизнес. Начиналась трансформация несколько необычно. Крупная частная инвестиционная компания KKR приобрела Trainline, потому что справедливо считала, что этот бизнес значительно недооценен и что если Trainline перейдет к продуктовой модели, то сможет продемонстрировать свою реальную стоимость. KKR привела в компанию сильного генерального директора Клэр Гилмартин, которая затем привлекла опытного руководителя отдела разработки Марка Холта и проверенного главу продуктового направления Джона Мура. Далее Джон от первого лица рассказывает об этой впечатляющей трансформации».

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

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

Мы хотим, чтобы, читая главы этой части, вы держали в уме одну вещь. Здесь будут описаны идеальные сценарии взаимоотношений, однако в реальности человеческий фактор всегда вносит коррективы в ваши ожидания.

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

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

Часто клиенты воспринимают компанию как ненадежную и не заслуживающую доверия, неспособную выполнить свои обещания.

Этому есть много причин, но главное, что продуктовая модель вводит новые, прямые, принципиально иные отношения между клиентами и продуктовыми командами.

Когда компания переходит к продуктовой модели, происходят довольно значительные изменения в том, как продуктовые команды взаимодействуют с клиентами[18].

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

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

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

Мы всегда поощряем продуктовые команды объяснять свои намерения, приступая к прямому и интенсивному взаимодействию с пользователями и заказчиками, поскольку предполагаемые изменения могут сильно отличаться от целей клиентов.

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

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

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

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

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

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

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

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

Продуктовая команда не будет брать на себя обязательство до тех пор, пока не проведет достаточную работу по исследованию продукта, чтобы понять, что действительно требуется и будет ли это решение эффективным для клиента. Обычно это подразумевает создание одного или нескольких прототипов для устранения конкретных рисков. Как только потребности будут понятны, команда также учтет объем других своих работ и обязательств, прежде чем будет готова дать какое-либо обещание. Мы называем эти обещания высоконадежными, и, дав такое обещание, продуктовая команда стремится сделать все, что в человеческих силах, ради его выполнения.

Сильные продуктовые команды понимают, что принятие обязательств должно быть учтено наряду с другими вашими обязанностями, включая связанные с потенциальным риском виды деятельности по поддержанию текущей работоспособности. Высоконадежным обязательство делает тот факт, что оно основано на глубоком анализе требуемых ресурсов, а также — что оно исходит непосредственно от исполнителей.

Возможно, продуктовой команде придется напомнить клиенту, что она работает в компании, производящей коммерческие продукты. А значит, ее задача — придумать решение, которое сочтет эффективным не только конкретный клиент, но и большой сегмент пользовательской аудитории.

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

Цель исследования продукта — придумать эффективное решение проблем ваших клиентов. Ваша продуктовая команда стремится найти решения, которые понравятся вашим клиентам и при этом будут работать на ваш бизнес.

Для этого у нее имеется межфункциональный набор навыков в области управления продуктом, продуктового дизайна и инженерных разработок. Чтобы глубоко понимать стоящую проблему и тестировать потенциальные решения, продуктовая команда напрямую взаимодействует с пользователями и клиентами.

Как правило, в ходе прямого взаимодействия с клиентом команда фокусируется как на понимании его проблемы, так и на выяснении того, удалось ли ей предложить ценное, полезное, осуществимое и жизнеспособное решение.

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

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

Во-первых, вы обещаете эффективно тестировать свои решения, что подразумевает два разных аспекта:

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

Пожалуй, нет двух более взаимозависимых ролей в компании, чем продукт и продажи.

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

Если хоть один из них сдаст позиции, возникнут серьезные проблемы.

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

Продуктовая команда недовольна, потому что отдел продаж постоянно просит (или требует) создавать функции, которые, как знают в команде, не решат реальных проблем клиентов.

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

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

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

Хорошая новость в том, что продуктовая модель разработана для исправления этой проблемы и имеет большой опыт применения в этом направлении.

В первую очередь важно понять, какие отношения должны установиться между продуктовыми командами и клиентами, как это было описано в главе 21 «Работаем с клиентами». Схема, в рамках которой менеджер по продажам записывает требования от потенциального клиента и передает их команде для разработки, противоречит продуктовой модели.

В то же время в ее основе лежит ориентация на обретение довольных клиентов, готовых вас рекомендовать, и продуктовое направление должно сотрудничать с отделом продаж для поиска и выращивания этих перспективных референтных клиентов.

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

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

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

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

В результате тесной совместной работы два основных фактора соответствия «продукт — рынок» становятся заметной силой. Затем, работая с несколькими потенциальными клиентами, продуктовая команда узнаёт, что именно соответствует требованиям клиентов, а что — нет, и это позволяет ей создавать единое решение, которое будет успешно внедрено у львиной доли пользовательской аудитории.

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

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

Есть еще одно важное последствие продуктовой модели для продаж. В большинстве традиционных операционных моделей отдел продаж является единственной группой сотрудников, ориентированной на клиента и ориентированной на результат (по объему продаж оценивается и стимулируется их производительность). Продуктовая модель дает отделу продаж настоящего соратника, который также ориентирован и на клиента, и на результат. При правильном подходе продукт и продажи получают по-настоящему обогащающий опыт общего дела.

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

В некоторых компаниях продуктовой команде везет работать с одним маркетологом, выделенным только для нее, но в большинстве случаев несколько продуктовых команд будут контактировать с одним и тем же специалистом, а иногда с несколькими. Это объясняется тем, что, как правило, маркетинговые команды имеет смысл организовывать по иному принципу, чем продуктовые. Но вне зависимости от того, есть ли у вас выделенный маркетолог или вы делите одного специалиста с другими командами, менеджеру по продукту необходимо наладить с ним необходимые отношения.

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

Хотя большинство людей интуитивно понимают, как взаимодействует маркетинговое и продуктовое направления, многие удивляются, увидев всю глубину и силу этого сотрудничества в его наилучшем варианте.

Итак, вот к чему вы стремитесь в продуктовой модели.

Когда продуктовые команды работают над изучением различных рынков, продуктовый маркетолог является ключевым ресурсом с доступом к отраслевой аналитике, анализу рынка, исследованиям конкурентов и т. д. Вся информация о новых конкурентах и перспективных технологиях свободно циркулирует между обоими направлениями.

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

Вывод продукта на рынок — это, пожалуй, самая важная область сотрудничества. При работе над новым продуктом для существующего рынка или при выводе существующего продукта на новый рынок, а особенно в случае создания нового продукта для нового рынка, разработка эффективного продукта — это только половина проблемы. Вторая половина — найти эффективный способ доставки продукта в руки покупателей, что называется «выводом продукта на рынок».

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

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

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

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

Если говорить прямо, то вывод продукта на рынок — один из самых важных моментов в определении успешной стратегии развития продукта.

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

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

Менеджер по продукту и менеджер по маркетингу продукта плотно сотрудничают по всем аспектам этой программы. Продуктовый менеджер применяет полученные выводы к новому продукту, а маркетолог — к его выводу на рынок, к инструментам продаж и к процессу продаж.

Даже при ежедневных изменениях в продукте бывают заметные изменения, влияющие на систему смыслов (месседжинг) и позиционирование.

Иногда эти изменения носят ситуативный характер, а порой они имеют широкие последствия для продукта.

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

Благодаря таким современным методам разработки, как непрерывное внедрение, изменения в продукте происходят по многу раз за день, но часть из них могут серьезно повлиять на ваших клиентов, отдел продаж или отдел заботы о клиентах. В этом случае вам необходимо синхронизировать действия с коллегой-маркетологом, чтобы предстоящее изменение не застало всех врасплох.

Если ваш коллега из маркетингового отдела оказался не готов к внесенному изменению (например, потому, что только узнал о них), то вам стоит либо воздержаться от выпуска данной функции, либо, при наличии подходящей инфраструктуры внедрения, выпустить ее таким образом, чтобы клиенты не видели ее, пока маркетолог не сообщит о готовности со своей стороны.

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

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

Продуктовые команды, конечно, вносят свой вклад в принятие решений о ценовой политике, но для расчета идеальной цены используется множество других факторов.

Работе маркетологов помогают различные продуктовые команды, но именно направление маркетинга отвечает за цифровые и печатные материалы для продвижения продукта и различные инструменты, необходимые менеджерам по продажам.

Если продуктовые менеджеры не пожалеют времени на установление рабочих отношений с маркетологами, то, скорее всего, они по достоинству оценят компетентность коллег в понимании возможностей и нюансов продукта. Однако если это не так, то львиная доля этой работы ляжет на плечи менеджеров по продукту. Именно поэтому опытные продуктовые менеджеры понимают, что время, потраченное на объяснение нюансов маркетологу, в дальнейшем окупится сторицей.

Подробнее о важной роли продуктового маркетинга можно узнать из книги нашей коллеги Мартины Лаученгко «Продуктовый маркетинг по любви».

Сотрудничество с коллегами из финансов, а часто и с инвесторами, является критически важным аспектом работы, потому что у вас просто нет другого выхода, кроме как наладить эффективные партнерские отношения. Компания зависит от продукта, который она продает, а специалисты по продукту зависят от финансирования.

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

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

Начните с совместного анализа данных и признайте, что текущая модель недостаточно предсказуема для принятия правильных решений о финансировании, а также для оценки прибыльности продукта. Если у вас есть сомнения, можно убедиться в этом, сравнив требования к бизнес-проекту с фактическими результатами предыдущих кварталов.

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

Как правило, все это до боли понятно. Остается единственный вопрос: можем ли мы работать лучше?

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

В зависимости от степени разочарования старой моделью и степени срочности перехода к новой модели, вы можете проводить тестирование либо осторожно (с малым количеством продуктовых команд), либо более активно.

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

При переходе к продуктовой модели изменится целый ряд операций в рамках сотрудничества между продуктовым и финансовым отделом.

Продуктовые команды обещают перестать прятаться за списком функций и «дорожными картами», прогнозируя лучшие результаты, как только будет готова следующая новая функция. Продуктовые команды перестанут придумывать бизнес-кейсы, а затем искать оправдания за отсутствие ожидаемого результата.

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

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

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

В дальнейшем, обращаясь с просьбой о выделении дополнительных ресурсов, они будут предоставлять убедительные данные и прозрачный анализ с обоснованием этой просьбы.

Вместо крупных запросов на финансирование продуктовая команда сначала проведет очень недорогие тесты для сбора необходимых данных. Затем, если у них появится более крупный запрос, он будет сопровождаться фактическими данными, подтверждающими важность этих вливаний.

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

Когда продуктовая модель начнет генерировать реальные и стабильные инновации, продуктовое направление не забудет показать доказательства окупаемости инвестиций финансовой службе и инвесторам.

Для того чтобы партнерство складывалось успешно, продуктовому отделу потребуется от финансового несколько вещей:

Мы определяем стейкхолдера как человека, который не является участником продуктовой команды, а представляет в компании какое-то важное направление, область бизнеса или сферу применения специальных знаний.

Нельзя отрицать, что переход на продуктовую модель — это серьезное изменение для стейкхолдеров.

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

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

Остальные займут выжидательную позицию.

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

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

На практике это означает установление отношений, основанных на взаимном доверии.

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

Создать решение, которое придется клиентам по душе, обычно не так уж сложно — при условии, что продуктовая команда имеет прямой и свободный доступ к пользователям, а также к данным о продукте.

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

Вы должны быть уверены, что сможете профинансировать данный продукт, а затем хорошо его монетизировать. Продукт должен быть пригоден для внедрения. Необходимо обеспечить его соответствие нормативным требованиям, законам о конфиденциальности и партнерским соглашениям, а также гарантировать отсутствие нежелательных последствий для людей и окружающей среды.

Очевидно, что вы не сможете сделать все это в одиночку.

Кроме того, мы понимаем, что для создания любого продукта необходимо принять сотни, если не тысячи решений. Собирать всех ключевых стейкхолдеров для принятия каждого решения — это не только чрезмерная трата времени и денег. Опыт говорит, что заседания больших комиссий редко приводят к инновациям.

Чтобы ваш продукт был новаторским, нужен прямой доступ — в равной мере и к клиентам, и к технологиям.

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

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

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

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

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

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

В случае возникновения проблемы продуктовая команда может оперативно осуществлять доработки до тех пор, пока стейкхолдеры не убедятся, что в нынешнем виде решение будет отвечать их задачам и работать на бизнес-цели.

Иногда это будет легко. Но иногда, чтобы получить решение, которое будет работать не только для клиентов, но и для многочисленных стейкхолдеров — каждого со своими потребностями, — может потребоваться длинная череда итераций, чтобы найти решение, которое устроит всех. Более того, оно может оказаться таким, что никто из заинтересованных сторон и представить себе не мог, что такое возможно.

В целом менеджер по продукту стремится работать над достижением желаемых бизнес-целей. Продуктовые команды знают, что внедрение функций само по себе не обязательно решит основную проблему клиента или бизнеса. Команда продукта стремится к достижению необходимых результатов.

Но мы обещаем не разрабатывать — и уж тем более не внедрять — решения, которые не отвечают критически важным потребностям бизнеса.

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

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

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

В зависимости от состояния корпоративной культуры, переход к продуктовой модели может существенно отразиться на взаимодействии руководства с продуктовыми командами и продуктовыми лидерами.

Переход к продуктовой модели часто требует значительных культурных изменений, особенно если речь идет об уходе от командно-административного стиля руководства от принципа «сверху вниз».

Когда мы обсуждаем необходимые изменения, то в основном фокусируемся на том, что нужно продуктовому и технологическому направлению. Однако важным аспектом трансформации является изменение динамики между продуктовым направлением и топ-менеджментом.

Признаемся честно, было бы здорово, если бы изменения можно было свести к одной просьбе к руководству: «Пожалуйста, отойдите в сторону и дайте продуктовым командам возможность развернуться в полную силу».

Но стоит учитывать, что у руководства есть вполне реальные потребности в том, что касается ответственного и эффективного управления компанией.

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

Поэтому в рамках продуктовой модели контакты с топ-менеджментом надо не снижать, а сделать частыми и качественно другими.

По сути, мы говорим о характере этих взаимодействий.

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

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

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

Но команды могут принимать правильные решения лишь тогда, когда им предоставляется необходимый стратегический контекст. Поэтому руководству крайне важно вводить их в курс дела: делиться с ними бизнес-стратегией, финансовыми параметрами, изменениями в законодательстве, тенденциями в отрасли и содержанием договоров с другими компаниями.

Продуктовые команды зависят от руководства, которое должно делиться с ними максимальным количеством информации о стратегическом контексте, чтобы принимать правильные решения.

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

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

Но это получится лишь в том случае, если перед продуктовыми командами ставится проблема, которую нужно решить (а не поручается конкретное решение, которое нужно разработать), а затем они получают возможность самостоятельно придумать решение, которое принесет нужный эффект.

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

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

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

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

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

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

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

Продуктовые команды понимают, какой ущерб наносится организации, когда данные обещания не выполняются.

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

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

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

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

Одна из худших форм расточительства — это когда продуктовая команда создает качественное масштабируемое решение, а после обнаруживает, что по какой-то причине оно неприемлемо.

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

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

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

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

Кроме того, и сами продуктовые лидеры с командами должны ощущать, что топ-менеджмент ведет компанию в нужном направлении.

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

Примечание Марти: «Сегодня по всему миру можно найти потрясающие примеры трансформации и инноваций, и мне очень нравится, как показала себя эта бразильская компания после испытания пандемией».

Gympass[19] — бразильская компания, основанная в 2012 году с целью улучшить здоровье и самочувствие сотрудников, помогая справиться с сидячим образом жизни.

Через платформу Gympass работодатели могут предоставлять своим сотрудникам доступ к сети из более чем 50 тысяч тренажерных залов и студий в 11 странах мира.

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

Чтобы задействовать преимущества современных технологий, в 2018 году в Gympass решили, что им необходима трансформация к продуктовой модели, для чего на должность продуктового директора был приглашен опытный руководитель продукта Жока Торрес.

Вместе с техническим директором и директором по маркетингу они втроем довольно быстро и с нуля построили технологическое и продуктовое направление. Команды начали свою работу с автоматизации большинства задач, выполнявшихся операционным подразделением, а также с обновления пользовательских процессов со стороны тренажерных залов, конечных пользователей (сотрудников) и сотрудников отдела кадров (чтобы они могли видеть, как именно это влияет на персонал).

Усилия быстро окупились, и в 2020 году компания вышла на траекторию уверенного роста.

Увы, потом началась пандемия.

Одной из отраслей, которая немедленно попала под удар, стала фитнес-индустрия, особенно тренажерные залы и студии.

По всей стране наемные работники перестали не только ходить в офисы, но и посещать спортзалы.

Бесчисленные игроки фитнес-рынка были вынуждены закрыться.

Как и многие другие компании в тот период, руководство Gympass столкнулось с экзистенциальным кризисом. Они понимали, что их миссия — победить пассивный образ жизни — сейчас актуальна как никогда, но также осознавали, что им придется быстро и кардинально изменить свой подход.

К счастью, продуктовый отдел компании изучал и тестировал среди своих пользователей множество идей продуктов, связанных с фитнесом. К тому времени уже было обнаружено, что значительная часть пользователей интересуется оздоровительными занятиями, выходящими за рамки фитнеса в спортзале: медитацией, практиками осознанности, здоровым питанием и домашними упражнениями.

Продуктовой команде предстояло решить следующую задачу: предоставить пользователям Gympass ряд домашних оздоровительных решений, чтобы они могли поддерживать физическую форму, даже не имея доступа к спортзалу или фитнес-студии.

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

Команда начала интенсивную работу по продуктовому исследованию — быстро построила серию прототипов, призванных устранить два основных риска.

Первый и самый серьезный риск касался ценности для конечных пользователей. Если сотрудники компаний-клиентов не захотят использовать новое решение, отказ от оплаты услуг Gympass будет лишь вопросом времени.

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

Основным инструментом для этой работы стал пользовательский прототип, который демонстрировал взаимодействие пользователя с различными велнес-продуктами, то есть сервисами для физического и психологического благополучия. Кроме того, было создано несколько прототипов для проверки осуществимости необходимых партнерских интеграций.

Как только команда почувствовала, что справилась с этими рисками, нужно было в рекордные сроки перейти от прототипа к продукту.

Помимо разработки и внедрения, компания менее чем за два месяца набрала около 100 нишевых фитнес-партнеров, чтобы обеспечить максимальный охват своих разноязычных пользователей.

В течение четырех недель Gympass вышел на рынок в десяти странах, и всего за несколько месяцев количество пользователей выросло с нуля до нескольких сотен тысяч.

Команда, которая отвечала за этот запуск, состояла из одного продакт-менеджера, одного продуктового дизайнера и четырех разработчиков, которые сотрудничали с выделенным специалистом по бизнес-операциям и маркетологом. Также в запуске поучаствовал отдел продаж, привлекавший региональных партнеров.

Если бы Gympass не вложила средства в трансформацию, у нее почти наверняка не оказалось необходимых навыков для столь быстрого поворота бизнеса, и ее, скорее всего, постигла бы та же участь, что и многих других представителей фитнес-индустрии.

Вместо этого в разгар пандемии Gympass удалось более чем вдвое увеличить число корпоративных клиентов и общую выручку. Стоимость компании выросла до 2,2 миллиарда долларов США, и сегодня взлет Gympass является яркой страницей в истории латиноамериканской технологической индустрии.

Примечание Марти: «Когда я впервые услышал, что Кристиан собирается присоединиться к этой компании в качестве руководителя продуктового отдела, я уже знал его несколько лет и считал одним из самых талантливых специалистов в нашей отрасли. Я сказал, что могу помочь ему с аналогичной позицией в какой-нибудь более известной компании, но ему очень хотелось посмотреть, сможет ли он преобразовать устаревшую, ориентированную на продажи финансовую компанию и вывести ее в лидеры рынка. Сомневаться в квалификации Кристиана не приходилось, однако я прямо ему сказал, что он взвалил на себя исключительно трудную задачу. Но таков уж у него характер, сложности его не пугают. Итак, он присоединился к двум другим опытным лидерам — Томасу Фределлу и Джеремии Айвену. Втроем им удалось раздвинуть границы возможного».

Мы обсудили, что означает преобразование в продуктовую операционную модель, каковы ее ключевые концепции и каковы компетенции, которые в ней применяются. Кроме того, мы привели несколько примеров компаний, успешно прошедших трансформацию, и теперь готовы поговорить на более теоретическую тему: управление изменениями.

Другими словами, как лучше всего добраться из того места, где вы сейчас находитесь, туда, куда вы хотите попасть?

В зависимости от размера организации, проводящей трансформацию, переход к продуктовой модели занимает от шести месяцев до двух лет, и это при условии, что компания серьезно относится к преобразованиям и это не просто спектакль.

Семь глав этой части посвящены методикам, которые мы считаем полезными в работе над вашей трансформацией.

Когда будет завершена работа по преобразованию?

Учитывая, что компании, производящие успешные продукты, продолжают импровизировать и экспериментировать, можно сказать, что трансформация никогда не завершается. Однако есть веха, которая делит историю компании на «до» и «после».

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

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

Вот почему при обсуждении трансформации так важно рассматривать эту работу как достижение реальных результатов.

Именно поэтому в нашей книге мы приводим так много примеров новаторства в компаниях, где перешли на продуктовую модель.

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

Поэтому когда мы говорим об итогах трансформации, то всегда строим дискуссию вокруг результатов. Что вы надеетесь сделать после трансформации, чего не можете делать эффективно сегодня?

Предсказать будущее невозможно, и вы не сможете из сегодняшнего дня назвать ваши конкретные цели в отношении возможностей, которые появятся в будущем.

В конечном счете большинство компаний хотят уметь выявлять и использовать наиболее перспективные возможности, а также эффективно реагировать на наиболее серьезные угрозы.

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

Компании, которые ранее перешли на продуктовую модель, смогли быстро освоить новые технологии, в том числе технологии генеративного ИИ, и решить проблемы своих клиентов так, как не получалось раньше. Сейчас они на пике своего потенциала.

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

Честная и точная оценка текущей ситуации в организации необходима для любого плана успешных преобразований.

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

Но цель этой главы — помочь вам провести такую оценку самостоятельно, даже если вы никогда не делали ничего подобного раньше. В этом случае процесс, скорее всего, займет несколько дней.

Прежде чем мы перейдем непосредственно к самой экспертизе, необходимо сделать несколько важных оговорок.

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

Но формирование этих компетенций обычно является одной из первоочередных задач, поскольку без соответствующих навыков люди не смогут успешно освоить ключевые понятия продуктовой модели.

Обратите внимание, что многие техники из этой главы описаны гораздо подробнее в книге «Создающие ценность».

Новые определения должностей

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

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

Успех начинается с четкого определения требуемой работы. Затем вы можете начать оценивать, кто из ваших сотрудников способен качественно справиться с этими обязанностями. При умелом руководстве со стороны лидера или тренера по продукту многие осилят новые компетенции. Но если вы не измените сам настрой и ожидания от работы, то не увидите изменений в поведении или производительности.

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

После того как компетенции по созданию новой модели продукта сформированы, люди готовы начать использовать свои навыки для работы над продуктом.

Помните, что такие навыки, как продуктовая стратегия и исследование продукта, находятся в вечном процессе совершенствования. Непрерывно появляются новые методики и инструменты, и хорошие продуктовые компании постоянно работают над своим развитием.

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

Обратите внимание, что многие техники из этой главы описаны гораздо подробнее в книге «Создающие ценность».

Отношения в команде

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

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

Важно отметить, что эти различные тактики освоения элементов трансформации не являются взаимоисключающими. Более того, их можно совмещать, с учетом обстоятельств.

На ваш конкретный выбор тактик освоения может повлиять множество факторов:

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

В конечном счете план трансформации будет представлять собой обещание большого объема работы.

Как и при любом другом перечислении задач, важно определить ответственность и подотчетность каждого элемента. Пусть несколько человек работают вместе над какой-то задачей или над всем проектом, но в большинстве случаев без личной ответственности и подотчетности результаты будут скромны.

Теперь, когда у вас есть план преобразования вашей организации, вам необходимо его реализовать.

Эти усилия должны продолжаться в течение длительного времени — обычно от шести месяцев до двух лет, — и за это время очень легко потерять фокус или интерес к трансформации. Вам придется приложить немало усилий, чтобы этого избежать.

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

Примечание Марти: «Еще одно очень распространенное в продуктовом сообществе заблуждение заключается в том, что инновации происходят только в потребительских продуктах, а создание продуктов для крупных компаний — это совсем другая игра. Да, надо признать, что многие корпорации, занимающиеся разработкой программного обеспечения, весьма медленно переходят на продуктовую модель, а в организациях, чей бизнес построен на продажах, бывает трудно осуществить изменения. Но следующий пример показывает, что те, кому это удается, получают огромные рыночные преимущества».

В части VII вы узнали об истории трансформации Datasite. Но причина, по которой в компании прилагаются усилия для перехода к продуктовой модели, в том, что в организации имеется желание обрести способность к постоянным инновациям. В данном примере новаторства вы увидите, как это происходит на практике.

Одним из ключевых моментов успешного бизнеса по слияниям и поглощениям является защита корпоративных данных. В процессе переговоров между сторонами происходит обмен многочисленными конфиденциальными документами. Если не обеспечить безопасный оборот этих документов, они могут быть утеряны или даже украдены.

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

Эта процедура применяется к тексту, изображениям или другим данным в документе. Такой процесс гарантирует, что информация не станет достоянием общественности и не будет продана мошенникам.

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

В 2019 году отредактированные документы стали поводом для появления одной из главных юридических и политических новостей.

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

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

Компания Datasite знала, что для сохранения доверия клиентов ей необходимо создать инструмент редактирования, который обеспечит конфиденциальность документов, передаваемых в процессе слияний и поглощений.

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

Datasite пришла к выводу, что на рынке нет подходящего инструмента, поэтому необходимо самостоятельно создать новый и эффективный продукт для редактирования коммерческих данных. До того как компания прошла трансформацию, это было невозможно. Но, к счастью, благодаря переходу на продуктовую модель, в Datasite уже располагали нужными мощностями для подобной задачи.

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

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

Разработчикам нужен был способ не только «вычистить» документ, но и по запросу воссоздавать скрытые данные, имея соответствующие разрешения и доступ к информационной системе.

Как это часто бывает, один из инженеров придумал новый подход к решению этой проблемы, вдохновившись чужим примером — в данном случае инструментом, который автоматически скрывал конфиденциальные данные в Google Maps. Чтобы доказать техническую осуществимость, инженеры создали прототип и продемонстрировали его продуктовой команде и руководителям продукта.

Следующим этапом стал еще один прототип — для тестирования клиентского опыта на платформе Datasite.

С помощью более чем десятка партнеров в Европе и Северной Америке были проведены исследования пользователей, чтобы уточнить нюансы и со всех сторон проверить предложенное решение. В ходе этого обширного тестирования отделы продаж, маркетинга и обслуживания приняли участие в исследовании продукта на ранней стадии, взаимодействуя с клиентами в Лондоне, Париже и Нью-Йорке.

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

Инструмент удаления конфиденциальных данных Datasite стал большим конкурентным преимуществом на рынке, обеспечив реальную ценность для клиентов компании, а также их спокойствие.

Примечание Марти: «Сейчас вы прочитаете историю одной из самых впечатляющих трансформаций, которые я когда-либо видел. Adobe всегда были одним из крупных игроков на рынке программного обеспечения и создали целый ряд успешных продуктов, однако они не работали в рамках продуктовой модели. В компании понимали, что в условиях надвигающихся рыночных рисков без изменений не выжить. В данном случае сам запрос на новаторство послужил основой для трансформации. Движущей силой преобразований стала необходимость создания нового предложения Creative Cloud. Историю рассказывает Ли Хикман, которая была назначена руководителем отдела управления продуктами для нового облачного сервиса Adobe Creative Cloud. Ли объединила усилия с техническим директором Кевином Линчем, и при поддержке нескольких очень сильных топ-менеджеров им удалось провести трансформацию, которая и по сей день считается самой финансово успешной в отрасли».

В любом достаточно крупном коллективе всегда найдется место возражениям против существенных изменений.

Конечно, всегда будут те, кто сопротивляется переменам просто из принципа, и у нас есть методы борьбы с такой ситуацией.

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

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

Примечание: большая часть этого обсуждения основана на главе 21 «Работаем с клиентами».

Примечание: большая часть этого обсуждения основана на главе 22 «Работаем с отделом продаж».

Примечание: большая часть этого обсуждения основана на главе 26 «Работаем с топ-менеджментом».

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

«Каждый день мы сталкиваемся с трудными клиентами. Мы буквально находимся на передовой. Однако продуктовым командам, похоже, все равно, что у нас есть острые потребности».

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

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

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

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

Важно понимать, что «список топ-10 проблем» будет существовать всегда, но продуктовые команды должны постоянно работать над проработкой этих пунктов.

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

Примечание: в контексте этой главы мы объединяем все виды маркетинга — продуктовый маркетинг, «полевой» маркетинг, корпоративный маркетинг и маркетинг бренда. Обратите внимание, что значительная часть этого обсуждения основана на главе 23 «Работаем с продуктовыми маркетологами».

Примечание: большая часть этого обсуждения основана на главе 24 «Работаем с финансовым отделом».

«Эти новые профессиональные компетенции серьезно нарушают работу в компании. У нас много людей, занимающих должности, которые больше не актуальны, а у ряда других сотрудников сильно изменился круг обязанностей. Изменение классификации должностей — дело нелегкое, и оно связано со значительными затратами. Мы предпочли бы сохранить наши нынешние кадры и существующее штатное расписание».

«У нас много сотрудников на позициях, связанных с технологиями. Давайте просто поменяем их названия на продуктовых менеджеров и отправим их на какие-нибудь курсы, вместо того чтобы нанимать новых людей».

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

Важно также понимать, что не все ваши сотрудники захотят принять новую роль менеджера по продуктам. Эта позиция связана с большой ответственностью, особенно в сравнении с должностью управляющего продуктом или бизнес-аналитика.

Тем не менее если у вас есть управленцы, которые хотят и могут проводить необходимые тренинги (а это большой вопрос), и если у вас есть люди, готовые переучиваться, то первым делом мы советуем попытаться тренировать и развивать этих людей. Как правило, способный руководитель должен быть в состоянии за три месяца довести перспективного кандидата до приемлемого уровня компетентного продуктового менеджера. Если же после трех месяцев искренних усилий человек все еще не способен выполнять требуемую работу, вам нужно определить его на другой участок работы и найти ему подходящую замену.

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

В продуктовой модели технологии действительно приобретают новый смысл. Вместо статьи расходов они становятся генератором прибыли.

Мы работали со многими директорами по информационным технологиям, которые расширили свои навыки, чтобы справляться с новой ролью (иногда ее называют комбинированной — технический директор / ИТ-директор). Именно эти люди и стремились к переменам, а порой и выступали инициаторами перехода к продуктовой модели.

Важно отметить, что продуктовая модель охватывает не только технологии, с которыми непосредственно взаимодействует клиент. Как правило, значительный объем разработки остается «за кулисами» — либо в сервисах платформы, либо во вспомогательных инструментах для клиентов, либо во внутренних инструментах.

Мы понимаем, что не все ИТ-директора хотят меняться. В этом случае они останутся работать с информационными технологиями в узком смысле: управление работой с поставщиками и системы, на которых базируются бизнес-процессы. Для продуктовых разработок в широком смысле будет привлечен кто-то другой.

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

Во-первых, продуктовое направление главным образом занимается разработкой, в то время как ИТ-отдел в узком смысле в основном занят интеграцией систем, поставляемых поставщиками (покупкой).

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

Эти различия обычно отражены и в должностных инструкциях инженеров, и в шкале оплаты труда.

Еще одно очень важное различие заключается в том, что в сфере классических информационных технологий аутсорсинг поощряется, ведь они не являются центральной компетенцией компании. Но в продуктовой сфере передача разработки на аутсорсинг, как правило, для инноваций фатальна.

Примечание: под руководителем проектов здесь понимается офис управления программами, который, по сути, управляет проектами с доступом под контролем первых лиц компании.

Примечание: в рамках данной главы мы смотрим на возражения от широкого круга сотрудников из сферы продукта и технологий (продуктовые менеджеры, продуктовые дизайнеры, разработчики, операционные менеджеры, а также продуктовые лидеры).

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

Kaiser Permanente — одна из крупнейших в США некоммерческих организаций в сфере здравоохранения и медицинского страхования, обслуживающая более 12 миллионов пациентов.

В 2019 году цифровое подразделение Kaiser Permanente приступило к масштабной трансформации в сторону продуктовой модели.

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

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

А через год после запуска преобразований началась пандемия COVID-19.

Практически в одночасье подход Kaiser Permanente к оказанию медицинской помощи пришлось менять — в связи с чрезвычайной ситуацией в области здравоохранения. Теперь на оказание медицинской помощи были наложены суровые ограничения.

За несколько лет до этого компания начала внедрять телемедицину в ряде направлений. Однако на тот момент решения в области дистанционных медицинских услуг имели ряд фундаментальных ограничений.

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

Кроме того, пациенты могли записаться на дистанционный прием только в своем регионе, что не позволяло им получать виртуальную помощь вдали от дома. Сочетание технических, нормативных, клинических и операционных ограничений не позволяло внедрять телемедицину последовательно и широко, хотя географический охват у компании был достаточно широкий.

В начале пандемии замаячил риск того, что многие пациенты останутся вообще без медицинской помощи.

Компании Kaiser Permanente срочно понадобилось расширить подходы к оказанию медицинской помощи, чтобы охватить как можно больше пациентов.

Компании требовалось технологичное решение, которое позволит пациентам получать доступ к необходимой медицинской помощи в нужное время, вне зависимости от региона проживания, от их возможности добраться до медицинского учреждения и от времени суток.

Эта инициатива получила название Get Care Now («Получи помощь прямо сейчас») и стала единым общегосударственным решением по оказанию врачебной помощи онлайн и круглосуточно.

В продуктовом направлении Kaiser Permanente понимали, что у данного продукта есть существенные риски.

Приоритетом и мотивацией было удовлетворение потребностей пациентов в условиях повышенного риска для здоровья, вызванного пандемией.

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

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

Поставщикам услуг (врачам и медицинскому персоналу) тоже требовалось освоить новый способ оказания помощи. Важно было убедиться, что они смогут обеспечить необходимое обслуживание пациентов до, во время и после приема по телемедицинской записи. Помимо фактического медицинского обслуживания, существует ряд специфических медицинских, нормативных и операционных требований.

Поскольку опыт «здравоохранения по интернету» был новым как для пациентов, так и для врачей, продуктовой команде предстояло изучить ожидания и поведение обеих групп при виртуальном взаимодействии. Как долго пациенты готовы ждать приема? Какие заболевания лучше всего подходят для виртуального сеанса, а какие требуют очного осмотра?

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

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

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

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

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

Кроме того, решение, рассчитанное на более чем 12 миллионов пациентов, должно было хорошо масштабироваться.

Для поддержки программы Get Care Now предстояло собрать и обобщить ключевые данные о количестве врачей, о расписании приемов и об информации о состоянии здоровья пациентов.

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

Примечательно, что проект Get Care Now был создан очень быстро. Всего четыре месяца прошло с момента первой идеи до запуска нового сервиса. После того как были собраны данные о его фактическом использовании пациентами и врачами, спустя три месяца была внедрена следующая итерация.

С момента полного запуска Get Care Now пациенты Kaiser Permanente получили круглосуточный доступ к виртуальному обслуживанию у своих лечащих врачей в режиме онлайн во всех штатах страны.

Что особенно важно, уровень удовлетворенности клиентов составил 9,6 из 10, а чистая оценка по индексу лояльности клиентов достигала 88%. Более 36% пациентов, пользующихся этой услугой, были приняты в нерабочее время — с 17:00 до 8:00, что избавило многих из них от необходимости посещения отделений неотложной помощи и снизило нагрузку на этот сегмент системы здравоохранения.

В целом многие считают, что в регулируемых отраслях вроде медицины невозможно внедрить инновации такого уровня, тем более за 4 месяца.

Компания Kaiser Permanente доказала, что ей это по плечу — и доказала не только в глазах собственных сотрудников и высшего руководства, но и всей отрасли. Она обеспечила настоящую ценность как пациентам, так и многим преданным своему делу медицинским работникам.

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

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

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

Здесь мы сосредоточимся на десяти моментах, которые, по нашему мнению, приоритетны для повышения ваших шансов на успех.

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

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

Запомните: хотя в центре этой трансформации находится управление продуктом, дизайн и разработка, ее последствия обязательно выйдут далеко за пределы продуктового отдела.

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

Словом, он должен быть главным евангелистом, сторонником и защитником продуктовой модели.

По своей сути успешная трансформация меняет представление о роли технологий в организации, превращая их из неизбежной статьи расходов в основную движущую силу бизнеса. Этот образ мышления отражается практически на всех аспектах: как финансируются технологии, как укомплектовываются команды, считаются ли технологии ключевой компетенцией или второстепенной функцией для аутсорсинга.

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

Невозможно переоценить важность этого момента. Именно эти люди несут ответственность за все последующие действия.

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

Расширение возможностей продуктовых команд зависит от компетентных продакт-менеджеров. В большинстве компаний, где пытаются трансформироваться, это будет новая компетенция, несмотря на наличие людей на таких позициях.

Хотя в компаниях часто есть люди с должностью «менеджер по продукту», это название может ввести в заблуждение, поскольку настоящие продуктовые команды предъявляют к менеджеру по продукту совсем другие требования, нежели функциональные команды предыдущего образца.

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

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

Если быть еще более откровенным, то продуктового лидера будут оценивать по самому слабому продакт-менеджеру.

Руководство продуктом не второстепенная роль, и она требует сильных людей с глубоким пониманием целевой аудитории продукта, знанием статистики, пониманием специфики бизнеса, рыночного контекста и технологических тенденций.

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

Инженеры, наделенные широкими полномочиями, являются двигателем инноваций для всей компании. Львиная доля эффективной трансформации заключается в создании условий и поощрении разработчиков, обладающих широким кругом возможностей.

На всякий случай подчеркнем, что у вас не будет новаторских разработчиков с широкими полномочиями, если вы отдадите эту компетенцию на аутсорсинг.

Никто не предлагает возводить инженеров на пьедестал, но вам нужно вытащить их из пресловутого «гаража» и поставить вровень с остальными сотрудниками продуктовой команды. Их надо привлекать к решению самых сложных проблем, с которыми вы сталкиваетесь.

Цель вашей продуктовой стратегии — определить приоритетные проблемы, которые необходимо решить в первую очередь, чтобы компания достигла своих целей.

До трансформации большинство компаний ни разу не создавали стратегию продукта осознанно. Фактически они просто старались обрадовать как можно больше стейкхолдеров, а это вовсе стратегией не назовешь.

Однако эффективная продуктовая стратегия, основанная как на количественных, так и на качественных показателях, является ключом не только к полноценному применению талантов вашими сотрудниками, но и к получению максимальной отдачи от инвестиций в технологии.

За продуктовую стратегию отвечают ваши продуктовые лидеры, и это еще одна причина, по которой так важно поставить на эти позиции опытных и сильных специалистов.

Один из самых сложных аспектов успешной трансформации — перестройка отношений между продуктовым направлением и различными частями бизнеса.

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

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

Если говорить прямо, это означает переход от модели подчинения к модели сотрудничества.

Большинство сотрудников других отделов не в восторге от старых подходов к продуктовой работе, поэтому они как минимум готовы попробовать что-то поменять. Но приготовьтесь к тому, что некоторые из них примут потерю контроля близко к сердцу. Руководители продукта и продуктовые команды должны проявить тактичность в этом вопросе.

Важно, чтобы продуктовые лидеры не форсировали эти изменения, пока в продуктовых командах не появятся компетентные продакт-менеджеры, готовые взяться за дело и выполнять свои обязанности по новым стандартам. Когда же ваши команды будут укомплектованы, им может понадобиться активная поддержка со стороны топ-менеджмента, чтобы убедить специалистов других направлений перейти к модели сотрудничества.

Важно не пытаться ничего скрывать, поскольку перемены очень глубоки.

Еще одна важная обязанность продуктового лидера — евангелизм, то есть непрерывная популяризация работы на результат. Нужно рассказывать сотрудникам про видение и стратегию продукта, важность переноса фокуса на этот результат, а также на продуктовую модель в целом.

Видение продукта — это вдохновение и мотивация для работы и совместных усилий всей организации.

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

Как мы помним, работая над созданием продуктов для решения поставленных перед ними задач, продуктовые команды каждую неделю учатся чему-то новому.

Важно честно и открыто делиться накопленным опытом, чтобы вся компания понимала, как происходит обучение, откуда берутся инновации и что значит действительно добиваться результатов в бизнесе, а не просто реализовывать функции и завершать проекты.

Несомненно, успешная трансформация — это сложный процесс. Мы надеемся, что данный список поможет понять причины сложностей и как с ними справиться.

Однако список был бы неполным, если бы мы не отметили, что каждый известный нам случай успешной трансформации требовал от руководителей и других топ-менеджеров настоящей храбрости.

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

Надеемся, что эти десять ключей помогут вам глубже понять, что необходимо для успешной и эффективной трансформации вашей компании в продуктовую модель.

Примечание Марти: «Как вы уже имели возможность убедиться, руководство компании Trainline создало очень сильное продуктовое направление, способное последовательно внедрять необходимые инновации. Из всех примеров их мастерства следующая история — моя любимая. Вы можете увидеть каждую из компетенций и понятий продуктовой модели на практике, когда сотрудники решают очень сложную, но многообещающую проблему. Найденное ими решение представляло огромную ценность для клиентов, для партнеров в железнодорожной отрасли и для их компании. Уровень новаторства продукта, описанный здесь, превосходит все, что я видел в самых известных мировых компаниях, производящих технологические продукты».

После трансформации, описанной в части V, в Trainline появились квалифицированные инженеры, менеджеры по управлению продуктами и дизайнеры, а также сильное видение продукта и продуктовая стратегия. Кроме того, в компании начали замечать реальную отдачу от своих инвестиций в аналитику данных.

Trainline создала успешную и эффективную систему, которая включала определение местоположения поездов в режиме реального времени, оценку времени отправления с платформы, персонализированное оповещение о сбоях в движении и возможность найти менее заполненный вагон. Все это помогло воплотить их видение продукта.

Но один важный вопрос продолжал беспокоить их клиентов: ценообразование.

На ранней стадии продуктового исследования стало ясно, что очевидная дороговизна железнодорожных билетов мешает Trainline расширять клиентскую аудиторию. Пользователи твердили им: «Билеты такие дорогие!»

И наоборот, представители отрасли отвечали, что это неправда, в подтверждение своих слов указывая на билеты по очень низким ценам. Распутывание этой загадки могло стать очень перспективным в плане новаторства, но миллионы потенциальных железнодорожных маршрутов означали большой объем работ.

У компании, на первый взгляд, не было никаких рычагов влияния на ситуацию. Trainline получала цены в режиме реального времени в тот момент, когда пользователь выполнял поиск. Только после этого API оператора выдавал стоимость конкретной поездки.

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

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

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

В то время как индустрия во все горло рекламировала билеты по самым низким ценам, подавляющему большинству клиентов приходилось платить значительно больше. Команда не нашла никаких свидетельств сознательного управления доходностью или автоматической распродажи «в последнюю минуту». Это было важным открытием и потенциально большой победой. Теперь команда могла точно определить, насколько выгодно покупать билеты заранее на любом маршруте.

Дальше встал вопрос: можно ли придумать способ показывать эту информацию клиентам в режиме реального времени, помогая им делать более осознанный выбор и экономить деньги?

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

Будет ли решение достаточно ценным и удобным, чтобы привести к изменению поведения пользователей? Сможет ли компания корректно масштабировать его? Получится ли разработать понятный продукт, когда объемы информации огромны, а ресурсы мобильных гаджетов ограничены?

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

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

Аналитики данных, отвечающие за сбор информации, объединили усилия с командой разработчиков мобильного приложения, перейдя к работе над комплексным продуктовым исследованием.

Разобравшись в первую очередь с риском ценности, команда ювелирно разработала серию небольших решений и протестировала их в режиме реального времени на нескольких избранных маршрутах. Прототип с живыми данными получил единогласные положительные отзывы. Это была реальная экономия, и клиентам очень понравилось. Команда принялась за дело с удвоенной энергией.

В соответствии со стремлением к премиальному мобильному опыту команда решила сделать это решение уникальным для приложений Trainline. Это напрямую отражало видение компании и полностью поддерживало ее продуктовую стратегию.

Благодаря высококвалифицированной команде дизайнеров, а также интенсивным итерациям отладки и созданию пользовательских прототипов, удобство использования вряд ли представляло серьезный риск. Но оставались два других риска: осуществимость и жизнеспособность.

Критически большое значение приобретала точность информации. Проблема была сложна и основана на больших данных. Даже очень смышленая команда могла не справиться. Команда установила минимальную толерантность к риску — нельзя было ставить под удар лицензию Trainline. Работала кипела, росла способность выполнять поставленную задачу с предельной точностью, подкрепляемая эффективным масштабированием на облачных сервисах AWS.

Оставался последний существенный риск: жизнеспособность. Хотя Trainline формально не требовалось одобрение партнеров, но ни команда, ни топ-менеджмент, ни совет директоров не могли допустить публичного конфликта с железнодорожными перевозчиками, особенно перед потенциальным выходом компании на фондовую биржу.

Как минимум раскрытие стратегии ценообразования, лежащей в основе железнодорожных билетов в Великобритании, вызвало бы споры. Trainline могла доказать, что это приведет к экономии средств клиентов, но, учитывая значительную долю компании на рынке, руководители начали беспокоиться, что их решение может привести к снижению чистой прибыли для других игроков отрасли.

Требовались реальные данные, причем в больших объемах. Пришлось в значительной степени опираться на небольшую, но квалифицированную операционную команду, состоящую из людей, которые потратили годы на развитие тесных отношений со своими партнерами по промышленному бизнесу. Без них инициатива, скорее всего, была обречена на провал.

Сотрудники операционного отдела были воодушевлены, но все же нервничали. Они предложили на первых порах сосредоточиться на небольшом количестве партнеров с более прогрессивными взглядами в сфере цифровых технологий. Работа с ними была тонкой и сложной. Многие партнеры отказались, раздраженные очередным вмешательством со стороны новичка в отрасли. Но, к счастью, один согласился на живое тестирование. Наконец у команды появилась возможность спокойно запустить проект и посмотреть, какими будут реальные данные.

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

Те, кто сэкономил деньги, были в восторге. Тестирование прошло с ошеломляющим успехом, что позволило членам команды обосновать необходимость более широкого (но по-прежнему тщательно контролируемого) внедрения. Попутно компания собрала очередную порцию бесплатной рекламы в СМИ.

Релиз данного продукта напрямую отражал миссию Trainline: продвигать решения по снижению выбросов углекислого газа в атмосферу, предлагая максимально низкие цены. Кроме того, команда маркетологов получила новую шикарную возможность позиционировать Trainline как единственного новатора в этом секторе. В преддверии IPO был запущен ряд маркетинговых кампаний, которые пришлись как нельзя кстати. Теперь об инновации Trainline сообщали не только в национальных СМИ, но и в специализированных журналах по технологиям. О компании регулярно упоминали в новостях.

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

Релиз за релизом, компания достигла значительного прироста показателей — не только ради клиентов и бизнеса, но и для акционеров. Как раз вовремя — для предстоящего IPO.