Говорят, что продакт-менеджер — это мини-CEO. Он несет ответственность за успех продукта и направляет силы всей команды в нужное русло.
При этом продакт напрямую не руководит разработчиками, дизайнерами или тестировщиками. Это делают другие люди: нанимают, увольняют, ставят оценки на ревью, выписывают премии. Проще говоря, пользуются главными рычагами воздействия.
Что остается продактам? Вовлекать коллег с помощью софт-скиллов и лидерских качеств.
Люди не станут выкладываться на 100%, если задача их не заинтересует. Это правило работает даже с прямыми подчиненными. Чтобы вовлечь сотрудника в работу, нужно понимать мотивацию — что его драйвит.
Например, вашему разработчику всегда хотелось в одиночку сделать сложное решение, поработать с большой нагрузкой. Если в ходе создания новой фичи он может это попробовать — расскажите об этом.
Важно общаться с командой и узнавать о желаниях людей постоянно, а не в тот момент, когда вам что-то нужно. Поэтому разговаривайте с ними не только на рабочие темы. Я сама часто делюсь тем, что мне интересно внутри и вне компании. Это создает безопасную среду, в которой люди охотнее раскрываются и проявляют свои таланты.
Не все желания могут быть удовлетворены, поэтому важно при найме обращать внимание на мотивацию и искать людей со схожими ценностями.
Во всех компаниях, где я работала, мы приглашали людей, которым в целом интересен наш продукт, интересно улучшать жизнь пользователя. Это помогает работать на общие цели. Несмотря на то, что продакт не нанимает разработчиков, он всё же может пообщаться с человеком до того, как тот придёт в его команду.
Продакт-менеджер — это коммуникатор. Он должен не просто ставить задачу, но и объяснить, откуда она взялась. Поделитесь с командой всей информацией от топ-менеджмента и настройте процесс регулярной передачи этого контекста. Так у людей будет достаточно сведений, чтобы принимать решения на своём уровне.
Представьте, что вы просите разработчиков сделать какую-то тривиальную задачу. Например, создать новую кнопку на сайте. Объясните, что она нужна для проверки гипотезы и проведения эксперимента, в результате которого вы получите важное для бизнеса знание и потенциальную прибыль в будущем.
К контексту нужно возвращаться и после завершения задачи. То есть объяснить людям, как их работа повлияла на результат.
«За последние 5-6 лет разработчики сильно выросли в продуктовом мышлении. Ещё недавно было много технарей, которые не понимали, почему мы проводим очередной эксперимент, когда могли бы внедрить новую технологию. Сегодня продакты могут говорить на одном языке с разработкой».
От общего тона коммуникации многое зависит. Важно помнить, что продакт-менеджер такой же индивидуальный контрибьютор, как разработчик или дизайнер, до тех пор, пока не становится лидом и не получает прямых подчиненных.
Вовлекайте команду в обсуждение продуктовых решений, давайте возможность высказаться и внести свой вклад. Не все идеи будут приняты, но это позитивно повлияет на мотивацию.
Конечно, как продакт-менеджер вы оставляете финальное решение за собой, но всегда лучше пояснить — почему оно именно такое.
Я провожу встречи по стратегии каждый месяц. В этом нет ничего нового — все продакты их проводят, делают красивые презентации, готовятся. Проблема в том, что остальные приходят просто послушать. Для них это очередной созвон, параллельно с которым можно доделать какие-то задачи или полистать ленту соцсетей.
Чтобы вовлечь людей, я приношу на встречи опросники. Например, мы хотим заняться жалобами клиентов. Даю каждому список этих жалоб и прошу проранжировать их по важности — с чем боремся в первую очередь, а что откладываем на потом. Сотрудники вникают, ставят себя на место пользователя. Обсуждать становится проще.
Этот лайфхак помогает справиться с пофигизмом разработчиков. Представьте, что вы спроектировали важную фичу: собрали прототип, протестировали, исправили недочёты. Вы уверены, что получилось классно и хотите скорее выкатить результат клиентам.
Отдаёте в разработку, ждёте несколько спринтов и наконец получаете долгожданную сборку. Вы открываете её и понимаете — один из важных кейсов работает совсем не так, как хотелсь бы. И никто этого не исправил.
Чтобы разработчик задумывался о том, как конкретный кусок кода решает проблему пользователя, ему нужно увидеть эту проблему. Поэтому мы заменили бэклог задач на бэклог проблем и поменяли сами формулировки:
Было: пожалуйста, сделай так.
Стало: помоги решить эту проблему.
Теперь разработчики возвращают фичи на доработку, если находят недостатки в UX-решениях. Например, увидели, что расчет комиссии при переводе занимает много времени, а это совсем не покрыто дизайном.
Бэклог проблем будет работать лучше, если вы свяжете его с долгосрочным видением. Мы для этого используем Miro — там склеиваем воедино задачи на квартал, год и пять лет. Доска позволяет проследить весь путь от маленькой проблемы к глобальным целям.
Случайные встречи один на один провоцируют общение, которого не хватает на удалёнке. На Random Coffee необязательно говорить о работе. Можно обсуждать футбольные матчи или любимые рецепты для завтрака. Польза в том, что сотрудники общаются, выстраивают эмоциональную связь. Как следствие — они становятся смелее на общих созвонах.
В ИТ работают специалисты, выросшие в культуре поиска правильного ответа (решить уравнение или задачу). Миссия продуктового лидера склеивать таких людей. Свою работу дальше они сделают сами.
Чтобы встречи вызывали интерес, включите в игру руководителей высокого уровня. Это замотивирует людей, у них появится любопытство, желание задавать вопросы.
При этом сами руководители тоже хотят знать, чем живут сотрудники, что их волнует и вдохновляет. Эти ответы они не всегда могут получить от менеджеров среднего звена.
Если люди теряются, помогите им с темами. Например, соберите рандомные вопросы, с которых можно начать разговор. В Райффайзенбанке команды, которые проводят Random Coffee, показали прирост в скорости на 7-10%.
Большинство конфликтов происходят из-за того, что люди не понимают, зачем нужно то или иное решение. Так случается, если вы привлекаете сотрудников, когда сами уже всё придумали и запланировали.
В хорошей команде разработчики, аналитики и тестировщики — партнёры продакта. Если они погружены в бизнес, то приносят решения, о которых вы сами даже не подумали бы.
Поэтому важно поддерживать постоянную вовлеченность коллег. Мы регулярно проводим для этого встречи с тимлидами, квартальные и годовые кик-оффы со всей командой, а также лекции про бизнес — на них я рассказываю, почему компания выбрала именно такую стратегию и метрики для оценки результатов.
Чтобы лучше вовлечь сотрудников, я отправляю их поработать «в поля», то есть ближе к пользователю. Например, разработчик, который делает что-то для техподдержки, может провести пару часов в саппорте. Так он своими глазами увидит, что именно нужно исправить.
Эта практика обязательна для всех тимлидов и тестировщиков в моей команде. Для остальных — по желанию. Мало кто отказывается, так как ребятам важно понимать, чью жизнь они улучшают своей работой. Или ухудшают в случае неудачного релиза.
Иногда на горизонтальном планировании мы не сходимся во взглядах. И это нормально, так мы обмениваемся мнениями. Плохо, если коллеги не задают вопросов и не делают встречных предложений. Это значит, что они не думают самостоятельно.
Поэтому поощряйте дискуссию и давайте сотрудникам возможность по-хорошему челленджить ваши решения. Если они смогут доказать на цифрах, что нашли другую точку роста — выиграет вся команда.
