13 вопросов для собеседования, на которые должен знать ответы каждый продакт

Кому будет полезна статья?

— Middle и junior продактам — позволит найти свои зоны роста, а также подготовиться к собеседованиям в топовые IT-компании.

— Тем, кто хочет стать менеджером продукта, но не знает какие компетенции стоит прокачать, чтобы войти в профессию.

— Нанимающим менеджерам — поможет составить требования к вакансии продакта и провести интервью.

Я работаю ведущим менеджером продукта в Авито и являюсь автором Telegram канала Product Net, где делюсь своим опытом, оказываю карьерные консультации и помогаю продактам найти работу мечты. До этого работал senior продактом в AliExpress, продактом в Яндекс Маркете и 3 года развивал собственный бизнес.

Андрей работал со мной в Яндекс Маркете в роли старшего менеджера продукта и провел больше 50 собеседований. Сейчас он работает в роли Chief Product Officer в международном AdTech стартапе GG Agency LLC.

Вместе мы составили список вопросов, на которые, по нашему мнению, должен уметь отвечать каждый middle-продакт. Такие и похожие вопросы часто задают на собеседованиях в ведущие IT компании. К вопросам мы написали желательные варианты ответов и свои комментарии. Так что статья может стать хорошей шпаргалкой для собеседования. Вопросы разбили на 2 блока:

Итак, приступим.

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

Хотим услышать от соискателя что:

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

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

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

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

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

Хотим услышать, что соискатель четко понимает разницу между проджектом и продактом. Он понимает, что задачи не надо просто выполнять, что у него есть право и обязанность критично оценивать задачи, с которыми к нему приходят заказчики. Будет круто, если подчеркнет, что даже, если заказчик неправ, то не надо просто отказывать, а нужно предлагать альтернативу, либо аргументировать, почему стоит сфокусироваться на других задачах. Совсем хорошо, если в качестве главных аргументов в диалоге с заказчиком будет использовать цифры, значения метрик, а также согласованность со стратегическими целями компании.

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

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

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

Тут хотим увидеть, что кандидат четко понимает:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фильтр “Страна производства” кажется логичной фичей, так как у пользователей, действительно, есть убеждение, что у китайских товаров низкое качество, но это релевантно не для всех товарных категорий. Например 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 - для того, чтобы сравнить 2 конкурирующих решения в интерфейсе.

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

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

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

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

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

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

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

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

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

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

Проверяем навыки и знание инструментов приоритизации.

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

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

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

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

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

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

Проверяем навыки планирования и организации работы команды.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проверяем soft-skills и умение отрабатывать конфликтные ситуации.

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

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

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

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

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

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

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

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

Мы не претендуем на истину в последней инстанции и будем признательны за ваши комментарии и конструктивный диалог!

Также подписывайтесь на блог Product Net в Telegram. Там вы найдете больше полезного контента, а также сможете получить карьерную консультацию, которая сделает вас на шаг ближе к офферу в компанию мечты 😉