Типовые вопросы на собеседовании на продакт-менеджера и ответы на них

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

  • Вопросы на отсев самозванцев;
  • Вопросы на базовые компетенции.

Опросник этот, скорее на джун+ или мидл, сениорских вопросов тут не будет, найм продакта-сениора занятие нетривиальное.

Полетели.

Вопросы на отсев самозванцев 

Что такое продукт в твоем понимании? 

Что проверяем вопросом? 

Общее понимание, что такое продукт. 

Комментарии 

Что должно быть в ответе: 

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

Ответ 

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

Почему решил стать продактом? Что для тебя продакт-менеджмент? 

Что проверяем вопросом? 

Понимание профессии, мотивацию и майндсет.

Комментарии 

Будет здорово, если кандидат скажет, что хочет делать жизнь каких-то пользователей лучше, либо ему нравится продукт, которым занимается ваша компания и он хотел бы его усилить. Плохо, если он просто считает профессию современной или идёт в неё ради денег — быстро выгорит.

Ответ 

Всегда думаю как сделать продукт/опыт лучше. Люблю интуитивно понятные интерфейсы и получаю кайф, когда удается создать такой опыт! Продукт лежит в основе бизнеса. Продавцы и маркетологи могут красиво продать продукт, в котором пользователь потом разочаруется. Менеджер продукта обязан сделать продукт, который будет решать задачи пользователей. Такой продукт и продвигать легче, и презентовать не стыдно.

Чем продакт отличается от проджекта? 

Что проверяем вопросом? 

Понимание задач продакта.

Комментарии 

Соискатель должен понимать главную вещь — прожект отвечает на вопрос: «как», а продакт: «что» и, что куда более важно: «зачем». Соискатель должен понимать, что должен не просто пилить задачи, а трезво оценивать, нужны ли они продукту. Совсем хорошо, если скажет, что продакт должен оперировать метриками и согласовывать свои решения со стратегическими целями компании.

Ответ 

Задача проджекта – в согласованные с заказчиком сроки и с доступными ресурсами качественно решить поставленную перед ним задачу. Проджект не оспаривает саму задачу. 

Задача продакта – понять, какую потребность пользователей необходимо решить. Есть ли такая потребность? На какие метрики это повлияет? Какую пользу принесет бизнесу? Продакт работает с идеями по улучшению опыта пользователей, в том числе с идеями от стейкхолдеров продукта, также работает с обратной связью от пользователей продукта. Он исследует проблемы, подтверждает их или аргументировано опровергает, ищет наиболее эффективные решения. В случае, если гипотеза стейкхолдеров неверна, продакт предлагает альтернативное, более эффективное решение.

Опиши свой опыт работы над продуктом. Кто были юзеры? Какие проблемы решали? Какие метрики смотрели? Каких бизнес-результатов добились? 

Что проверяем вопросом? 

Понимание продукта, его аудитории и метрик.

Комментарии 

В основном, тут видим презентационные навыки кандидата, умеет ли он рассказывать о назначении продукта, целевой аудитории, метриках.

Тут ответ у каждого будет свой, но приведем пример, на который можно опираться.

Ответ 

Я развивал категорию спортивных товаров на Яндекс Маркете. Мы ориентировались на спортсменов-любителей и на тех, кто хочет заняться спортом. Такие пользователи плохо разбираются в сложном спортивном инвентаре, поэтому мы всячески помогали им с выбором товара: делали подборки, обогащали карточки товаров необходимыми параметрами, добавляли рекомендательный контент. Отслеживали, как наши продуктовые изменения влияют на конверсию в заказ. Например, мы создали подборщик товаров, который, задавал пользователям 3-4 простых вопроса и, исходя из ответов, формировал выдачу с подходящими товарами. У пользователей, прошедших через подборщик, конверсия в заказ была на Х % выше, чем у других пользователей категории (сорри – NDA, не могу разглашать, но цифры были крутые).

Какая целевая метрика была у твоего продукта? Как ее качали? Какие бывают метрики? 

Что проверяем вопросом? 

Умение работать с метриками — базовая штука для продакта, он должен очень хорошо в них разбираться, понимать, как они влияют друг на друга.

Комментарии 

Если продакт не знает, с какими метриками работал, интервью можно не продолжать. В идеале, услышать про целевые, прокси, контр, качественные и количественные метрики.

Ответ 

В моем предыдущем продукте целевой метрикой был GMV. Эту метрику можно качать либо при помощи увеличения AOV, либо за счет увеличения количества заказов. Мы решили растить количество заказов через улучшение базового пользовательского опыта и увеличения Conversion Rate (CR) в заказ, потому что у нас была молодая категория и, прежде чем растить средний чек, нужно построить хороший опыт покупки, которого нам не хватало. Кроме того, делать ставку на рост среднего чека в условиях кризиса, казалось сомнительной инициативой. Качали CR в заказ через обогащение описания товаров параметрами, важными для выбора, добавление новых инструментов выбора и сравнения товаров. То есть, делали изменения в продукте, которые упрощали выбор и увеличивали конверсию в заказ. 

Есть целевая метрика или North Star. 

Она декомпозируется на прокси-метрики. Это метрики, которые влияют на вышестоящую метрику в дереве метрик. В случае с GMV – это количество заказов и средний чек. Они, в свою очередь, раскладываются на другие прокси-метрики. 

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

Качественные метрики позволяют оценивать уровень качества сервиса, но за счет их роста тяжело обеспечить непрерывный рост бизнеса. Например % заполненности параметров у объявлений. Как ни старайся – выше 100 % не будет. 

Количественные метрики – это те, за счет которых обеспечивается рост. Например, количество заказов, как в примере выше.

Вопросы на базовые компетенции 

Заказчик пришел к тебе с двумя фичами: фильтр «Страна производства» и фильтр «Скорость доставки». Первый фильтр горячо продвигает один из топ менеджеров компании, потому что он покупает товары, произведенные только в определенных странах. Как оцениваешь эти инициативы? Какую будешь делать первой? 

Что проверяем вопросом? 

Критическое мышление и навык оценки идей.

Комментарии 

Это довольно частый вопрос, на который нет единого правильного ответа. Интервьюер проверяет им навыки анализа идей и правильной приоритизации.

Хотим посмотреть критическое мышление и умение задавать правильные вопросы: Кто ЦА? Какая боль? Как повлияет на бизнес? Какие сигналы? 

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

Вопрос с подвохом, на самом деле. Многие неопытные продакты, услышав, что фичу педалирует кто-то из руководства, кидаются её тут же делать. Это неправильно.

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

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

Ответ 

Фильтр «Страна производства» кажется логичной фичей, так как у пользователей, действительно, есть убеждение, что у китайских товаров низкое качество, но это релевантно не для всех товарных категорий. Например iPhone и Яндекс Станция тоже собираются в Китае. Важно понять есть ли у нас сигналы от пользователей про эту идею? Почему пользователям важно знать, в какой стране произведён товар? Много ли таких пользователей в нашем продукте? Для какой категории товаров мы хотим реализовать эту фичу? Какую метрику мы надеемся прокачать этой фичей? Действительно ли фича так же важна для бизнеса, как она важна для конкретного менеджера в компании? 

Вторая фича тоже не противоречит здравому смыслу, но стоит разобраться, а действительно ли есть, из чего выбирать? Так ли сильно отличаются сроки доставки у разных товаров в категории? Так ли важно нашим покупателям получить товар к конкретному сроку? Сколько таких покупателей? Есть ли такой фильтр у прямых конкурентов?

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

Следующий шаг – анализ трудозатрат на реализацию фичей. Если у наших товаров в каталоге изначально не было параметра «Страна производства», то добавить параметр в систему управления товарной информацией, а потом для всех товаров в продаже единоразово указать достоверное значение параметра, и в дальнейшем поддерживать значения у новых товаров может оказаться неподъемной задачей для компании в силу текущих бизнес процессов. В то же время, сроки доставки для каждого товара мы знаем «из коробки» и тут очевидно, что вторая фича сильно дешевле в реализации. Я бы сначала реализовал фильтр «Сроки доставки» и принес компании пользу в более короткие сроки с меньшими трудозатратами. 

Сформулируй гипотезу выбранной идеи. Как будешь проверять гипотезу? 

Что проверяем вопросом? 

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

Возможные способы проверки гипотез, которые должны быть озвучены:

  • Качественное исследование,
  • Количественное исследование,
  • АВ-тест или постепенная раскатка.

Опять же, вопрос открытый. На собеседовании могут дать любой кейс. Предлагаем подход к ответу на примере своего кейса. 

Ответ 

Допустим, из предложенных инициатив мы решили сделать фильтр «Срок доставки». 

Гипотеза: 

В маркетплейсе миллионы товаров и эти товары имеют разные сроки доставки в очень широком диапазоне – от 15 минут до нескольких недель. Если мы предложим пользователям опцию выбора товаров по «Сроку доставки», то пользователи смогут быстрее выбрать нужный товар, отсеяв те, чьи сроки не совпадают с ожиданиями. За счёт ускорения выбора и прозрачности сроков получения товаров, должна вырасти конверсия в заказ и, как следствие – число заказов, что в свою очередь увеличит GMV. Так как гипотезу выбрали на основе качественных сигналов от пользователей, то будем считать, что качественник уже провели. Знаю, что фильтрами пользуются около 10 % пользователей и допустим, что 50 % пользователей фильтров будут уточнять срок доставки товаров, соответственно, наша аудитория – это 5 % пользователей категории. По предыдущему опыту знаю, что у пользователей фильтров конверсия в заказ на 13 % выше. Допустим текущая конверсия в заказ 2 %.

Детали расчёта

Получается, что без фичи с 1 млн. пользователей в день получим 20 тыс. заказов. 

С фичей у 50 тыс. пользователей конверсия будет на 13 % выше, т.е. не 2 %, а 2,26 %

50 000 * 0,0226 = 1 130 заказов

у остальных 950 тыс. пользователей расчет будет прежним: 950 000 * 0,02 = 19 000 

Вместе 19 000 + 1 130 = 20 130 заказов против 20 000 заказов. 

Аплифт = 20 130 / 20 000 — 1 = 0,65 % или 130 новых заказов в день или 3 900 новых заказов в месяц.

Оценку получили. Ее можем использовать для планирования AБ-теста. Практика показывает, что результаты АБ-теста могут сильно отличаться от предварительных оценок, причем как в лучшую, так и в худшую сторону. 

Какие методы качественных исследований знаешь? Какие вопросы задашь? 

Что проверяем вопросом? 

Некоторые продакты чрезмерно полагаются на аналитику и упускают качественные исследования. Но современный продакт должен уметь проводить интервью и задавать правильные вопросы.

Комментарии 

Достаточно рассказать про базовые методы, которые продакты чаще всего используют в работе: глубинные интервью, SbS, коридорки, UX-тесты. 

Ответ 

В своей практике я применял 4 метода качественных исследований: 

  • глубинные интервью;
  • коридорные тесты;
  • SbS;
  • UX-тесты.

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

В глубинных интервью важно спрашивать открытые вопросы и не задавать вопросы в лоб из серии: «Мы придумали такую-то идею, как она вам?» Люди склонны давать социально ожидаемые ответы. Большинство скажет, что им нравится, но это не будет соответствовать действительности. 

Вместо этого нужно задавать вопросы про проблему пользователей: Как часто она возникает? Насколько сильно болит? Когда проблема возникала в последний раз? Как решали? Сколько времени и денег потратили на решение? Что будет, если проблему не решить? И исходя из ответов составлять представление о том, поможет ли твой продукт решить проблему пользователя.

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

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

SbS — для того, чтобы сравнить 2 конкурирующих решения в интерфейсе. 

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

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

Тут важно поставить пользователю задачу, а дальше наблюдать: как он будет ее решать, сколько времени займет решение, будет ли сталкиваться с трудностями во время решения.

Какие методы количественной валидации знаешь? 

Что проверяем вопросом? 

Здесь без подвоха, проверяем знание методов валидации.

Комментарии 

Достаточно рассказать про базовые и про особенности их применения. 

Ответ 

Конечно, в первую очередь – это АБ-тест. Это самый надежный и точный инструмент. 

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

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

Также мы можем использовать опрос, когда у нас есть конкретные варианты ответов. Например, какой нейминг использовать для нового фильтра: «Цель сделки» или «Вид сделки». 

У тебя есть 20 идей развития продукта. Как построишь работу над этими идеями? Какие фреймворки приоритизации знаешь? 

Что проверяем вопросом? 

Продакт должен постоянно давать команде приоритеты, проверяем, умеет ли он это.

Комментарии 

Хотим услышать, что продакт знает на какие вопросы стоит обратить внимание при приоритизации, а также, что он уверенно владеет RICE или Moscow и может использовать какие-то кастомные механики.

Ответ 

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

Далее можем прогнать оставшиеся идеи через следующие вопросы:

  • Есть ли среди них блокеры для других важных инициатив?
  • Какие из них имеют наибольшее влияние на ключевую метрику?
  • Какие из них самые дорогие в реализации?

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

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

Но сразу в RICE упарываться не стоит, так как это трудозатратно. Через него можно прогнать только самые жирные идеи, которые конкурируют между собой. При необходимости, RICE можно тюнить и добавлять в него новые множители, типа PR эффекта, ожиданий заказчиков и т.д. 

Как будешь запускать инициативу? 

Что проверяем вопросом? 

Проверяем навыки планирования и организации работы команды. Хотя, это больше уже к прожекту. Но прожект в компании есть не всегда.

Комментарии 

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

Ответ 

В первую очередь, выясню есть ли какие-то жёсткие дедлайны, например старт рекламной кампании на ТВ? 

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

После посмотрю, есть ли конфликты с другими продуктами и какие зависимости от смежников имеются? Например: поиск, модерация, машинное обучение и т.д. Узнаю у коллег про их загруженность. Возможно, придется десантировать к ним свою команду разработки, а значит у нас останется меньше ресурса. 

Также, узнаю про загруженность коллег, которые будут принимать участие в исследовании: дизайн, исследователи, аналитики. Возможно, к каким-то задачам придется подключаться самому, например – провести интервью. Это тоже сократит ресурс.

Далее узнаю к команды разработки сколько примерно времени нужно, чтобы разработать решение? 

Далее положу оценки от всех коллег на роадмап и посмотрю попадаем ли мы в дедлайн? Какие процессы можно запараллелить? Какие есть риски? Как эти риски можно отработать? Нужно ли просить дополнительные ресурсы уже сейчас? 

Что будешь делать непосредственно перед релизом и сразу после него? 

Что проверяем вопросом? 

Навыки контроля за качеством продукта и понимание необходимости информирования коллег. Это уже больше к главе QA, но продакт должен знать основы.

Комментарии 

Хотим услышать чек-лист задач, которые продакт выполнит перед запуском и сразу после него. Что кандидат понимает, что его продукт может влиять на другие продукты и что коллеги должны быть в курсе. Что умеет проявлять оунерство над продуктом. 

Ответ 

Оценю на кого может повлиять запуск моего продукта? Например, если что-то пойдет не так, то может вырасти число обращений в поддержку. Чтобы поддержка оказала качественную помощь пользователям, они должны быть в курсе запуска и знать, какие вопросы могут возникнуть и как на них отвечать. Таких коллег стоит предупредить заранее — как минимум, за пару недель до релиза, чтобы они успели подготовиться к запуску. 

Как только продукт будет готов, сяду смотреть его на стейдже вместе с разработчиком и тестировщиком, чтобы убедиться, что продукт работает как надо и что мы ничего не упустили. 

Напишу уведомление об ожидаемой дате релиза. 

Сразу после релиза протестирую продукт, чтобы убедиться, что он работает как надо. 

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

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

Заказчик пришел с бредовой идеей от топ-менеджера компании, как будешь с ней работать? 

Что проверяем вопросом? 

Умение вести себя в конфликте, софты.

Комментарии 

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

Ответ 

Во-первых я спрошу какую проблему пользователей мы хотим решить такой идеей? Очень часто заказчики приходят с идеей без осознания проблемы. Такой вопрос часто опускает их на землю и заставляет отказаться от идеи. Например, как-то заказчик попросил меня сделать бейдж «Краш» и этот вопрос поставил его в тупик) 

Если заказчик стоит на своем, то спрошу какую пользу это принесет пользователям и компании? Какие метрики планируем вырастить? В зависимости от ответа приведу другие проекты, которые бьют в те же самые метрики, но которые более эффективны, а соответственно, принесут больше пользы и имеют больший приоритет. Потом скажу, что мы положим идею в бэклог и вернемся к ней, когда будут реализованы эти проекты. Например, заказчик просил меня начать развивать категорию «Дзюдо». Я спросил: Почему не футбол, который является самым популярным видом спорта? Почему не зимние виды спорта, по которым сейчас сезон и скоро будет Олимпиада и где средний чек гораздо выше за счет большого количества защитного инвентаря? 

Если продолжит настаивать, то вернусь к проблеме и вместе посмотрю а является ли предлагаемая идея самым эффективным решением проблемы? Может есть альтернативные решения, которые дешевле или будут иметь бОльший эффект? Далее скажу, что возьму этот вопрос в исследование и обозначу сроки исследования.

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

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


Опубликовано

в

от

Подпишитесь на новые посты, чтобы не пропускать их (РКН о сборе имейлов уведомлён должным образом):

Добавить комментарий

Предыдущий пост
Как гарантированно задизморалить сотрудников, будучи менеджером. Каждый пункт выстрадан работой…