Кейс «спроектируй фичу» на собесе продакта

Чем design-кейс отличается от improve

«Спроектируй фичу» (или целый продукт) — кейс, где вам не дают существующий сервис, а просят придумать с нуля. «Спроектируй приложение для обмена книгами», «спроектируй фичу для подростков в Телеграм», «спроектируй сервис аренды самокатов в маленьком городе». Цель — посмотреть, как вы думаете в условиях белого листа: умеете ли начинать с пользователя, ставить цели, отрезать лишнее.

Главная ловушка — кандидат сразу проваливается в UI. «Тут будет лента, тут поиск, тут профиль». Но проектирование начинается не с экранов, а с того, кому и зачем это нужно. Если внутри головы нет каркаса, на собесе его не появится — поэтому каркас лучше выучить заранее и тренировать на разных вводных.

Сравнение двух типов кейсов:

Параметр	Design-кейс	Improve-кейс
Стартовая точка	Чистый лист	Существующий продукт
Что проверяют	Структуру мышления, креатив, отрезание	Декомпозицию, метрики, гипотезы
Главная ловушка	Прыжок в UI	Сразу решения без диагностики
Длительность	30–45 мин	30–60 мин
Финал	MVP с метриками успеха	Гипотеза с приоритетом и тестом

Шаг 1. Цель продукта и бизнеса

Первое — спросите себя и интервьюера: какую бизнес-цель закрывает продукт. Без неё непонятно, что считать успехом.

Варианты обычно сводятся к четырём: привлечение новой аудитории, удержание текущей, монетизация, выход в новый сегмент. Уточните: «Я правильно понимаю, что мы делаем продукт, чтобы привлечь молодую аудиторию в экосистему?» Если интервьюер не определился — предложите вариант сами и зафиксируйте: «допустим, главная цель — рост MAU среди 18–24, потому что иначе фича не имеет смысла». Допущения проговаривать вслух — норма.

Антипаттерн: «давайте сделаем продукт, который понравится пользователям». Это не цель, это пожелание. Хорошая формулировка — измеримая: «вырасти DAU выбранного сегмента на 10–15% за два квартала», «привлечь 50 тысяч новых регистраций из узкой аудитории», «выйти на безубыточность через 12 месяцев». Числа можно проговаривать как порядки величин — на собесе никто не ждёт точной финансовой модели, но без чисел цель остаётся пустой.

Шаг 2. Пользователь и его джоб

Дальше — кому это нужно. Назовите 2–3 потенциальных сегмента, опишите, что они хотят сделать (job-to-be-done), и выберите приоритетный. Не «все люди от 14 до 60», а конкретно «студент, который читает 1–2 книги в месяц и не хочет тратить деньги».

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

Шаблон описания сегмента: «Кто (демография и поведение), какой у него job-to-be-done, как он сейчас закрывает эту задачу, что в текущем решении болит, при каком триггере он бы попробовал альтернативу». Если вы можете прогнать этот шаблон за минуту вслух, вы прошли половину кейса.

Шаг 3. Основные сценарии

Для приоритетного сегмента опишите 2–3 ключевых сценария: первый запуск, регулярное использование, момент возврата. Каждый сценарий — это короткая история: «человек открывает приложение, видит X, делает Y, получает Z».

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

Полезно для каждого сценария называть «момент истины» — точку, в которой пользователь либо получает ценность, либо уходит. Для приложения такси это «увидел машину на карте через ETA меньше ожидания». Для маркетплейса — «нашёл то, что искал, в первых 5 результатах». Если в сценарии нет момента истины — пользователь не вернётся.

Шаг 4. MVP и фичи

Из сценариев выпишите минимальный набор фич, без которых продукт не работает. Это и есть MVP. Параллельно — список «потом»: что добавим, если зайдёт.

Хорошая практика — явно сказать, что вы убрали из MVP и почему. Например: «соцграф и лента активности — потом, потому что без базового сценария обмена они не нужны». Это показывает, что вы умеете отрезать.

Шаблон таблицы для приоритизации в MVP:

Фича	Зачем (какой сценарий закрывает)	Усилия	Решение
Поиск книг рядом	Базовый сценарий поиска	M	В MVP
Чат для договорённости	Закрытие сделки	S	В MVP
Рейтинг пользователей	Доверие	M	После MVP
Доставка через курьера	Расширение охвата	L	В roadmap

Усилия — грубо S/M/L, точнее на этапе кейса не нужно. Главное — показать, что вы умеете класть в MVP только то, что без чего не работает базовый сценарий.

Шаг 5. Метрики успеха и риски

Закрываем ответ метриками и рисками. Метрики — northstar (одна главная) и 2–3 поддерживающих. Риски — что может убить продукт: нет предложения, нет спроса, плохая логистика, юридика.

Для каждого риска полезно назвать, как бы его проверили: интервью с пользователями, лендинг с записью, ручной MVP без приложения. Это переводит разговор из «придумал, защитил» в «придумал, готов проверять» — большая разница в восприятии.

Полезный фрейм рисков — ICE: impact (что сломается), confidence (насколько уверены, что риск реальный), ease (легко ли проверить). Сначала проверяем риски с высоким impact и низким confidence — то есть то, что может убить идею и в чём вы пока не уверены.

Пример: спроектируй приложение для обмена книгами

Цель — рост MAU среди студентов 18–24. Сегмент — городской студент, читает 1–2 бумажные книги в месяц, экономит. Триггер — закончил книгу, хочет следующую без похода в магазин.

Сценарии: первый запуск (показал свои книги, увидел, что есть рядом), запрос на обмен (выбрал, договорился, встретился), возврат (получил уведомление о новой книге у соседа). MVP — список книг пользователя, поиск по геолокации, чат для договорённости. Потом — рейтинги, доставка, подписка на жанры.

Northstar — количество завершённых обменов на пользователя в месяц. Поддерживающие — DAU/MAU, retention W2, доля пользователей с минимум 3 книгами в профиле. Главные риски: нет плотности предложения в районе, страх встречаться с незнакомцем. Проверка — запуск в одном районе одного города, ручной чат поддержки.

Антипатерн — рассказывать про экраны: «на главной будет карта, сверху — поиск, в углу — профиль». Это не проектирование, это описание макета. Сильнее звучит «первый сценарий — увидеть книги рядом, поэтому первый экран — список или карта в зависимости от плотности предложения; в маленьком городе список будет понятнее, в большом — карта».

Тайминг ответа и что делать на каждой минуте

Кейс на 30 минут — это ориентир, и на каждый этап есть свой бюджет. Если этого не помнить, к концу не успеваешь ни до MVP, ни до метрик.

• 0–3 мин: уточняющие вопросы и фиксация цели.
• 3–8 мин: сегменты, выбор приоритетного, JTBD.
• 8–15 мин: сценарии и моменты истины.
• 15–22 мин: MVP и список «потом», явное отрезание.
• 22–28 мин: метрики и риски, как бы проверяли.
• 28–30 мин: общая логика, что бы сделали в первую очередь после собеса.

Если интервьюер обрывает или спорит — не паниковать, это часть формата. Сильный кандидат отвечает: «справедливо, давайте я возьму ваш вариант и встрою в логику», а не упирается.

Частые ошибки

• Прыгать в UI. Описание экранов до того, как зафиксирован пользователь и цель.
• Пытаться сделать «для всех». Размытый сегмент = размытый продукт.
• Молчать про метрики. Без northstar непонятно, что считается успехом.
• Не отрезать. В MVP попадает всё подряд — это уже не MVP.
• Игнорировать риски. «У меня всё взлетит» звучит как красный флаг.
• Не уточнять у интервьюера. Кейсы намеренно даются с двусмысленностью — её надо снять вопросами в первые минуты.
• Молча думать. Если думаете — проговаривайте структуру вслух, иначе интервьюер не понимает, на каком вы этапе.

Связанные темы

• Кейс «улучши X»: что говорить на продакт-собесе
• Что такое продуктовая аналитика
• Как пройти собес продакт-менеджера в Яндексе
• Что такое A/B-тест

FAQ

Сколько фич называть в MVP?

3–5. Меньше — выглядит несерьёзно, больше — это уже не MVP, а полноценный релиз.

Нужно ли рисовать схемы?

Если есть доска или маркер — да, простой набросок воронки или сценария помогает. На устном собесе можно проговорить «текстом».

Как ответить, если продукт мне не близок?

Честно сказать, что не сталкивались, и попросить 30 секунд подумать. Дальше — обычный каркас: цель, сегмент, сценарии, MVP, метрики.

Стоит ли упоминать конкурентов?

Кратко — да, чтобы показать, что вы знаете рынок. Но не превращайте кейс в аналитический отчёт о конкурентах.

Что делать, если интервьюер говорит «нет, давайте по-другому»?

Принять и встроить. Не упираться в свою логику. Гибкость на собесе считывается как сила.

Как защититься, если кейс сильно не из моей сферы?

Использовать каркас. Цель, сегмент, сценарии, MVP, метрики работают в любой индустрии. Глубина уйдёт, но структура останется — этого часто достаточно.

Сколько метрик называть?

1 northstar и 2–4 поддерживающих. Больше — путаешься сам и теряешь интервьюера.

Можно ли в MVP только одну фичу?

Только если эта фича сама по себе закрывает базовый сценарий. Чаще нужно 3–5: вход, основное действие, возврат.

---

Тренируйте продуктовые кейсы — откройте Карьерник с задачами на проектирование и улучшение продуктов.