19 вопросов для собеседования product-менеджера

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

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

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

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

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

Итак, поехали.

О прошлых продуктах

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

1. Над каким продуктом работали? На какой фазе рынка и фазе продукта? Что особенного было в продукте, что отличало его от конкурентов?

2. Какая сфера ответственности была лично у вас? По вашему мнению, эта сфера ответственности типовая или нетипичная?

3. Если стояли задачи по увеличению показателей, то каких конкретно? Опишите состояние ДО (на момент вашего прихода), ОЖИДАЕМОЕ (что от вас ждали) и ПОСЛЕ ФАКТИЧЕСКАЯ (что удалось сделать).

4. Что было сделано для достижения этих показателей (по порядку)? Какие инструменты реализации задействовали и какой выхлоп они давали?

5. С какие значимыми челленджами столкнулись?

О рабочем инструментарии

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

6. Какие продуктовые метрики были? Как часто по ним отчитывались и как следили за ними — был ли какой-то дашборд? Если да, то какой, как настраивали?

7. Как организовывали процесс работы от гипотезы до развития (CustDev, Data Driven)? В каких случаях стоит использовать тот или иной подход

8. Проводили ли количественные и качественные исследования (различия, применение, репрезентативность, выборки)?

9. Какими инструментами для прототипирования пользовались?

10. Какие были самые критичные проблемы, с которыми столкнулись?

О команде

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

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

11. Помогали ли набирать команду или пришли в готовую?

12. С какими лицами в основном общались в компаниях внутри и (если были) у партнеров?

13. Как выстраивали общение со cтейкхолдерами? Бывало ли такое, что мнения нескольких cтейкхолдеров противоречили друг другу? Что с этим делали?

14. Как мерили эффективность команды разработки продукта? Как выстраивал управление и взаимодействие?

О самооценке

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

15. Какая была ваша самая большая ошибка в профессиональном опыте? Какие выводы из нее сделали?

16. Что читаете/слушаете, где черпаете проф.знания? Подкасты, статьи?

17. Кто был вашим непосредственным руководителем? Что он может сказать о вас? Насколько он был «удовлетворен» как заказчик?

18. А что скажут подчиненные/команда что скажут?

19. Попробуйте оценить себя в профессиональном плане как продакта по 10-бальной шкале? Чего не хватает до 10-ти?

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

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