Первые 90 дней продакт-менеджера: что делать, чтобы не завалить испытательный срок

Почему 70% продактов не проходят испытательный срок

По данным исследования Product Management Festival 2024, каждый третий продакт-менеджер не проходит испытательный срок в новой компании. Ещё 40% проходят формально, но получают негативную обратную связь и попадают в PIP (Performance Improvement Plan) через 6-9 месяцев.

Парадокс: это происходит даже с опытными PM, которые успешно работали в других компаниях. Проблема не в компетенциях — проблема в том, как эти компетенции применяются в первые 90 дней.

Три главных причины провала:

1. «Синдром нового начальника» — PM приходит и сразу начинает менять продукт, не разобравшись в контексте. Команда саботирует инициативы, бизнес теряет доверие.

2. Паралич анализа — PM три месяца изучает продукт, проводит исследования, но не показывает никаких результатов. К концу испытательного срока у руководства вопрос: «А зачем мы его наняли?»

3. Неправильные приоритеты — PM фокусируется на том, что интересно (новые фичи, редизайн), вместо того, что важно для бизнеса (метрики, боли пользователей, технический долг).

Что отличает успешных PM в первые 90 дней:

• Они следуют структурированному плану адаптации (30/60/90)

• Они балансируют обучение и действия (не только учатся, но и делают)

• Они строят доверие с командой ДО того, как предлагать изменения

• Они показывают quick wins, пока изучают стратегию

• Они задают правильные вопросы, а не дают готовые ответы

В этой статье я дам вам пошаговый фреймворк, который помог сотням продакт-менеджеров успешно пройти испытательный срок в компаниях от стартапов до FAANG. Это не теория из учебников — это конкретные действия, чеклисты, шаблоны вопросов и разбор реальных ошибок.

Фреймворк 30/60/90: структура успешной адаптации

Общая логика

Первые 30 дней: Learn (Учиться)
- Главная цель: понять контекст (продукт, команда, пользователи, бизнес)
- Результат: документ «Что я понял» + список гипотез
- Ошибка: начинать менять продукт без понимания «почему оно так сделано»

Дни 31-60: Contribute (Вносить вклад)
- Главная цель: показать первые результаты (quick wins)
- Результат: 2-3 небольших улучшения + план на квартал
- Ошибка: браться за большие проекты, которые не закончатся до конца испытательного срока

Дни 61-90: Lead (Вести)
- Главная цель: показать стратегическое мышление
- Результат: роадмап на квартал + измеримое влияние на метрики
- Ошибка: продолжать «копаться в деталях» вместо масштабирования влияния

Первые 30 дней: Learn (Учиться)

Цель первого месяца

К концу 30-го дня вы должны ответить на 5 ключевых вопросов:

1. Кто наши пользователи и какие у них главные боли?

2. Какие метрики важны для бизнеса и почему продукт устроен так, а не иначе?

3. Кто принимает решения и как устроены процессы?

4. Какие главные проблемы продукта и команды (технические, продуктовые, организационные)?

5. Что я могу улучшить в первые 60 дней без больших рисков?

Неделя 1: Погружение в продукт и команду

День 1-2: Онбординг и знакомство

Чек-лист первого дня:
- ✅ Встреча с руководителем (1:1) — договоритесь о формате обратной связи
- ✅ Знакомство с командой (не только «привет», но и роли/зоны ответственности)
- ✅ Получить доступы: продуктовая аналитика, код (хотя бы read-only), документация, Slack/Teams каналы
- ✅ Попросить «onboarding buddy» — человека, у которого можно спрашивать «глупые вопросы»
- ✅ Узнать ритуалы команды (стендапы, ретро, планирование)

Шаблон первой встречи с руководителем:

«Привет! Хочу договориться о формате работы на испытательный срок:

1. Ожидания: Что для тебя будет означать »успешный испытательный срок«? Какие результаты ты хочешь увидеть через 30/60/90 дней?

2. Обратная связь: Как часто давать апдейты? Предлагаю еженедельные 1:1 по пятницам + короткий письменный отчёт в конце каждого месяца.

3. Границы автономии: Какие решения я могу принимать сам, а какие нужно согласовывать?

4. Контекст: Почему наняли на эту позицию именно сейчас? Какая главная боль, которую я должен решить?»

Чего НЕ делать в первый день:
- ❌ Сразу предлагать изменения («А почему у вас кнопка не тут?»)
- ❌ Критиковать текущие процессы («В моей прошлой компании было лучше»)
- ❌ Пропускать знакомства с «неважными» людьми (секретарь CEO важнее, чем вы думаете)

День 3-5: Глубокое погружение в продукт

Задачи:

1. Используйте продукт как пользователь

2. Пройдите полный onboarding с нуля (зарегистрируйтесь как новый пользователь)

3. Попробуйте выполнить 3-5 ключевых use cases

4. Записывайте все вопросы и сложности («Почему это так работает?»)

5. Изучите аналитику

6. Какие дашборды смотрят каждый день? (North Star метрика)

7. Как выглядит воронка конверсии?

8. Какие сегменты пользователей (по поведению, географии, платежам)?

9. Где самые большие drop-offs?

10. Прочитайте документацию

11. Product vision & strategy

12. Роадмап (текущий и прошлый квартал)

13. User research (последние исследования)

14. Post-mortems (что запускали и почему провалилось)

Шаблон для заметок о продукте:

## Продукт: [Название]

### Пользователи
- Основная аудитория:
- Сегменты:
- Jobs To Be Done:

### Ключевые метрики
- North Star:
- Вторичные метрики:
- Воронка конверсии:

### Проблемы/наблюдения
1. [Что заметил] → [Вопрос для команды]
2. ...

### Гипотезы для улучшений
1. [Гипотеза] → [Как проверить?]
2. ...

Неделя 2: Исследование пользователей и стейкхолдеров

Задачи:

1. 10-15 встреч с пользователями

2. 5 встреч с активными (power users)

3. 5 встреч с новичками (onboarding < 2 недель)

4. 3-5 встреч с churned (почему ушли?)

Шаблон вопросов для интервью:

Для активных пользователей:
- «Расскажи, как ты используешь [продукт] в своём рабочем дне?»
- «Какая главная ценность, которую получаешь?»
- «Что тебя больше всего раздражает?»
- «Если бы ты был PM, что бы изменил первым делом?»
- «Какие альтернативы рассматривал до нас?»

Для новичков:
- «Как ты узнал о нас?»
- «Что ожидал от продукта vs что получил?»
- «На каком этапе onboarding было сложно?»
- «Будешь ли рекомендовать друзьям? Почему да/нет?»

Для churned:
- «Что стало триггером для отказа от продукта?»
- «К какой альтернативе перешёл?»
- «Что могло бы вернуть тебя обратно?»

Встречи со стейкхолдерами

Карта стейкхолдеров (пример для B2B SaaS):

Шаблон встречи со стейкхолдером:

«Привет! Я новый PM на [продукте]. Хочу понять твой контекст:

1. Твоя роль и цели: Какие KPI за этот квартал?

2. Что ожидаешь от продукта: Как я могу помочь твоей команде быть эффективнее?

3. Текущие боли: Что сейчас не работает/мешает?

4. Формат взаимодействия: Как часто синхронизироваться? Какой формат удобен (встречи, Slack, email)?»

Пример из практики (B2B SaaS):

Новый PM пришёл в компанию и первым делом встретился с Head of Sales. Вопрос: «Какие фичи нужны для закрытия крупных сделок?»

Ответ: «Нам нужны SSO и SAML для enterprise-клиентов. Мы теряем 2-3 сделки в месяц на $50K+ из-за этого.»

PM не бросился сразу в разработку, а спросил:
- «Сколько сделок именно из-за этого проваливается?» (выяснилось: 1-2, а не 2-3)
- «Какие ещё причины отказов?» (выяснилось: медленная поддержка важнее SSO)
- «Если сделаем SSO за 3 месяца, на сколько вырастет конверсия?» (Sales не смог ответить точно)

Вывод: SSO важен, но не критичен прямо сейчас. PM добавил в роадмап, но сфокусировался на поддержке.

Неделя 3: Погружение в команду разработки

Задачи:

1. Понять технический контекст

2. Попросить архитектурную схему (какие сервисы, как общаются, где узкие места)

3. Посмотреть backlog технического долга (что хотят рефакторить и почему)

4. Узнать про ограничения (легаси код, скорость CI/CD, тестовое покрытие)

5. Встроиться в процессы

6. Участвовать в daily standups (слушать, не вести)

7. Посмотреть 2-3 спринта в ретроспективе (что обсуждали на ретро)

8. Понять definition of done (когда задача считается готовой?)

9. Построить доверие с разработчиками

Как завоевать доверие команды (действия, а не слова):

✅ Делайте:
- Приходите на code review (даже если не пишете код) — покажите интерес
- Спрашивайте «Почему это сложно реализовать?» вместо «Почему так долго?»
- Берите на себя задачи (написать тесты, обновить документацию, разобрать support тикеты)
- Защищайте команду от scope creep («Нет, мы не будем менять требования в середине спринта»)

❌ Не делайте:
- Не обещайте бизнесу сроки без согласования с командой
- Не говорите «Это же просто кнопку добавить» (нет такого слова «просто»)
- Не приносите каждый день «супер-срочную» задачу от CEO
- Не игнорируйте технический долг («Потом порефакторим, давайте фичи»)

Пример из практики:

Junior PM пришёл в команду и на первом планировании спринта сказал: «Давайте сделаем редизайн главной страницы за 2 недели, это приоритет от CEO.»

Tech Lead: «Мы не успеем, там нужно переписать компонентную систему.»

PM: «Ну постарайтесь, очень нужно.»

Результат: команда сделала за 2 недели «половину редизайна», который пришлось откатить из-за багов. CEO разочарован, команда больше не доверяет PM.

Правильный подход:

PM: «CEO хочет редизайн главной. Давайте разберёмся, что именно его не устраивает и какой минимальный scope можем сделать качественно?»

Tech Lead: «Если только текст и картинки — 1 неделя. Если новые компоненты — 4 недели.»

PM: «Ок, давайте за 1 неделю обновим текст и визуал существующими компонентами. Покажем CEO, соберём обратную связь, потом сделаем фазу 2 с новыми компонентами.»

Результат: CEO видит прогресс через неделю, команда работает без стресса, PM показывает себя адекватным человеком.

Неделя 4: Синтез и презентация

Задачи:

Создать документ «30-day insights»

Структура документа:

# Мои наблюдения за первые 30 дней

## Executive Summary
- Что я понял о продукте, пользователях, команде (3-5 пунктов)
- Главные возможности для роста (топ-3)
- Главные риски (топ-3)

## Продукт
### Сильные стороны
1. ...
2. ...

### Слабые стороны
1. ...
2. ...

### Метрики (текущее состояние)
- North Star: [значение, динамика]
- Конверсия onboarding:
- Retention D7/D30:
- Churn rate:

## Пользователи
### Сегменты
1. [Описание сегмента] — [% от базы] — [главная боль]
2. ...

### Ключевые инсайты из интервью
- «Цитата пользователя» → [что это значит для продукта]
- ...

## Команда и процессы
### Что работает хорошо
- ...

### Что можно улучшить
- ...

## Quick wins (предложения на 30-60 дней)
1. [Идея] — [ожидаемый эффект] — [усилия разработки]
2. ...

## Вопросы для обсуждения
1. ...
2. ...

Презентовать руководителю

Запланируйте встречу на 60 минут в конце 4-й недели. Не просто отправляйте документ — обсудите лично.

Структура встречи:
- 5 мин: Что я понял о бизнесе и продукте
- 10 мин: Главные инсайты (покажите, что вы слушали пользователей и команду)
- 15 мин: Предложения на следующие 60 дней (2-3 quick wins)
- 20 мин: Обсуждение и обратная связь
- 10 мин: Договориться о приоритетах

Цель встречи: Показать, что вы не просто «изучали», а думали и готовы действовать.

Дни 31-60: Contribute (Вносить вклад)

Цель второго месяца

К концу 60-го дня вы должны показать измеримые результаты:

1. 2-3 quick wins — небольшие улучшения, которые уже влияют на метрики или пользовательский опыт

2. Квартальный план — приоритеты на следующий квартал с обоснованием

3. Улучшенные процессы — хотя бы один процесс команды стал лучше благодаря вам

Неделя 5-6: Реализация quick wins

Что такое хороший quick win:

✅ Критерии:
- Решается за 1-2 недели
- Измеримый эффект (метрика или качественная обратная связь)
- Низкий риск (не ломает существующий флоу)
- Показывает ваше понимание пользователей ИЛИ помогает команде

❌ Не quick win:
- Большой редизайн
- Переписывание архитектуры
- Интеграция с внешним API (обычно долго)
- Фича, которая требует изменений в 5+ местах продукта

Примеры хороших quick wins по типам продуктов:

B2C мобильное приложение:
- Улучшить onboarding (сократить шаги с 5 до 3, добавить прогресс-бар)
- Исправить топ-3 бага из support тикетов
- Добавить push-уведомления для брошенной корзины
- Оптимизировать время загрузки главного экрана

B2B SaaS:
- Добавить bulk actions (массовые операции) в админку
- Улучшить экспорт в CSV (добавить больше полей)
- Настроить email-дайджест для неактивных пользователей
- Создать onboarding checklist для новых клиентов

Внутренний продукт (для сотрудников):
- Автоматизировать рутинную операцию (которую делают 10 раз в день)
- Добавить поиск/фильтры в большую таблицу
- Интегрировать с Slack для нотификаций
- Улучшить документацию (видео-туториал вместо текста)

Кейс: quick win в e-commerce

PM пришёл в e-commerce компанию. Из интервью с пользователями выяснил: 30% бросают корзину, потому что «не было времени оформить заказ прямо сейчас, а потом забыл».

Quick win: Email-напоминание через 24 часа после добавления в корзину.

• Разработка: 3 дня (шаблон письма + триггер)

• Запуск: A/B-тест на 20% пользователей

• Результат через 2 недели: +5% к конверсии корзины (return on abandoned cart)

• Влияние на бизнес: +$15K выручки в месяц

PM показал результат через 3 недели после начала работы → доверие команды и бизнеса выросло.

Неделя 7: Стратегическое планирование

Задачи:

1. Провести приоритизацию backlog

Используйте любой фреймворк (RICE, ICE, Value vs Effort), главное — прозрачность критериев.

Пример RICE:

Reach — сколько пользователей затронет за период (квартал/месяц)
Impact — насколько сильно повлияет (1=low, 2=medium, 3=high)
Confidence — насколько уверены в оценках (%)
Effort — сколько человеко-недель

RICE = (Reach × Impact × Confidence) / Effort

2. Создать квартальный роадмап

Структура роадмапа:

# Q1 2025 Product Roadmap

## Цели квартала (привязаны к метрикам)
1. Увеличить retention D30 с 40% до 50%
2. Снизить churn rate с 8% до 5%
3. Запустить новый канал acquisition (партнёрская программа)

## Тематические треки

### Track 1: Retention (60% ресурсов команды)
- Milestone 1: Улучшенный onboarding (неделя 1-3)
  - Success metric: D7 retention +10%
- Milestone 2: Персонализация контента (неделя 4-6)
  - Success metric: время в продукте +20%
- Milestone 3: Email reactivation campaign (неделя 7-9)
  - Success metric: вернуть 15% churned пользователей

### Track 2: Churn reduction (30% ресурсов)
- ...

### Track 3: New acquisition channel (10% ресурсов)
- ...

## Что НЕ делаем в этом квартале (но будет в следующем)
- Редизайн главной (Q2)
- Мобильное приложение (Q2-Q3)
- AI-рекомендации (Q3)

Важно: Покажите роадмап команде ДО того, как показать руководству. Получите обратную связь:
- Реалистичны ли сроки?
- Понятны ли приоритеты?
- Что упустили?

3. Презентация роадмапа стейкхолдерам

Формат презентации (30 минут):

Слайд 1-2: Контекст
- Где мы сейчас (метрики, проблемы)
- Почему это важно для бизнеса

Слайд 3-4: Цели квартала
- Какие метрики двигаем
- Какой бизнес-эффект (revenue, retention, NPS)

Слайд 5-8: Что делаем (и почему в таком порядке)
- Показать приоритеты через фреймворк
- Связать каждую инициативу с целью

Слайд 9: Что НЕ делаем
- Это показывает, что вы думали о trade-offs
- Объясните, почему отложили (не хватает данных / меньший impact / блокеры)

Слайд 10: Риски и зависимости
- Что может пойти не так
- От кого зависим (другие команды, внешние API)

Слайд 11: Как будем измерять успех
- Метрики + частота отчётности

Ожидайте вопросы:
- «А почему не делаем [фичу X], которую просил CEO?»
- «Это слишком амбициозно / недостаточно амбициозно»
- «А как это повлияет на revenue?»

Подготовьте ответы заранее.

Неделя 8: Улучшение процессов

Почему это важно: К концу испытательного срока руководство оценивает не только результаты, но и как вы работаете. Улучшение процессов показывает зрелость.

Примеры улучшений процессов:

1. Product discovery

Было: фичи придумываются на встречах, без исследований

Стало: регулярные user interviews (5 в неделю) + запись инсайтов в Notion
 

2. Планирование

Было: планирование спринта занимает 3 часа, все устают

Стало: pre-planning за день до (PM готовит и оценивает задачи с Tech Lead), само планирование 1 час
 

3. Коммуникация

Было: разработка не знает, зачем делает фичу

Стало: в каждой задаче есть секция «Зачем» + ссылка на user research
 

4. Обратная связь от пользователей

Было: support тикеты никто не анализирует

Стало: еженедельный обзор топ-10 тикетов + hypotheses для улучшений

Кейс: улучшение процесса в B2B SaaS

PM заметил: Sales постоянно просят фичи для конкретных клиентов, разработка не успевает, клиенты уходят.

Решение: процесс «Sales feature request»:

1. Sales заполняет форму (какой клиент, сколько revenue, когда нужно)

2. PM еженедельно разбирает запросы + приоритизирует

3. Топ-3 запроса идут в backlog, остальным — объяснение, почему нет

4. Sales видит статус в публичном Notion

Результат:
- Sales понимают приоритеты (не обижаются, когда их фича не взята)
- PM не отвлекается на каждый «срочный» запрос
- Разработка работает по плану

Итоги 60 дней: Презентация прогресса

В конце 60-го дня сделайте письменный отчёт + встречу с руководителем.

Структура отчёта:

# Отчёт за 60 дней

## Достижения
1. Quick win 1: [результат] — [метрика до/после]
2. Quick win 2: ...
3. Процессы: [что улучшили]

## Квартальный план
- Роадмап согласован с [список стейкхолдеров]
- Команда committed на цели
- Начали работу над [первая инициатива]

## Обратная связь от команды
- [Цитата от разработчика]
- [Цитата от дизайнера]
- [Отзыв от Sales/Support]

## Следующие 30 дней
- Цель 1: [какую метрику двигаем]
- Цель 2: ...

## Где нужна помощь
- [Блокер 1]
- [Вопрос для решения]

Цель отчёта: Показать, что вы не только делаете, но и измеряете результаты + думаете наперёд.

Дни 61-90: Lead (Вести)

Цель третьего месяца

К концу 90-го дня вы должны показать, что можете вести продукт самостоятельно:

1. Измеримое влияние на метрики (хотя бы +5-10% к ключевой метрике)

2. Стратегическое мышление (видите не только задачи, но и долгосрочное направление)

3. Лидерство (команда и стейкхолдеры доверяют вашим решениям)

Неделя 9-11: Запуск ключевой инициативы

Выберите одну инициативу из роадмапа, которая:
- Даст измеримый результат до конца испытательного срока
- Покажет ваши навыки (discovery → delivery → measurement)
- Не слишком рискованная (не сломает продукт)

Пример выбора инициативы:

Плохой выбор: «Полный редизайн приложения»
- Слишком долго (не успеете до конца 90 дней)
- Слишком рискованно (можно сломать UX)
- Сложно измерить (что считать успехом?)

Хороший выбор: «Улучшить onboarding новых пользователей»
- Можно запустить за 3-4 недели
- Измеримо (D7 retention, activation rate)
- Итеративно (можно тестировать гипотезы)

Фазы запуска:

Фаза 1: Discovery (неделя 9)
- Проблема: только 40% новых пользователей доходят до ключевого действия
- Гипотеза: onboarding слишком длинный (7 шагов) + непонятная ценность продукта
- Исследование: 10 интервью с новичками + анализ воронки
- Решение: сократить до 3 шагов + добавить видео-туториал

Фаза 2: Design & Prototype (неделя 10)
- Дизайнер делает новый флоу
- Показать 5 пользователям → собрать обратную связь
- Итерация по фидбеку

Фаза 3: Development (неделя 11)
- Разработка делает implementation
- QA тестирует
- Подготовить A/B-тест (50% пользователей видят новый onboarding)

Фаза 4: Launch & Measure (неделя 12)
- Запуск A/B-теста
- Мониторинг метрик каждый день
- Если результат положительный (статистически значимый) → раскатка на 100%

Кейс: улучшение onboarding в SaaS

Junior PM запустил новый onboarding:
- Было: 7 шагов, 40% завершают
- Стало: 3 шага, 65% завершают (+62% к conversion!)

Дополнительный эффект:
- Снижение support тикетов «Как начать пользоваться?» на 30%
- Увеличение D7 retention с 45% до 52%

К концу испытательного срока PM показал слайд с графиком «до/после» → руководство в восторге.

Неделя 12: Стратегическая презентация

Задача: Показать, что вы думаете не только о тактике (задачи на неделю), но и о стратегии (направление на год).

Подготовьте документ «Product vision & strategy»

Структура:

# Product Vision & Strategy: [Продукт]

## Vision (Видение на 2-3 года)
Чем мы хотим стать для наших пользователей?

Пример: «Мы хотим стать главным инструментом для [целевая аудитория], который помогает [главная ценность] лучше, чем любая альтернатива.»

## Current State (Где мы сейчас)
- Пользователи: [количество, сегменты, география]
- Метрики: [ключевые показатели]
- Проблемы: [топ-3 боли пользователей]
- Конкуренты: [кто и чем лучше нас]

## Strategy (Как придём к vision)

### Цели на год
1. [Метрика] с X до Y
2. [Метрика] с X до Y
3. Запустить [новое направление]

### Ключевые инициативы
**Pillar 1: [Название]** (40% ресурсов)
- Почему: [обоснование]
- Что: [что будем делать]
- Результат: [ожидаемый эффект]

**Pillar 2: ...** (35% ресурсов)
**Pillar 3: ...** (25% ресурсов)

### Что НЕ делаем (trade-offs)
- [Направление 1]: отложено до [когда], потому что [причина]
- [Направление 2]: ...

## Risks & Dependencies
- Риск 1: [что может пойти не так] → [как митигируем]
- Зависимость 1: [от кого зависим] → [план B]

## Success Metrics
Как поймём, что стратегия работает?
- Ежеквартально: [метрики]
- Ежемесячно: [leading indicators]

Презентация стратегии (для руководства):

Не просто отправьте документ — защитите его на встрече.

Ожидайте tough questions:
- «Почему не фокусируемся на [другое направление]?»
- «Конкурент X делает иначе, почему мы не копируем?»
- «Эти цели слишком амбициозные / недостаточно амбициозные»

Как отвечать:
- Покажите данные (user research, метрики, анализ конкурентов)
- Объясните trade-offs («Если будем делать X, то не успеем Y»)
- Будьте гибкими («Отличная мысль, давайте добавлю в план исследования»)

Итоги 90 дней: Финальная презентация

Это ваш «выпускной экзамен». Подготовьте встречу с руководителем + ключевыми стейкхолдерами.

Структура презентации (45 минут):

Слайд 1-3: Journey (Путь за 90 дней)
- Что узнал о продукте, пользователях, рынке
- Ключевые инсайты (покажите цитаты пользователей, графики метрик)

Слайд 4-7: Achievements (Достижения)
- Quick wins: [список] → [метрики до/после]
- Ключевая инициатива: [название] → [результат с графиком]
- Процессы: что улучшили в работе команды

Слайд 8-10: Impact (Влияние на бизнес)
- Как изменились ключевые метрики за 90 дней
- Revenue impact (если есть)
- Качественная обратная связь (NPS, отзывы пользователей)

Слайд 11-15: Strategy (Стратегия на следующий квартал)
- Куда двигаемся дальше
- Топ-3 приоритета
- Roadmap на Q2

Слайд 16: Lessons Learned (Что я узнал)
- Что сработало хорошо
- Что бы сделал иначе
- Где мне нужна поддержка

Слайд 17: Thank you
- Благодарность команде и руководству

Цель презентации: Показать, что вы:
1. Быстро учитесь
2. Делаете результаты
3. Думаете стратегически
4. Рефлексируете (понимаете свои ошибки)

Специфика для разных уровней

Для Junior PM (первая позиция в продукте)

Дополнительные задачи:

Первые 30 дней:
- Попросить mentor (senior PM в компании) для еженедельных 1:1
- Изучить основы: что такое North Star метрика, как считать retention, что такое product-market fit
- Больше времени на изучение продукта (не стесняйтесь задавать «глупые» вопросы)

Quick wins:
- Фокус на операционных улучшениях (документация, процессы)
- Не беритесь за стратегические инициативы сразу
- Примеры: улучшить onboarding документацию, автоматизировать отчёт, исправить UX-баги

Метрики успеха:
- Вы освоили базовые инструменты (аналитика, Jira, Figma)
- Вы понимаете, как работает продукт (можете объяснить любую фичу)
- Команда вас уважает (разработчики не игнорируют ваши сообщения)

Чего от вас НЕ ждут:
- Глобальной стратегии (вы пока учитесь)
- Сложных A/B-тестов и статистики
- Управления большими проектами

Главная опасность: Синдром самозванца («Я ничего не знаю, меня скоро выгонят»). Это нормально! Все junior PM через это проходят.

Для Middle PM (опыт 2-4 года)

Дополнительные задачи:

Первые 30 дней:
- Быстрее погружайтесь в метрики (вы уже знаете, что такое retention и cohorts)
- Сравните процессы с прошлой компанией (но не критикуйте открыто!)
- Найдите «белые пятна» — области, которыми никто не занимается

Quick wins:
- Можете браться за более сложные задачи (A/B-тесты, интеграции)
- Покажите опыт (но не хвастайтесь «а вот в моей прошлой компании...»)
- Примеры: запустить reactivation campaign, улучшить метрику на 10-15%, настроить новый канал acquisition

Метрики успеха:
- Вы самостоятельно ведёте track в роадмапе (без микроменеджмента)
- Вы влияете на метрики (не просто «сделали фичу», а «подняли retention»)
- Стейкхолдеры доверяют вашим решениям (не требуют каждое решение согласовывать)

Чего от вас ждут:
- Самостоятельности (не нужно держать за руку)
- Инициативы (вы сами предлагаете, что улучшить)
- Баланса между тактикой и стратегией

Главная опасность: Переоценить свой опыт («В прошлой компании это работало, значит, сработает и здесь»). Каждый продукт уникален!

Для Senior PM (опыт 5+ лет)

Дополнительные задачи:

Первые 30 дней:
- Смотрите на продукт глазами CEO: как это влияет на бизнес?
- Оценивайте не только продукт, но и организацию (правильно ли устроена команда? Есть ли продуктовая культура?)
- Готовьтесь влиять на стратегию компании, а не только вашего продукта

Quick wins:
- Системные улучшения (не одна фича, а процесс, который даст много фич)
- Наставничество (помогите junior PM в компании)
- Примеры: выстроить product discovery процесс, создать data-driven культуру, запустить experimentation framework

Метрики успеха:
- Вы влияете на product vision компании
- Вы управляете другими PM (формально или неформально)
- Ваши решения влияют на revenue и бизнес-метрики топ-уровня

Чего от вас ждут:
- Лидерства (не просто делать, а вести команду и компанию)
- Стратегического мышления (видеть на 6-12 месяцев вперёд)
- Сложных trade-offs (убить фичу, которую любит CEO, ради long-term здоровья продукта)

Главная опасность: «Я senior, я знаю лучше» → игнорирование контекста и мнений команды. Даже senior PM должен слушать.

Типичные ошибки на испытательном сроке

Ошибка 1: Слишком много анализа, мало действий

Симптомы:
- Вы провели 50 user interviews, но ничего не запустили
- У вас 100-страничный документ с исследованием, но нет плана действий
- К концу испытательного срока вы говорите: «Я ещё изучаю продукт»

Почему это опасно:
Руководство думает: «Зачем мы наняли аналитика? Нам нужен человек, который делает.»

Как исправить:
- Правило: каждое исследование должно вести к action (гипотеза → проверка → решение)
- Установите себе дедлайн: «К концу 4-й недели я должен предложить 3 quick wins»
- Думайте 80/20: лучше сделать «хорошо» за 2 недели, чем «идеально» за 2 месяца

Ошибка 2: Слишком много действий, мало контекста

Симптомы:
- Вы запустили 5 фич за первый месяц, но ни одна не дала результата
- Команда жалуется: «Ты не спросил нас, мы бы сказали, что это не сработает»
- Пользователи в шоке: «Зачем вы изменили то, что работало?»

Почему это опасно:
Вы теряете доверие команды и пользователей. Вас воспринимают как «разрушителя».

Как исправить:
- Правило: первые 30 дней — только изучение + микро-улучшения (bug fixes, UX polish)
- Любое изменение обсуждайте с командой ДО реализации
- Запускайте A/B-тесты, а не «меняйте для всех сразу»

Ошибка 3: Игнорирование стейкхолдеров

Симптомы:
- Вы не встретились с Sales/Support за первый месяц
- CEO узнал о вашем роадмапе из письма, а не от вас лично
- CTO удивлён, что вы запланировали фичу, требующую серьёзной архитектурной работы

Почему это опасно:
Вы создаёте врагов. Даже если ваши решения правильные, их саботируют.

Как исправить:
- Создайте карту стейкхолдеров в первую неделю
- Еженедельно обновляйте ключевых людей (короткое письмо или 15-минутная встреча)
- Спрашивайте feedback ДО финализации планов: «Что ты думаешь о таком подходе?»

Ошибка 4: Обещать и не делать

Симптомы:
- На первой неделе вы сказали: «Исправлю этот баг за 2 дня» → прошёл месяц, баг остался
- Вы обещали CEO запустить фичу к концу квартала → не запустили
- Команде обещали «сократить встречи» → встреч стало ещё больше

Почему это опасно:
Доверие теряется быстро, восстанавливается медленно. После 2-3 невыполненных обещаний вас перестают воспринимать серьёзно.

Как исправить:
- Не обещайте то, что не контролируете
- Добавляйте буфер: если думаете «2 недели», говорите «3-4 недели»
- Если не успеваете — предупреждайте заранее, а не в последний день

Ошибка 5: Игнорирование команды разработки

Симптомы:
- Разработчики избегают вас
- На планировании вас «посылают» («Это невозможно сделать»)
- Вы узнаёте о проблемах последним

Почему это опасно:
Без команды вы не PM. Вы просто человек с красивыми слайдами.

Как исправить:
- Первые 30 дней: больше слушайте, меньше говорите
- Покажите, что вы уважаете их экспертизу («Как ты думаешь, это реализуемо?»)
- Защищайте их от бизнеса («Нет, мы не будем менять приоритеты в середине спринта»)

Ошибка 6: Копировать «лучшие практики» без адаптации

Симптомы:
- «В Google делают вот так, давайте и мы»
- «Давайте внедрим OKR / RICE / [модный фреймворк]»
- Команда сопротивляется: «У нас другая ситуация»

Почему это опасно:
То, что работает в Google, может не работать в стартапе на 20 человек. Контекст важнее процесса.

Как исправить:
- Адаптируйте, не копируйте
- Спросите команду: «Что НЕ работает в текущих процессах?» → улучшите это
- Начинайте с маленьких экспериментов («Давайте попробуем на одном спринте»)

Чек-листы на каждый период

Чек-лист: Первые 30 дней

Неделя 1:
- ☐ Встреча с руководителем (ожидания, обратная связь, формат работы)
- ☐ Знакомство с командой (имена, роли, зоны ответственности)
- ☐ Получить доступы (аналитика, код, документация, коммуникация)
- ☐ Использовать продукт как пользователь (пройти onboarding с нуля)
- ☐ Найти onboarding buddy

Неделя 2:
- ☐ Провести 10-15 интервью с пользователями (active, new, churned)
- ☐ Встретиться с ключевыми стейкхолдерами (CEO, CTO, Sales, Support)
- ☐ Изучить метрики (North Star, конверсия, retention, churn)
- ☐ Прочитать роадмап и post-mortems

Неделя 3:
- ☐ Понять техническую архитектуру (схема сервисов, технический долг)
- ☐ Участвовать в процессах команды (standups, planning, retro)
- ☐ Начать собирать список quick wins

Неделя 4:
- ☐ Создать документ «30-day insights»
- ☐ Презентовать руководителю
- ☐ Договориться о приоритетах на 30-60 дней

Чек-лист: Дни 31-60

Неделя 5-6:
- ☐ Выбрать 2-3 quick wins
- ☐ Запустить первый quick win
- ☐ Показать первые результаты (метрики или фидбек)

Неделя 7:
- ☐ Провести приоритизацию backlog (RICE/ICE)
- ☐ Создать квартальный роадмап
- ☐ Получить feedback от команды на роадмап
- ☐ Презентовать роадмап стейкхолдерам

Неделя 8:
- ☐ Улучшить хотя бы один процесс команды
- ☐ Запустить второй quick win
- ☐ Написать отчёт за 60 дней

Чек-лист: Дни 61-90

Неделя 9-11:
- ☐ Выбрать ключевую инициативу для запуска
- ☐ Провести discovery (исследование, гипотезы)
- ☐ Разработка и QA
- ☐ Запуск (A/B-тест или полный rollout)

Неделя 12:
- ☐ Измерить результаты инициативы
- ☐ Создать документ «Product vision & strategy»
- ☐ Подготовить финальную презентацию
- ☐ Провести встречу с руководством (итоги 90 дней)

Шаблоны и инструменты

Шаблон: Еженедельный отчёт руководителю

# Weekly update: [Дата]

## 🎯 Главное за неделю
[1-2 предложения: что сделали, какой результат]

## ✅ Что сделано
- [Задача 1] → [статус/результат]
- [Задача 2] → [статус/результат]
- [Задача 3] → [статус/результат]

## 📊 Метрики (если есть изменения)
- [Метрика]: [значение] ([↑↓] X% vs прошлая неделя)

## 🚧 Блокеры / Нужна помощь
- [Проблема] → [что нужно для решения]

## 📅 План на следующую неделю
- [Задача 1]
- [Задача 2]
- [Задача 3]

Почему это работает:
- Короткий (читается за 2 минуты)
- Фокус на результатах, а не на действиях
- Показывает проблемы (вы не скрываете сложности)

Шаблон: 1:1 с членом команды

Частота: Каждые 2 недели, 30 минут

Структура:
1. Как дела? (5 мин) — не формальность, а реальный интерес
2. Что тебя сейчас беспокоит? (10 мин) — дать выговориться
3. Что я могу сделать, чтобы тебе работалось легче? (10 мин) — помочь убрать блокеры
4. Обратная связь для меня (5 мин) — «Что я делаю хорошо / что могу улучшить?»

Что НЕ делать на 1:1:
- Обсуждать статус задач (это для стендапа)
- Критиковать при других людях
- Игнорировать обратную связь («Ты не прав»)

Инструменты для работы

Для управления backlog:
- Jira / Linear / Asana
- Notion (для документации и гипотез)

Для аналитики:
- Amplitude / Mixpanel (product analytics)
- Google Analytics / Metabase (web analytics)
- Looker / Tableau (BI для deep dive)

Для исследований:
- Dovetail (хранение user interviews)
- Miro / FigJam (customer journey maps)
- Typeform / Google Forms (опросы)

Для коммуникации:
- Slack / Teams (async communication)
- Loom (видео-объяснения вместо встреч)
- Notion / Confluence (документация)

Итоговые рекомендации: формула успеха

Формула успешного испытательного срока:

Успех = (Понимание контекста × Quick wins × Доверие команды) / Ego

Расшифровка:

1. Понимание контекста — вы не можете принимать хорошие решения, не зная, как устроен продукт, бизнес, пользователи. Первые 30 дней критичны.

2. Quick wins — вы должны показать результаты быстро. Не ждите 90 дней, чтобы «запустить что-то большое». Маленькие победы важнее.

3. Доверие команды — если команда вас не уважает, вы не PM. Всё время стройте доверие через действия, а не слова.

4. Ego — чем больше ваше эго («Я senior, я знаю лучше»), тем меньше шансов на успех. Оставьте эго за дверью.

Что делать в последнюю неделю испытательного срока:

1. Попросите обратную связь у всех (руководитель, команда, стейкхолдеры)

2. Подготовьте финальную презентацию (достижения, планы, что узнали)

3. Будьте готовы к tough conversation (если что-то пошло не так, обсудите честно)

4. Покажите энтузиазм («Я хочу продолжать работать здесь»)

Три вопроса для самопроверки:

К концу 90 дней спросите себя:

1. Влияние: Могу ли я показать хотя бы одну метрику, которая улучшилась благодаря мне?

2. Доверие: Если бы команда голосовала, хотят ли они, чтобы я остался, — сколько % проголосуют «да»?

3. Стратегия: Если меня спросят «Куда двигаться продукту на следующий год», есть ли у меня обоснованный ответ?

Если на все три вопроса ответ «да» — вы прошли испытательный срок. Если «нет» — вы знаете, над чем работать.

Следующий шаг после прочтения:

Не откладывайте. Если вы на испытательном сроке прямо сейчас:

1. Откройте календарь

2. Запланируйте 3 встречи на эту неделю: с руководителем, с ключевым разработчиком, с 1 пользователем

3. Создайте документ «30/60/90 plan» и заполните хотя бы первую неделю

Действие важнее планирования. Удачи! 🚀

P.S. Ищете работу продакт-менеджером? На HireHi собраны вакансии для junior, middle и senior PM с реальными зарплатами и прямыми контактами работодателей