Вернуться в каталог собеседований

Идеальное собеседование в прямом эфире. Спикеры — Сергей Колосков, Марина Михеева

Демонстрационное интервью Product Manager с разбором продуктовых кейсов: воронки, исследования, unit-экономика, конкуренты, приоритизация и коммуникация в команде. Запись завершается вопросами зрителей, обратной связью и презентацией курсов ProductStar.

ProductStar
  • Опубликовано на YouTube:
  • Просмотры на YouTube: 7,9 тыс.
  • Лайки на YouTube: 191
Открыть на YouTube

Таймлайн

Коротко о видео

Образовательный стрим ProductStar показывает демонстрационное собеседование Product Manager: кандидатка разбирает свой опыт в продуктовой аналитике, воронках такси-сервиса, исследованиях, приоритизации и работе с командой. В кейсах она объясняет, как находить причины отвалов, проверять гипотезы количественными и качественными данными, разрешать спор дизайнера и разработчика через MVP. В финале ведущий отвечает на вопросы зрителей, даёт кандидату обратную связь и рекламирует курсы ProductStar для Product Manager.

Затронутые темы

Что взять на заметку

  • Перед улучшением онбординга и воронки кандидатка предлагает сначала настроить сквозную аналитику: без неё нельзя надёжно локализовать этапы отвалов.
  • В её примере причины отвалов разделяются на технические (загрузка документов, платежи, адаптивность экранов) и продуктовые/смысловые (ожидание машины, отмены, оплата, ценность сценария).
  • Приоритизацию стоит начинать с крупнейшего drop-off на ранних шагах воронки, а затем работать с пользователями, почти завершившими целевое действие; кандидатка называет их «горячими лидами».
  • Интервью с пользователями не следует принимать как единственное доказательство ценности фичи: ответ предлагает сверять их с долей респондентов, обращениями в поддержку и другими данными.
  • Для гипотез команда оценивает соответствие цели и vision продукта, стоимость в ресурсах, ожидаемый эффект и метрики здоровья; после этого гипотеза декомпозируется в задачи недельного спринта.
  • В споре между дизайнером и разработчиком сначала нужно определить, является ли решение обязательной фичей или проверяемой гипотезой: для гипотезы достаточно быстрого рабочего MVP, а полную реализацию стоит делать после подтверждения эффекта.
  • На собеседовании при неполных входных данных полезно явно обозначать допущения, декомпозировать проблему и предлагать способ проверить каждую версию, а не делать вид, что данных достаточно.

Рекомендуем посмотреть