Материал Эйч · Опубликовано 13 июля 2026
Middle PM на продукты Scheduling и Modules в B2B SaaS для сферы услуг. Фокус — data-driven приоритизация, UX по поведению пользователей и умение доказать «зачем» каждой фиче.
Фишка: Продуктовая экосистема для сферы услуг: онлайн-запись на 15+ площадках, YPLACES, модули (финансы, склад, лояльность, аналитика), 100+ интеграций. PM работает на стыке поведения владельцев салонов/сетей и метрик заполняемости, no-show, LTV.
| Этап | Длительность | Что проверяют |
|---|---|---|
| Скрининг / HR | 30–45 мин | Мотивация перехода в PM, опыт работы с продуктом vs проектами, зарплатные ожидания, гибрид (3 дня в офисе, м. Тульская), готовность к Senior-уровню ответственности |
| Интервью с нанимающим PM / Head of Product | 60–90 мин | Продуктовое мышление: как формировал backlog, принимал решения на данных, говорил «нет», работал с dev/design. Кейсы по Scheduling/Modules |
| Продуктовый кейс | 45–60 мин | Приоритизация фич, анализ метрик запущенной фичи, улучшение онлайн-записи или модуля для сетевого бизнеса. Ожидают структурированный ответ с гипотезами и метриками успеха |
| Кросс-функциональная встреча | 45–60 мин | Коммуникация с разработкой и дизайном, качество user stories/ТЗ, фасилитация |
| Финал с руководителем | 30–45 мин | Культурный fit: flat-культура («на ты»), ownership, стратегическое видение продукта, вопросы о Yclients как «операционной системе для бизнеса» |
Обязательный минимум
Плюсом будет
Как ты участвовал в формировании продуктовой стратегии?
Vision → цели на квартал → инициативы → метрики. Покажи связь с данными рынка и пользователей, не только с roadmap delivery.
Как строишь roadmap на квартал?
Now-Next-Later или OKR → initiatives. Укажи inputs: аналитика, интервью, support-тикеты, бизнес-цели. Покажи trade-offs.
Scheduling vs Modules — как бы ты определил приоритеты между двумя продуктовыми направлениями?
Для Yclients: Scheduling = core (запись, fill rate, no-show); Modules = expansion (LTV, ARPU). Сравни impact на North Star (кол-во записей / revenue per client) и стратегию «операционная система».
Фишка: Yclients позиционирует себя как «интеллектуальная операционная система для бизнеса» — на собесе покажи, что видишь продукт шире, чем виджет записи.
Как приоритизируешь бэkлог, когда все задачи «срочные и важные»?
Фрейм: impact × confidence / effort. Собери данные: сколько клиентов затронуто, revenue impact, cost of delay. Покажи, как говорил «нет».
Stakeholder просит фичу «на вчера». Твои действия?
Уточни проблему → проверь данные → предложи MVP или альтернативу → зафиксируй решение письменно. Не просто «нет», а «не сейчас, потому что…».
Расскажи о случае, когда ты отказал в фиче и это было правильным решением.
STAR: ситуация → что предлагали → твой анализ (метрики/риски) → результат. Идеально, если сэкономили ресурсы команды.
Ловушка: Не отвечай «все задачи в Jira по приоритету PO». Yclients явно ищет PM, который сам чувствует направление и доказывает «почему».
Совет: Подготовь мини-кейс: 5 фич для Scheduling (например: предоплата, напоминания VK, запись через Telegram, сетевой календарь, промоблок) — проранжируй с обоснованием.
Как собираешь требования от пользователей, поддержки и аналитики?
Triangulation: интервью (Jobs-to-be-Done) + support-тикеты (частота/severity) + продуктовые данные (drop-off, funnels). Выход: problem statement → user story → acceptance criteria.
Как пишешь user stories и ТЗ для разработки?
As a [role], I want [action], so that [value]. AC: given/when/then. Добавь edge cases, метрики успеха, mockup/wireframe. Покажи пример из своего опыта.
Как отличаешь симптом от корневой проблемы?
5 Whys. Пример для Yclients: «клиенты не записываются» → UX? нет слотов? нет доверия? конкурент ближе? → разные решения.
Как анализируешь результаты запущенной фичи?
До/после + контрольная группа если есть. Метрики: primary (целевая) + guardrails (не сломали ли другое). Срок: 2–4 недели на значимость. Вывод: ship/iterate/kill.
Какие метрики ты бы отслеживал для модуля онлайн-записи?
Conversion воронки записи, fill rate, no-show rate, time-to-book, % записей с предоплатой, источники трафика (Яндекс Карты, 2GIS, YPLACES), retention салона.
Метрика выросла на 5%. Это успех?
Зависит от baseline, статзначимости, сегмента, seasonality. Спроси: какой был target, сколько пользователей, как long-term retention.
Фишка: Yclients публикует кейсы клиентов: +30% записей, +25% retention, 70% клиентов записываются онлайн — используй эти цифры, чтобы показать понимание домена.
Ловушка: Не называй vanity metrics (page views) без связи с бизнес-результатом клиента (записи, выручка, LTV).
Как понимаешь UX — не по макетам, а по поведению?
Session recordings, funnels, heatmaps, support feedback. Пример: drop-off на шаге выбора мастера → мало слотов vs плохой UI.
Как бы улучшил онboarding нового салона в Yclients?
Time-to-first-booking, activation checklist, персональный куратор (у них есть!), шаблоны услуг, импорт базы. Метрика: % салонов с первой записью за 7 дней.
Владелец сети из 10 филиалов — какие у него боли vs одиночный салон?
Сеть: единый календарь, права доступа, консолидированная аналитика, франчайзи-контроль. Одиночный: простота, быстрый старт, минимум настроек.
Фишка: Продукт Yclients основан на 60+ UX-исследованиях — на собесе уместно спросить, как команда делится инсайтами и как PM участвует в research.
Как выстраиваешь работу с командой разработки и дизайна?
Ритуалы: refinement, planning, demo, retro. PM приносит problem + success metrics, не готовое решение. Design — discovery, Dev — feasibility early.
Разработка говорит, что фича займёт 3 месяца вместо 3 недель. Что делаешь?
Scope cut → MVP → phased rollout. Пересмотри AC, найди 20% scope с 80% value. Не давить, а вместе декомпозировать.
Конфликт между дизайном и бизнесом по scope фичи.
Вернись к user problem и метрикам. Прототип/тест с 5 пользователями. Escalate с data, не с opinion.
Приоритизация бэkлога Scheduling
Ты PM продукта Scheduling в Yclients. На квартал есть capacity команды на 3 major-фичи из списка: 1) Предоплата при онлайн-записи (снижение no-show) 2) Запись через Telegram-бота 3) Единый календарь для сетей 5+ филиалов 4) A/B промоблока с акциями на форме записи 5) Ускорение загрузки виджета на мобильных Stakeholders: Sales просят (3), Support — (1), CEO — (4). Выбери 3 фичи и обоснуй.
Рекомендуемый порядок: 1) Предоплата (1) — прямой impact на no-show и revenue клиентов; данные Yclients: доходимость до 85% с уведомлениями, предоплата усиливает эффект. High impact, medium effort. 2) Единый календарь сетей (3) — стратегический сегмент (сети/франчайзи), higher ARPU, differentiation vs конкурентов. High impact, high effort — но CEO-уровень стратегии «операционная система». 3) A/B промobлок (4) — quick win для acquisition/конверсии, кейс Xella: 300+ новых пациентов за год. Medium impact, lower effort. Отложить: Telegram (2) — channel expansion, но без core fix no-show/calendar меньше leverage. Performance (5) — guardrail, можно как quick fix отдельной командой. Фрейм: для каждой фичи — impact (на записи/revenue/retention), confidence (есть ли данные), effort (eng weeks), cost of delay.
Сложность: O(n) по числу инициатив — главное качество обоснования, не алгоритм
Post-launch анализ фичи
2 месяца назад запустили бесплатные напоминания через VK для сегмента beauty-салонов (5000 салонов). Результаты: - No-show rate: 18% → 15% - Записи через VK: +12% от total - NPS салонов: без изменений (42) - Support-тикеты про «не приходят напоминания»: +40% CEO спрашивает: продолжаем rollout на все сегменты или iterate?
Решение: iterate, не full rollout. Анализ: + No-show -3pp — положительно, но нужна stat significance и cohort view (новые vs old салоны). + VK-канал растёт — хороший signal для acquisition. − NPS flat — салоны не видят ценность или есть pain с setup. − Support +40% — критичный guardrail, риск churn. Next steps: 1) Разобрать тикеты: setup, доставляемость, opt-in клиентов. 2) Сегментировать: какие салоны получили benefit vs проблемы. 3) Fix top-3 причин тикетов → повторный pilot на 1000 салонов. 4) Метрики для go-decision: no-show -2pp+, support tickets < +10%, NPS +3. Не rollout, пока support issue не решён — иначе масштабируем проблему.
Сложность: Качественный анализ, не алгоритмическая задача
Discovery: формализация требований
Support сообщает: «Много жалob от сетевых клиентов — администраторы путаются, в каком филиале записан клиент, и двойная запись в разных филиалах». Как проведёшь discovery и что принесёшь команде?
1) Problem framing: сколько тикетов/нед, какой % сетей, revenue at risk. 2) Интервью: 5 админов сетей + 3 владельца + 2 support-агента. 3) Данные: частота cross-branch bookings, cancel rate, duplicate client IDs. 4) Root cause hypothesis: нет единого view клиента / нет блокировки double booking / плохой UX переключения филиала. 5) Output для команды: - Problem statement - User stories (admin видит все записи клиента; система предупреждает о конфликте) - MVP scope: unified client card + conflict alert (без full CRM redesign) - Success metrics: -50% тикетов, -30% double bookings за 60 дней - Wireframe flow + edge cases (client в 2 городах, franchise permissions)
Сложность: Процесс discovery, 1–2 недели
Каркас ответа
3 дня
7 дней
14 дней
| Блок | Готов, если... |
|---|---|
| Стратегия и roadmap | можешь за 3 мин объяснить, как бы построил roadmap Scheduling на квартал с привязкой к North Star |
| Приоритизация | прорешал кейс 5 фич и можешь аргументированно сказать «нет» Sales/CEO |
| Discovery | можешь провести mock discovery по тикету support про сетевых клиентов |
| Аналитика | знаешь 5 метрик онлайн-записи и можешь разобрать post-launch кейс VK-напоминаний |
| Продукт Yclients | пользовался продуктом/демо и можешь назвать 3 модуля экосystem и конкурентное преимущество |
| Behavioral | 3 STAR-истории отрепетированы, есть ответ на «почему PM, не DPM» и «почему Yclients» |
В день собеседования