Почему не можешь делегировать передачу бумаг подчиненным?

Почему передачу бумаг (документации) нельзя полностью делегировать подчиненным

Это отличный вопрос о распределении ответственности PM. Короткий ответ: можно делегировать исполнение, но не стратегию и одобрение. Объясню почему.

1. PM отвечает за видение и стратегию

Документация — это не просто бумага:

• PRD (Product Requirements Document) содержит стратегию решения проблемы
• Это представляет видение PM, как мы собираемся решить потребность пользователя
• Подчиненный не может решить, правильное это видение или нет

Пример:

• Проблема: юзеры не создают проекты
• PM видит: причина в сложности формы (гипотеза)
• Подчиненный видит: может быть, люди не нужны проекты (другая гипотеза)
• PRD должен быть написан PM, чтобы выбрать правильное направление

2. Документация — коммуникационный инструмент PM

PRD/документация служит для:

• Выравнивания понимания с инженерами
• Выравнивания с дизайнерами
• Выравнивания с лидерством
• Выравнивания с marketing

Почему это должен делать PM:

• PM отвечает за то, чтобы все поняли видение
• Если подчиненный писал, PM все равно должен проверить и одобрить
• Лучше PM сам написал минимум главное (видение, стратегия, метрики)

3. Какую часть МОЖНО делегировать

Что можно делегировать:

• Ресёрч информации (например, конкурентный анализ)
• Форматирование и структурирование (сделать красивый документ)
• Сбор требований от stakeholders (но не фильтрацию)
• Написание деталей юз-кейсов (примеры, описания)
• Создание прототипов в Figma (если junior PM)

Что нельзя делегировать:

• Определение проблемы (why we're building this)
• Выбор решения (what we're building)
• Определение успеха (как мы это измеряем)
• Приоритизация требований
• Одобрение документации

4. Иерархия владения документацией

Правило в большинстве компаний:

Senior PM → пишет видение, стратегию, измерение успеха
Junior PM / APM → пишет деталь требований, юз-кейсы
Product Analyst → пишет метрики, success criteria
Designer → пишет UX требования, дизайн рациональ
Engineering Lead → пишет technical requirements

Но финальная одобрение: Senior PM на все это смотрит и говорит "да, это правильно"

5. Пример из моей практики

На InsightHub, когда был растущий PM:

• У меня была новая APM (Associate Product Manager)
• Я попросил её написать PRD для новой фичи
• Она написала все детали: юз-кейсы, примеры, интеграции
• Но видение (зачем нам это делать, почему это важно) я написал сам
• Я переписал первый раздел (vision), и она согласилась

Результат:

• APM быстро научилась писать документацию
• Но она поняла, что видение — это не её роль
• Она стала отличным писателем деталей
• Я остался ответственным за стратегию

6. Риск полной делегации

Если делегировать всё (видение + детали):

• Подчиненный может не понять контекст
• Документация будет неполной или неправильной
• Инженеры получат неправильное видение
• Проект пойдет в неправильном направлении
• PM потеряет ownership над собственным видением

Реальный пример из стартапа:

• Junior PM написал PRD для нового feature
• Не включил достаточно контекста о том, почему это важно
• Инженеры реализовали буквально что было написано, но неправильно
• 2 недели разработки потрачены впустую
• PM (senior) потом переписал весь PRD

7. Как правильно делегировать

Лучший подход:

1. PM пишет vision + success metrics (15-20% времени)
2. Дает подчиненному контекст: "Вот видение, вот метрики успеха"
3. Просит написать детали: юз-кейсы, примеры, требования (80% времени)
4. Пересматривает, дает feedback, правит видение если нужно
5. Финальная версия — одобрена PM

Это похоже на:

• Архитектор рисует план здания
• Инженер рисует детали (количество окон, размер комнат)
• Архитектор проверяет, что окна не нарушают стены

8. Масштабирование с несколькими PM

На больших продуктах:

• У вас есть Senior PM (стратегия)
• У вас есть Mid PM (видение для своего area)
• У вас есть Junior PM / APM (детали)

Иерархия:

VP Product
├── Senior PM (стратегия, roadmap)
├── Mid PM (видение для feature area)
├── Junior PM (детали требований)
└── Analyst (метрики, success criteria)

Каждый уровень одобряет следующий:

• VP Product одобряет Senior PM видение
• Senior PM одобряет Junior PM детали

9. Когда это может работать

Полная делегация может работать, если:

• Подчиненный очень опытный (senior engineer писать требования лучше PM)
• PM полностью доверяет и регулярно пересматривает
• Есть четкие критерии "хорошей документации"
• Есть система feedback и итерации

Но даже в этом случае:

• PM должен одобрить финальный вариант
• PM остается ответственным перед лидерством

10. Отличие от других задач

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

• Распланировать встречи (делегируй помощнику)
• Вести notes в Jira (делегируй кому-то еще)
• Подготовить данные для анализа (делегируй аналитику)
• Напланировать тесты (делегируй QA)

Почему документация отличается:

• Это воплощение видения PM
• Это стратегический документ, не просто координационный
• PM отвечает перед инженерами и лидерством за содержание

Заключение

Документация (видение + стратегия) — это heart of PM роли. Можно делегировать исполнение и детали, но не стратегию и одобрение. Senior PM должен всегда иметь в голове полную картину. Лучший способ — написать видение сам, потом привлечь подчиненного для деталей. Это и развивает его, и сохраняет качество документации.