Продуктовые кейсы на собеседовании продакт-менеджера
Зачем продакт-менеджеру кейс-интервью
Продуктовый кейс — главный этап собеса PM в любой технологической компании. Это открытый вопрос без единственного правильного ответа: «как улучшить функцию X», «метрика Y упала — план действий», «спроектируй продукт для сегмента Z». Интервьюер оценивает не финальный ответ, а ход мысли: задаёшь ли уточняющие вопросы, выстраиваешь ли структуру, думаешь ли о сегментах, видишь ли trade-off-ы.
В отличие от собеса аналитика, где есть «правильный SQL-запрос», в PM-кейсах кандидат может прийти к разным выводам — оценивают качество рассуждения. На собес продакт-менеджера такие кейсы дают на каждом сильном этапе: с нанимающим менеджером, с CPO, иногда отдельным раундом.
Четыре главных шаблона кейсов
PM-кейсы делятся на четыре типа. Все остальные — гибриды.
1. Improve feature. «Как улучшить функцию X в нашем продукте?» Самый частый. Проверяет умение глубоко погружаться в существующую механику, находить узкие места, предлагать решения с приоритизацией.
2. Design feature / product. «Спроектируй фичу для сегмента Y» или «новый продукт для рынка Z». Проверяет умение собирать пользовательские потребности, идти от проблемы к решению, формулировать гипотезы.
3. Diagnose metric drop. «Метрика упала на N%. План действий?» Проверяет аналитическое мышление, MECE-декомпозицию, приоритизацию проверок. Подробнее — в кейсе «метрика упала».
4. Estimation / market sizing. «Сколько кофеен в Москве?» / «Какой потенциал нового рынка?» Проверяет умение оценивать величины без точных данных, разбивать на компоненты, делать разумные допущения. Подробнее — в гайде по Fermi-задачам.
Фреймворки для структурирования
CIRCLES — для design/improve feature.
- Comprehend the situation — пойми контекст, цели, ограничения.
- Identify the customer — кто пользователь, какие сегменты.
- Report the customer needs — какие потребности у каждого сегмента.
- Cut, through prioritization — на какой потребности фокусируемся.
- List solutions — 3-5 решений приоритетной проблемы.
- Evaluate trade-offs — что выигрываем / теряем по каждому.
- Summarize recommendation — что сделал бы и почему.
Подробнее — фреймворк CIRCLES.
AARM — для metric drop.
- Awareness — что вообще происходит, на каком масштабе.
- Acquisition / Activation — что с привлечением и первым использованием.
- Retention — что с возвращением пользователей.
- Monetization — что с выручкой.
Декомпозиция метрики по жизненному циклу пользователя. Помогает не упустить целые блоки.
RICE / ICE — для приоритизации решений. RICE = Reach × Impact × Confidence / Effort. ICE = Impact × Confidence × Ease. Подробнее — RICE и ICE.
Главный совет: фреймворк — это не цель, а средство. Названия фреймворков на собесе никого не впечатляют. Впечатляет структура мышления, в которую фреймворк помогает упаковать ответ.
Структура ответа на кейс — 5 шагов
Шаг 1: уточняющие вопросы. Не прыгай к решению. Задай 2-4 вопроса про контекст:
- Какой именно продукт / сегмент / рынок
- Какая цель — рост / монетизация / удержание
- Какие данные доступны
- Какие ограничения (бюджет, время, технические)
Шаг 2: декомпозиция. Разбей задачу на компоненты:
- Для improve — выделить ключевые шаги функциональности
- Для metric drop — разложить метрику на factor (CR = visits × conversion × purchases)
- Для design — сегменты пользователей и их потребности
- Для estimation — формула и переменные
Шаг 3: гипотезы / решения. На каждый компонент — 2-3 варианта. Используй MECE: категории не пересекаются и покрывают всё пространство.
Шаг 4: приоритизация. Не все идеи равноценны. Применяй RICE или ICE. На собесе обычно проговаривают рассуждение без точных цифр.
Шаг 5: рекомендация и метрики успеха. Финал: что бы сделал в первую очередь, почему, как поймёшь что сработало (какая метрика, какой MDE, какой timeframe).
Пример разбора: «Доля повторных покупок на маркетплейсе упала на 8%»
Уточнение: «На каком сегменте упала — на всех или конкретных категориях? Какой период — неделя, месяц? Был ли релиз накануне? Есть ли изменения в маркетинге?»
Декомпозиция: Repeat purchases = (число повторных юзеров) / (общее число активных юзеров). Падение может быть из-за:
- Меньше пользователей возвращается (retention-проблема)
- Возвращаются, но не покупают (продуктовая или ценовая проблема)
- Изменился микс юзеров — больше новых разовых покупателей в знаменателе
Гипотезы: (a) техническая проблема — баг в push, в email-маркетинге; (b) ценовая — конкурент дал сильную акцию, отток лояльных в первый месяц; (c) ассортиментная — закончилась категория с высокой повторностью; (d) сезонная — пост-новогодний спад.
Приоритизация: проверять в порядке вероятности × лёгкости. Сначала — данные (не сломался ли трекинг), потом — push/email engagement, потом — сегментация по категориям, потом — внешние факторы.
Рекомендация: в первую очередь нужно убедиться, что данные корректны и нет технического сбоя. Если данные ок — провести segmentation analysis и определить, где именно проседает. Метрика успеха решения — возврат показателя на baseline за 4-6 недель.
Частые ошибки на кейсах
Прыгать к решению без уточнения. На любой кейс первые 60 секунд — уточняющие вопросы. Это показывает зрелость.
Перечислять идеи без структуры. 10 случайных гипотез выглядят хаотично. 4 структурированные по MECE — профессионально.
Зубрить фреймворки без понимания. «Я использую RICE» — фразу можно сказать. На уточнение «почему именно RICE здесь?» нужен содержательный ответ.
Игнорировать сегменты. Любая метрика в среднем по всей аудитории врёт. Сегментация — обязательный этап рассуждения.
Не приоритизировать. Если предложил 5 решений и не сказал, какое первое — кейс не закончен.
Не назвать метрику успеха. Решение без измеримой метрики — гипотеза, не план.
FAQ
Сколько минут готовиться к ответу на кейс?
На собесе обычно дают 2-5 минут на структурирование, потом 30-45 минут проговариваешь решение. Используй время на структуру, не на финальный ответ. Лучше структура без полного ответа, чем хаотичный «ответ».
Можно ли спросить «что у вас сейчас?» вместо догадок?
Да, и нужно. «Сейчас у нас retention D7 на уровне 25% — мы хотим 35%» — гораздо проще работать с реальными цифрами, чем с воображаемыми.
Что делать, если не знаю домена?
Спросить интервьюера. «Я не работал с маркетплейсами — что является ключевой метрикой для buyers и для sellers в вашей категории?» Это нормальный вопрос. Делать вид что знаешь — хуже.
Нужно ли называть фреймворк по имени?
Не обязательно. «Я разложу задачу по жизненному циклу пользователя» — лучше, чем «применю AARM». Названия не впечатляют, структура впечатляет.
Что важнее на кейсе — точные цифры или структура?
Структура. Точные числа в кейсе никто не проверяет. Главное — обоснованные допущения и логика, ведущая к ним.