Привет! Меня зовут Ксюша Соколова, я продакт менеджер в Точка Банк и занимаюсь развитием AI-Ассистента для бухгалтеров.
Эта статья родилась из личной боли: я регулярно провожу хардовые собесы продактов уровня миддл, и, к сожалению, регулярно приходится отказывать неплохим ребятам, которые, однако, совершают одни и те же ошибки, из-за которых мы не можем их оценить на заявленный грейд и пропустить дальше на знакомство с командой.
Дисклеймер:
Я буду рассуждать исключительно по фрейму найма в Точке, исходя из наших ценностей продуктовой разработки
Наши ценности – не секрет, и каждый кандидат, кто получил отказ, получает развернутую обратную связь насчет того, чего нам не хватило и на что обратить внимание для успешного прохождения собеседования в следующий раз.
Я верю, что материал будет применим и к другим компаниям! Пусть эта статья станет вашей шпаргалкой по подготовке к hard-skills интервью (и, конечно, почитал сам – покажи другому!).
Немного вводных о том, как выглядит хардовый собес в Точке:
5-10 мин кандидат рассказывает о своем продуктовом опыте (aka визитка)
Далее собеседующий задает уточняющие вопросы по зоне ответственности, метрикам, работе с командой
Далее решаем 1-2 кейса (бывает и больше, но это по ситуации)
Обычно все это занимает час-полтора.
Итак, коллеги, от сердца отрываю секретные материалы: перед вами мой личный топ-9 грубых ошибок, которые совершают практически все продакты (~80%) уровня миддл на интервью.
Ошибка #1: напрочь отсутствует структура сторителлинга о своем опыте
Часто рассказ начинается прямо с университета или первого места работы, кандидат пытается рассказать всю свою жизнь, вместо проведения собеседующего по наиболее значимому продуктовому опыту.
Отсюда вытекает проблема отсутствия структуры.
Согласитесь, можно делать одно и то же, но один расскажет, как он делал “вообще все и даже больше, чем надо было”, а другой расскажет:
какая цель/проблема была в начале
как он к ней подступился (дискавери)
откуда брал гипотезы
как ухватился не за все подряд, а за ту самую гипотезу, которая имела бóльший потенциал
как замерял результат на выходе, как отрефлексировал опыт?
Все мы работаем в неопределенности и часто хаосе, но глубину вашего опыта раскроет именно поэтапный рассказ о том, как вы это все структурировали, почему, что получилось на выходе и какие выводы из этого были сделаны.
Ошибка #2: в рассказе об опыте есть только список дел без хайлайта понятных результатов
– Мы что-то очень долго разрабатывали, исследовали, смотрели на метрики
– И что?
– …
Тут довольно очевидно, но, тем не менее, часто, очень часто кандидаты просто перечисляют свои обязанности, а не достижения. Я уверена, что менеджер должен хвалиться результатами, а не методами их достижения. Какая разница, сколько встреч проведено, сколько фреймворков выучено, если продукт/компания не стали лучше с вашим приходом?
Ошибка #3: в рассказе об опыте нет связи между целями/ключевыми метриками и гипотезами, которые проверялись
Ситуация:
– какая была твоя зона ответственности и цели по ней?
– в основном, я работал над удержанием, ну и конечно смотрел на выручку
– приведи пример классной гипотезы, как ты качал эти метрики?
– “если мы запустим рекламу на Авито, то привлечем 1000 новых пользователей
– а по ретеншену?
– а по ретеншену не успели особо проверить…
Возможно, очень возможно, что имеет место быть выдуманный опыт, но, честное слово, – каждый третий кандидат не связывает в своем рассказе (а может и в работе?), что тестирование гипотез неразрывно связано с ключевыми целями продукта. Иначе зачем копать то, что неважно?!
Ошибка #4: незнание конкурентного преимущества своего продукта
Но ведь это ключ к пониманию того, что с ним [продуктом] происходит.
Единицы продактов знают и могут четко сказать, за что пользователи выбирают их, а не конкурентов. И худшее заблуждение в этом вопросе, что “у всех такое было, и мы тоже сделали” – устойчивое конкурентное преимущество. Отсюда вытекает ключевой навык, который мы ищем в кандидатах: синтез ценности, или иными словами, знание, какую ценность несет его продукт, кто его пользователи (не соц-дем, а какие сегменты и сценарии лояльных), чем они отличаются от сценариев конкурентов, в какой области лежит потенциал "перетягивания" трафика у конкурентов?
Ошибка #5: плохое понимание инструментов или просто куча аббревиатур
Регулярно кандидаты рассказывают: “мы строили CJM, использовали MoSCoW, растили LTV, гипотезировали над CR1” и еще десятки вариантов “забыл как это по-русски”, иии..: никто из них не дает комментариев - а зачем? почему именно это? уверен, что этот фреймворк/инструмент тебе подходит?
То есть либо кандидат просто насыпал терминов, думая что чем больше - тем лучше, либо совершенно бездумно делал продукт неподходящими для него инструментами.
Отличие сильных кандидатов в том, что они всегда описывают свои метрики и специфические термины простыми словами, так что и на пальцах сразу становится понятно, что человек разобрался и действительно осознанно развивал свой продукт.
Ошибка #6: автоматизация ради автоматизации
Отдельный сегмент кандидатов, которые мне лично кажутся весьма толковыми, но бессистемными – это ребята, кто занимался переводом чего-то ручного во что-то машинное (а в т о м а т и з а ц и я).
Автоматизацию мы любим, но так получается, что ребята, кто занимается ею, презентуют свой опыт исключительно как проджектовый: “сказали делать, я сделал, потому что это очевидно, что будет лучше”.
Неочевидно.
В книге «Цель» Элияху Голдратта, хорошо раскрыта мысль, что автоматизация (в книге было про внедрение роботов) не приводит к росту прибыли, если она не повышает общий поток готовой продукции через систему.
На что обычно не могут ответить продакты после работы с автоматизацией:
что автоматизировали? (какая проблема была изначально)
как доказывали необходимость автоматизации?
как оценивали потенциальные улучшения? (на сколько улучшится/удешевится?)
любая автоматизация – это дорого, были ли какие-то пробные заходы?
за какими метриками следили?
как замеряли эффект? получили ли ожидаемый результат?
Часто ребята говорят, что задача была поставлена уже в таком виде, но мое мнение, что даже если тебе спустили задачу сверху, ничто не мешает разобраться, каковы причины этой задачи и выдвинуть разумные аргументы, как было бы лучше и безопаснее это сделать.
Ошибка #7: “это уже не моя зона ответственности”
В основном, этим грешат ребята из бигтеха: от зубов отлетают метрики, термины из p&l, гипотезы, но только в рамках своей, строго очерченной, зоны ответственности.
- Что происходит до и после твоего участка?
- - Как твои изменения повлияли на другие этапы воронки?
- - - Какие метрики у соседних сервисов, общался с их продактами?
- - - - За что пользователи выбирают ваш сервис?
– я не знаю, я отвечал только за конверсию в “далее”.
Это плохо. Но почему?
Одна из главных задач продакта – собирать контекст, чтобы трезво диагностировать проблемы и генерить глубокие, качественные гипотезы. Закрывая глаза на смежные с нашим продуктом участки, мы рискуем очень быстро исчерпать потенциал продукта.
Если кандидат отмахивается со словами “а это уже было не в моей зоне ответственности”, для меня это сигнал, что, придя в Точку, продакт уйдет в генерацию фичей, а не в создание ценности (а мы, в свою очередь, за второе и всегда стараемся влиять на смежные участки).
Ошибка #8: решение продуктового кейса без структуры и анализа ситуации
Каждый третий кандидат при решении кейса стремится сразу найти его решение, уходя в фичи. Это неправильно, ведь правильного решения по сути и нет, и вашу экспертность раскроет именно широта размышлений, широта сбора “анамнеза”;
Крепкий миддл чаще всего начинает решение кейса с шага 0 в виде вопроса “а зачем, почему могла возникнуть такая проблема?” И далее мы плавно движемся по важным вопросам, который опытный продакт должен задать себе, сталкиваясь с неизвестным.
Они [вопросы] не универсальные, но именно то, как многогранен этот спектр “важных вопросов” и способов поиска ответов на них, демонстрирует способность кандидата адаптироваться в новых условиях.
Что касается структуры, то тут, как мне кажется, более универсальный подход:
вы слушаете условие, вникаете в проблему
выделяете, к какой области продуктовой разработки относится эта проблема (синтез ценности, аналитика и метрики, гипотезы, лидерство и управление разрабокой)
применяете структуру решения, которая лучше всего подходит для этой области.
В идеале у вас должна быть заготовлена шпаргалка структуры решения под каждый вид кейса (у меня была!). Это нормально - держать ее под рукой, чтобы помочь себе быстро собраться на таком стрессовом мероприятии, как кейс-интервью.
Ошибка #9: неумение проводить пользовательские интервью
Наверное, сейчас уже считается дурным тоном не прочитать “Спроси маму”, и, конечно, не пройти курсы по пользовательским интервью. Все продакты любят писать в резюме, что проводили много исследований и принимали на их основе решения.
ОДНАКО, товарищи.
Один из моих любимых приемов на хард-интервью это буквально на 8-10 мин разыграть глубинку aka кастдев aka JTBD-интервью (выбирайте, что нравится, придираться не буду!). У нас есть условия кейса, и в ходе решения кандидат говорит, что пошел бы общаться с пользователями.
“Ага, попался” – думаю я и тут же предлагаю провести мини версию такого интервью.
От меня:
какая будет цель интервью?
какие респонденты тебе понадобятся?
какие самые важные вопросы ты мне задашь? (ответы всегда даю как реальный респ, чтобы посмотреть, как он/она ориентируется на ходу - нам это важно)
Long story short, чаще всего, в 4 из 5 раз я слышу вопросы “что бы вы хотели добавить в продукт? что вам не нравится? посоветуете его своим друзьям?”.
Хорошие ли это вопросы, оцените сами.
Вместо заключения
На этом все, спасибо, что прочли до конца! Пишите в комментариях, что думаете: строгие ли у нас в Точке ожидания от кандидатов уровня middle/middle+?
