Привет! Меня зовут Ксюша Соколова, я продакт менеджер в Точка Банк и занимаюсь развитием AI-Ассистента для бухгалтеров. 

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

Дисклеймер: 

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

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

Я верю, что материал будет применим и к другим компаниям! Пусть эта статья станет вашей шпаргалкой по подготовке к hard-skills интервью (и, конечно, почитал сам –  покажи другому!).

Немного вводных о том, как выглядит хардовый собес в Точке:

1. 5-10 мин кандидат рассказывает о своем продуктовом опыте (aka визитка)

2. Далее собеседующий задает уточняющие вопросы по зоне ответственности, метрикам, работе с командой

3. Далее решаем 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+?