Как выстраиваются отношения со stakeholders?

Выстраивание отношений со stakeholders: стратегия доверия

Почему отношения со stakeholders — это основа PM

PM — это не технический роль. Это роль политика, дипломата и лидера. 80% успеха зависит от того, насколько хорошо ты понимаешь интересы разных сторон и можешь их согласовать. Плохие отношения = продукт падает, даже если техника идеальна.

1. Определение stakeholders

Сначала нужно понять, кто влияет на твой продукт:

Внутренние stakeholders:

• CEO/Founder (стратегия, деньги, контроль)
• CTO/Tech Lead (выполнимость, архитектура, риски)
• Head of Design (юзабилити, бренд, красота)
• Sales/Growth (как продать, какие фичи продают)
• Finance (бюджет, ROI, расходы)
• HR (найм, retention инженеров)

Внешние stakeholders:

• Клиенты (платят деньги, хотят результат)
• Инвесторы (хотят growth, exit)
• Партнеры (интеграции, колаборации)
• Конкуренты (не напрямую, но влияют на стратегию)

Для каждого stakeholder я создаю профиль:

Имя: CTO
Интересы: масштабируемость, техдолг, архитектура
Опасения: быстрый рост → качество падает
Мощь: может заблокировать фичу, если архитектура не подойдёт
Интерес в продукте: ВЫСОКИЙ (его команда строит)
Стиль общения: любит данные, не любит слова

2. Матрица stakeholder'ов

Не все stakeholder'ы одинаковы. Некоторых нужно убеждать, некоторых просто уведомлять.

        HIGH POWER
        |
   II   |    I
 CONSULT| MANAGE
        |
--------+--------
        |
   IV   |   III
 MONITOR| KEEP SATISFIED
        |
      LOW INTEREST

Quadrant I (Manage) — высокая власть, высокий интерес

• CEO, CTO, Head of Sales
• Вовлекай активно, согласовывай решения, слушай

Quadrant II (Consult) — низкая власть, высокий интерес

• Дизайнеры, часть инженеров
• Проси мнение, но решение принимаешь ты

Quadrant III (Keep Satisfied) — высокая власть, низкий интерес

• CFO (если только в бюджете не заложено)
• Инвесторы (если не в переговорах раунда)
• Регулярно обновляй, покажи, что всё хорошо

Quadrant IV (Monitor) — низкая власть, низкий интерес

• Сторонние консультанты
• Просто держи в курсе

3. Основные принципы построения доверия

Принцип 1: Прозрачность

Никогда не скрывай проблемы. Если проект отстаёт на 2 недели, скажи об этом сейчас, а не за день до дедлайна.

Плохо:

• Неделю 1-3: всё хорошо (врёшь себе)
• Неделя 4: Ой, у нас проблема! (паника)

Хорошо:

• Неделя 1: Вижу, что сложнее, чем ожидали
• Неделя 2: Скорее всего отстанем на неделю
• Неделя 3: Мы выбираем между качеством и сроками, вот варианты

Принцип 2: Доставить на то, что обещал

Лучший способ потерять доверие — не доставить фичу к дедлайну без объяснения.

Правило 80%: обещай 80% того, что можешь. Остальные 20% = буфер для неожиданностей.

Принцип 3: Понять интересы stakeholder'а, не только свои

CEO хочет growth? Покажи, как твоя фича ускорит acquisition. CTO волнуется о tech debt? Объясни, как твой подход уменьшит нагрузку на архитектуру.

4. Техники работы с разными stakeholder'ами

Работа с CEO

CEO — твой главный stakeholder. Без его поддержки ничего не будет.

Еженедельная синхронизация (30 минут):

• Top 3 wins за неделю
• Top 3 risks/проблемы
• Что нужно от CEO (решение, ресурсы, одобрение)

Язык CEO:

• Growth, retention, LTV, чистокупоны
• Не говори про архитектуру, говори про результаты

Пример плохо:

• "Мы переписали backend с REST на GraphQL"

Пример хорошо:

• "Переписав backend, мы ускорили API на 3x. Это означает, что мобильные пользователи будут видеть данные на 500ms быстрее, что должно улучшить retention на 2-3%"

Работа с CTO

CTO — твой соратник. Если CTO и PM враги, продукт падает.

Еженедельная синхронизация (30 минут):

• Детали архитектуры новых фич
• Tech debt: куда его отложим?
• Bottleneck'и и performance

Язык CTO:

• Архитектура, масштабируемость, debt, complexity
• Приводи аргументы, основанные на числах

Пример плохо:

• "Нам срочно нужна фича X, залей её как можно быстрее"

Пример хорошо:

• "Нам нужна фича X. Я оцениваю её как 3 недели. У нас есть 2 недели до запуска. Давайте обсудим: можем ли мы урезать scope, или нужно сдвинуть дедлайн? Или может быть, есть способ запустить MVP за неделю, а остальное позже?"

Работа с Sales

Sales приносит деньги. Если Sales недоволен, компания падает.

Ежемесячная синхронизация (1 час):

• Какие фичи Sales чаще просят у клиентов?
• На какие возражения натыкается Sales?
• Какие конкуренты выигрывают в сделках?

Язык Sales:

• Сделки, ROI, конкурентное преимущество
• "Если мы запустим фичу X, это откроет нам 5 крупных сделок на $100k"

5. Инструменты для управления отношениями

Stakeholder Meeting Calendar

Понедельник
- 10:00 — Синхронизация с CTO (технология)
- 11:00 — Синхронизация с Design Lead (UX)

Вторник
- 14:00 — Синхронизация с CEO (стратегия)

Четверг
- 10:00 — Синхронизация с Sales (рынок)
- 15:00 — Demo для инвесторов (если нужно)

Shared Document

Одна Google Sheet со статусом всех проектов:

Проект | Статус | Progress | Блокеры | DRI | Дедлайн
------|--------|----------|---------|-----|--------
Feature A | On Track | 60% | Нет | PM | 28 Mar
Feature B | At Risk | 30% | Ждём API от партнёра | Tech Lead | 14 Apr
Bug Fix C | Done | 100% | Нет | QA | Done

Этот документ видят все stakeholder'ы. Никаких сюрпризов.

Regular Demos

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

• Показываешь, что сделали
• Собираешь фидбек
• Объясняешь, что будет дальше

Это не для того, чтобы выглядеть молодцом. Это чтобы stakeholder'ы видели прогресс и чувствовали себя вовлёченными.

6. Конфликты со stakeholder'ами: как управлять

Сценарий: CEO хочет фичу X, CTO говорит, это невозможно

Правильный процесс:

1. Слушай обе стороны отдельно
2. Пойми истинные потребности
   • CEO: может быть, не нужна ровно X, а нужен результат Y?
   • CTO: может быть, нет архитектурного решения, но есть временное?
3. Предложи варианты
   • Вариант A: запустить MVP без X за 2 недели
   • Вариант B: запустить полную X за 6 недель
   • Вариант C: запустить X через интеграцию с 3rd-party за 3 недели
4. Дай обеим сторонам выбрать

Сценарий: два stakeholder'а хотят противоположное

Пример:

• Sales: "Нам нужна поддержка 100 платёжных методов, иначе потеряем сделку"
• CTO: "Это невозможно, архитектура не потянет, займёт 3 месяца"

Решение:

• Не выбирай сторону сразу
• Попроси Sales показать сделку (есть ли она реально?)
• Попроси CTO оценить: а если мы сделаем поддержку только 10 методов, покрывает ли это 80% сделок?
• Обычно ответ: да, 10 методов покрывают 80% сделок за 2 недели

7. Частые ошибки в работе со stakeholder'ами

❌ Скрывание проблем — stakeholder'ы чувствуют ложь ❌ Обещание, которое не можешь доставить — потеря доверия навсегда ❌ Игнорирование интересов stakeholder'а — они отомстят позже ❌ Нет коммуникации — люди выдумывают истории сами ❌ Частые изменения приоритетов без объяснения — путаница и недоверие

Итоговая система

1. Найди всех stakeholder'ов и их интересы
2. Помести их в матрицу (власть vs интерес)
3. Для каждого создай план коммуникации
   • Как часто общаться?
   • По какому каналу?
   • Какую информацию? Какой язык?
4. Расписание встреч
5. Shared document со статусом
6. Regular updates без ожидания вопросов
7. Быстрое разрешение конфликтов через диалог, не противостояние

Заключение

Отношения со stakeholder'ами — это не soft skills, это hard skills PM. Если ты хороший в приоритизации, но плохой в коммуникации, твой проект упадёт. Если ты хороший в коммуникации, даже плохой проект может выжить, потому что люди будут помогать тебе его улучшать.