Но во время бесед с клиентами выяснилось, что методы обучения не имеют к компании никакого отношения. Несмотря на то что трафик с веб-сайта был большой, пользователи проводили там совсем мало времени. Исследования команды Pluralsight доказали, что видение не сходится с реалиями. Основные клиенты — разработчики с большим опытом (от 7 до 15 лет) — хотели расширить навыки, но не на предопределенном карьерном пути. Их интересовали конкретные технологии. Они не собирались становиться инженерами клиентской стороны интерфейса, а планировали приобрести навыки, скажем, в Angular и изучать Angular 2. Так видение основывалось на претворении прототипа и обратной связи от пользователей об этом прототипе. Неожиданно оказалось, что видение требует правок.
Это пример не столько о нерабочем видении, сколько о том, как его обогащает тестирование в реальном мире. Команда продукта проверила идею на практике и выяснила, что вместо методов обучения надо запускать методы наработки навыков. Так и сделали. Они получили информацию непосредственно на рынке, и она повлияла на видение. В результате изменилась стратегия продукта, и то, что компания запустила, наконец-то приятно удивило пользователей.
Но в то же время надо всегда помнить о видении продукта и не давать сбить себя с толку новой информацией. «Люди всегда просят больше. Если слепо верить им, то можно оказаться на другом рынке. У продукта будет больше функций, он потребует больше памяти, усложнится — и может утратить изначальную ценность», — считает менеджер продукта Basecamp Райан Сингер.
Создание команды
Как мы уже убедились, идеального метода создания команды не существует. Контекст крайне важен для структуризации и найма специалистов. Успешные продакт-менеджеры всегда учитывают культуру бизнеса. При условии, что она более или менее здоровая, она способна повлиять на структуру команды. Соответствие культурному контексту — вот первый шаг в наборе или реструктуризации команды. «Думаю, самое главное для продакт-менеджера — это думать о своих людях: “Кто они?” — говорит Тим Бантел из XebiaLabs. — Менеджер продукта — это рупор клиента. В управлении продуктом это уже почти клише, но все же лучше, чтобы вам нравились люди, с которыми вы работаете». Бантел знает, что лидер продукта представляет и внешнего клиента, и внутреннего: «Вы будете отстаивать их интересы, поэтому надо поставить себя на их место и верить им».
В развивающихся компаниях уже сложившаяся команда, а лидеру продукта остается только убедиться в согласованности ее действий с целями и культурой всей организации. Команда продукта обычно занята повседневными задачами и не так часто вспоминает про общую картину, как лидер. «Надо помочь им увидеть долгосрочные приоритеты, — говорит Мэтт Асэй, вице-президент по мобильным приложениям Adobe Marketing Cloud. — Иногда все внимание получает ближайшая задача. Я помогаю своим сотрудникам смотреть вперед». Асэй уверен, что, если помочь команде увидеть долгосрочные перспективы, от этого все только выиграют: «Мне надо быть связующим звеном».
Далеко не всегда структура команды уникальна и оригинальна в каждой компании. Для упрощения задачи и ускорения процесса можно позаимствовать успешную модель у похожей организации. При необходимости структуризации команды в развитой компании не всегда есть возможность экспериментировать с моделями. «Обычно работа над продуктом включает в себя управление продуктом, опыт пользователя, анализ и обработку данных, стратегию и маркетинг продукта, — поясняет Брайан Данн из Localytics. — У нас еще есть департамент маркетинга, отличный от стандартного».
Данн описывает, как команда Localytics копировала модель отряда Spotify для быстрой структуризации: «У нас пять full-stack команд. В них не только инженеры, а еще менеджер продукта, руководитель (технический), а для работы с клиентской стороной интерфейса еще и UX-дизайнер». Общие для всех команд эксперты предоставляют консультации по конкретным техническим вопросам. Эти люди — как команда для команды. «Еще у нас есть команда по анализу и обработке данных, — продолжает Данн, — которая работает со всеми по необходимости; у некоторых команд есть возможность улучшить отдельные части продукта с помощью алгоритма машинного обучения. Им помогут создать эти алгоритмы и перейдут к работе с другой командой, которой нужны сейчас».