Должен признать, я вообще против тестовых заданий для управленческого персонала. Особенно для продактов. Причин тому несколько
1) Решенное тестовое вам ничего о специалисте не скажет
2) Его может решить за него кто-то другой и рассказать ему как обосновать решение
3) Если задание делается быстро - оно делается на отвалите.
4) Если оно делается долго - оно должно оплачиваться.
5) Если оно делается долго и не приносит при этом ценности нанимателю, то это провал вдвойне. Это и ничего не покажет и не даст ценности, и платить не за что, а все кандидаты кроме одного потеряют свое время и силы. А наниматель потеряет еще и все это время вместе взятое.
И тем не менее, мы живем в очень странном мире, где рекрутеры изобретают все более изощренные методы отсева персонала и думают, что тестовые - это панацея. (Спойлер - нет) И есть ряд способов проверить некоторые навыки менеджера при помощи тестовых, однако нужно придерживаться некоторых правил.
1) Оно должно быть коротким. Да, оно будет сделано на отвалите, но в данном случае мы хотим проверить то как человек мыслит, а не загрузить его бесплатной бесполезной работой
2) Не просите составить роадмеп или вижн продукта. Эти вещи можно делать только при очень детальном погружении, в противном случае это будет просто файлик в ворде с буковками и табличечка в экселе с прямоугольничками, закрашенными разными цветами. Планировать роадмеп без хотя бы верхнеуровневых эстимейтов и знания особенностей вашей разработки - это все равно что гадать на кофейной гуще
3) Также, не стоит просить человека описывать метрики, прогноз их роста и P&L. Это кажется логичным, но нет. У каждого продукта метрики свои и P&L свой. В крайнем случае можете попросить составить P&L для его собственного продукта (пускай шизофренического, но своего), чтобы и NDA не нарушать чужие, и вам чушь не нести. Потому что вы то знаете все про свой продукт и будете оценивать его работу со своей колокольни. А он то точно не знает что у вас и как. Вы рискуете сделать неверные выводы
4) Не надо стараться одним тестовым понять уровень сениор / миддл / джуниор. Эти трое проверяются разными методами, потому что они для разных задач предназначены.
Что стоит спросить на тестовом
1) Дать гипотезу, попросить составить вопросы к интервью
2) Дать на вход проблему, попросить придумать продуктовое решение
3) На это решение попросить прописать требования к продукту. Лучше даже дать какое-нибудь коротенькое решение и попросить прописать требования. Потом отдать разработке, и спросить поняли ли они что нужно делать.
Только главное не говорить откуда взяли
4) Дать продуктовое решение и попросить придумать способ монетизации. Это как бонус, потому что опять же, чтобы так мочь делать, нужно поработать в компании
Эти 4 пункта дадут вам представление о том как человек будет решать свои задачи.
Бонусом.
Что забыл сказать в прошлой статье. Про ошибки при найме. Почему-то, в любой компании, когда нанимают продакта, ему изначально дается огромный кард бланш на все, огромный кредит доверия и просто космические ожидания. На мой взгляд, это может смутить людей - раз, и привести к плачевным результатам для компании - два. Продакт, да и любой менеджер, каким бы "крутым и классным" он не был, каким бы "гуру и ниндзя" он себя не позиционировал...Должен отработать в компании, погружаясь во все бизнес процессы хотя бы пол года, чтобы начать принимать серьезные стратегические решения. Такие вещи как вижн, роадмеп на год, цели на квартал даже, приоритеты и квоты ресурсов разработки по месяцам - могут делать только люди, которые очень хорошо понимают весь бизнес компании и взаимосвязи его подсистем. В противном случае - это будет полная херня. Да, опытные люди вовлекаются быстрее, но не бесконечно быстро :)