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

Согласно видению основателя компании Аарона Сконнарда, клиенты (в компании их называют «учащиеся») выиграют от нового способа использования веб-приложения. Он предположил, что эффективность возрастет, если вместо приобретения конкретных навыков они будут участвовать в путях обучения. Они во многом схожи с карьерным путем. Эта идея родилась из наблюдений за тем, как путь обучения соотносился с темами на корпоративном блоге. За последние пять лет в Pluralsight возникло более сотни методов обучения, и все они брали начало из тем блога, получивших высокий трафик. Казалось очевидным, что идея уже завоевала доверие. Сконнард был уверен, что популярность этих методов обучения указывает на новое видение, следовательно, надо ввести их в веб-приложение. Для тестирования видения команда продукта разработала макет новой версии приложения в соответствии с идеями Сконнарда.

Но во время бесед с клиентами выяснилось, что методы обучения не имеют к компании никакого отношения. Несмотря на то что трафик с веб-сайта был большой, пользователи проводили там совсем мало времени. Исследования команды Pluralsight доказали, что видение не сходится с реалиями. Основные клиенты — разработчики с большим опытом (от 7 до 15 лет) — хотели расширить навыки, но не на предопределенном карьерном пути. Их интересовали конкретные технологии. Они не собирались становиться инженерами клиентской стороны интерфейса, а планировали приобрести навыки, скажем, в Angular и изучать Angular 2. Так видение основывалось на претворении прототипа и обратной связи от пользователей об этом прототипе. Неожиданно оказалось, что видение требует правок.

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

Но в то же время надо всегда помнить о видении продукта и не давать сбить себя с толку новой информацией. «Люди всегда просят больше. Если слепо верить им, то можно оказаться на другом рынке. У продукта будет больше функций, он потребует больше памяти, усложнится — и может утратить изначальную ценность», — считает менеджер продукта Basecamp Райан Сингер.

Как мы уже убедились, идеального метода создания команды не существует. Контекст крайне важен для структуризации и найма специалистов. Успешные продакт-менеджеры всегда учитывают культуру бизнеса. При условии, что она более или менее здоровая, она способна повлиять на структуру команды. Соответствие культурному контексту — вот первый шаг в наборе или реструктуризации команды. «Думаю, самое главное для продакт-менеджера — это думать о своих людях: “Кто они?” — говорит Тим Бантел из XebiaLabs. — Менеджер продукта — это рупор клиента. В управлении продуктом это уже почти клише, но все же лучше, чтобы вам нравились люди, с которыми вы работаете». Бантел знает, что лидер продукта представляет и внешнего клиента, и внутреннего: «Вы будете отстаивать их интересы, поэтому надо поставить себя на их место и верить им».

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

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

Данн описывает, как команда Localytics копировала модель отряда Spotify для быстрой структуризации: «У нас пять full-stack команд. В них не только инженеры, а еще менеджер продукта, руководитель (технический), а для работы с клиентской стороной интерфейса еще и UX-дизайнер». Общие для всех команд эксперты предоставляют консультации по конкретным техническим вопросам. Эти люди — как команда для команды. «Еще у нас есть команда по анализу и обработке данных, — продолжает Данн, — которая работает со всеми по необходимости; у некоторых команд есть возможность улучшить отдельные части продукта с помощью алгоритма машинного обучения. Им помогут создать эти алгоритмы и перейдут к работе с другой командой, которой нужны сейчас».

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

ПРАВИЛЬНЫЕ ЛЮДИ В КОМАНДЕ

Команда должна работать совместно, но какие в ней должны быть люди? Выяснив предпочтения компании по поводу расположения офиса (или отсутствия такового) и структуры, эту среду надо наполнить людьми. Как же это сделать? «Мы работали с двумя HR-специалистами, которые уже помогали мне найти отличных сотрудников», — рассказывает Кац. Определив стратегию найма, он приступил к ее пошаговому исполнению. Сначала надо было создать ядро команды. «Мы собрали ядро из 2–3 человек и далее отталкивались от него, — объясняет Кац. — Мы не торопились, стремясь более качественно подойти к выбору. Я старался не занижать планку». Как и другие успешные лидеры продукта, Кац выше всего ценит качества сотрудников. В быстрорастущих компаниях это невероятно сложно. От команды продукта всегда ждут выполнения поставленных задач. «Это непросто, потому что в организации 18 тысяч человек, — продолжает Кац. — У нас много проектов, мы нуждаемся в постоянном изучении опыта пользователя и возможностей продукта. Мы всегда в поиске новых сотрудников с соответствующим опытом». Но лидеру продукта следует найти компромисс между нуждами организации и высокими требованиями к новичкам.