Редакция "Нетологии" перевела текстКена Нортона - главного специалиста по продуктам в Google Ventures. Он рассказал о том, что нужно делать первый месяц в должности менеджера по продукту.
Хорошо, когда продукт находит своего менеджера. Неважно, присоединились ли вы к стартапу из пяти человек или взяли на себя развитие продукта в большой корпорации. Будущий успех напрямую зависит от того, что вы будете делать первые несколько недель. Вот десять советов о том, какие шаги предпринимать.
Поймите, чего от вас ждут
Часто продуктологов нанимают только для того, чтобы заделать дыру в структуре управления продуктом. Руководство будет ждать от менеджера серьезных результатов чуть ли не в первый день работы.
Неправильные ожидания - плохо. Поэтому опытный продуктолог начинает свой путь с основательных переговоров с руководством. Предмет разговора - фронт задач на первый месяц работы. Цель - сделать так, чтобы у начальства не осталось неправильных ожиданий. Важно не взять на себя слишком много: приоритет первых нескольких недель - влиться в команду.
Узнайте как можно больше
Назначьте разговор тет-а-тет с каждым, кто имеет отношение к продукту. В зависимости от величины компании это отнимет или пару часов, или все 30 дней. Так или иначе, нужно найти время для каждого.
Хороший формат для таких встреч - пешие прогулки. Во-первых, ходьба поможет сфокусироваться на рассказе и остаться в бодром настроении после встречи. Во-вторых, иначе расставляются акценты с точки зрения переговоров (собеседники вместе смотрят вперед, а не сидят друг напротив друга).
Поймите, как помочь каждому
Опытный менеджер по продукту начинает с простого вопроса: "Как я могу упростить тебе жизнь?". С этим вопросом он приходит к каждому члену команды. Персонально.
Это важный момент: вы пришли помогать, а не командовать. Анализируйте ответы коллег. Во-первых, вы увидите одни и те же проблемы с разных позиций. Во-вторых, вы узнаете, как люди вокруг понимают роль менеджера по продукту (и чего ждут от него). Правильные ожидания коллег так же важны, как и в случае с начальством. Формируйте их.
Возьмите ответственность
Перед переговорами с коллегой поставьте себе четкую цель - незамедлительно взять в работу одну его задачу. Здорово, если в результате освежающей прогулки он не только поймет, что вы умеете слушать, но и избавится от головной боли хотя бы по одному вопросу.
Принятая задача не обязана быть сложной, важен сам факт оказания помощи и получения новых знаний о процессе. Отсортируйте баги для технолога или помогите копирайтеру с улучшением текста рассылки. Покажите, что вы готовы брать ответственность и исполнять обещания.
Погрузитесь в техническую архитектуру
Назначьте встречу с техническим директором, чтобы увидеть, как выглядит продукт в мире программистов. Важно погрузиться в его архитектуру как можно глубже - отсутствие детальных знаний помешает в будущем.
Не бойтесь задавать глупые вопросы и обязательно углубляйтесь в те вещи, в которых ничего не понятно. Часто продуктовые менеджеры пытаются произвести на программистов ненужное впечатление своей технической подкованностью. Опытного инженера впечатлит скорее тот, кто честно признается, что ничего не смыслит, и задаст много вопросов.
Не меняйте все и сразу
Сопротивляйтесь тому, чтобы внедрять изменения с наскока. Желание расширить функции продукта или скорректировать процесс разработки точно возникнет - не сомневайтесь. Но не спешите.
Подождите, пока идеи дозреют, а знания уложатся в голове. Вы сформулируете задачу лучше, когда заработаете доверие и вникнете во все тонкости. Поступательное и аккуратное движение к изменениям снова поможет коллегам увидеть в вас отличного слушателя.
Поймите, как люди пользуются продуктом
За первые пару недель вам следует разобраться с тем, как пользователи взаимодействуют с продуктом. Используйте все возможные каналы: послушайте разговоры отдела продаж, поучаствуйте во встрече с клиентом, обработайте пару тикетов в службе технической поддержки, задайте вопросы пользователям, которые оставляли отзывы на форумах или в Twitter.
Исправьте что-нибудь
Если у вас есть реальная техническая экспертиза, попробуйте самостоятельно исправить баг или выкатить крохотную фичу. Это поможет лучше понять, как организован процесс разработки.
Берите небольшой проект - такой, который будет вам по плечам. Если зароетесь, попросите помощи у команды и проследите, как и на что она расходует время. Так вы поймете, как построено взаимодействие и на что обращать внимание при постановке задач в будущем.
Добудьте все документы
Внимательно изучите все, до чего дотянутся руки, - спецификации, проектировочные документы, статьи на внутреннем вики-движке, таблицы с расписаниями работ, непринятые макеты. Не пренебрегайте морально устаревшими документами - в них зачастую хранятся важные детали.
Постройте свою собственную энциклопедию продукта и занесите в нее все файлы в хронологическом порядке. Когда изучите все, напишите краткую историю того, как рос и развивался продукт. Скорее всего, понимание, что делать дальше, появится у вас само собой.
Постройте рабочую среду
Подготовьте все инструменты, которые помогут выдавать нужный результат. Комфортная рабочая среда формируется из деталей: установите нужный софт, подпишитесь на профильные блоги, прочитайте отложенные тексты отраслевых экспертов, настройте почтовые фильтры, включите мониторинг по упоминаниям названия продукта - одним словом, постройте экосистему, которая сделает вас эффективнее. Лучше заранее воспринять создание среды как единый проект. Закройте его в первые пару недель работы - потом будет не до этого.
P. S. Чтобы больше узнать об управлении проектами, записывайтесь на онлайн-интенсив "Менеджер интернет-проекта".