Какая была конфликтная ситуация в работе?

Конфликтная ситуация: столкновение видения и данных

Время: начало 2022 года, SaaS-платформа для аналитики маркетинга. Эта ситуация научила меня многому о управлению конфликтами в tech-среде.

Контекст конфликта

Участники:

• Я (Product Manager)
• Тим Разработки (8 человек, lead — опытный tech architect)
• Маркетинг (Head of Marketing с 15-летним опытом)
• Финансы/Бизнес

Суть конфликта: Маркетинг настаивал на срочном выпуске новой feature для экспорта данных в Excel (якобы топ-1 запрос от клиентов). Требовал launch через 2 недели. Разработка говорила: «Это потребует 4–6 недель, потому что нужна переработка архитектуры». Финансы били тревогу, что срыв deadline убьёт квартальные бизнес-цели.

Почему это был конфликт

Позиции сторон:

1. Маркетинг: Клиентов уходят к конкурентам, которые уже это сделали. Excel — базовая фишка. Нельзя ждать 6 недель.
2. Разработка: Если напихаём фишку за 2 недели, она будет нестабильной, сломает остальное. Нужен правильный подход.
3. Финансы: Каждая задержка — минус X000 долларов потерянного дохода.
4. Я (PM): Должен был примирить всех, но данных было недостаточно.

Как я это разрешил

Фаза 1 — Остановка и анализ (1 день): Вместо того, чтобы занять сторону, я предложил 24-часовую паузу для сбора фактов:

• Попросил маркетинг принести конкретные данные: сколько клиентов просили Excel-экспорт, какой процент это от всей базы?
• Попросил разработку детально разобрать, что именно требует 4–6 недель, можно ли что-то упростить
• Запросил у финансов: какой реальный impact задержки на 2–3 недели?

Фаза 2 — Факты на стол (день 2): Результаты:

• Маркетинг признал: запросы были, но от 15–20 клиентов из 400+, не от всех
• Разработка разделила задачу: можно сделать MVP за 10 дней (простой Excel, ограничений), затем polish за ещё 2 недели
• Финансы согласились: задержка на 2–3 недели критична, но срыв стабильности платформы — катастрофа

Фаза 3 — Компромисс (реальное решение):

1. MVP-подход: Запускаем упрощённый экспорт через 10 дней — это удовлетворяет основной спрос
2. Честная коммуникация с клиентами: Маркетинг информирует клиентов, что фишка в бета, ограничения известны
3. Второй волна: Через 3–4 недели улучшенная версия
4. Метрики успеха: Отслеживаем, скільки клиентів реально используют MVP, не ушли ли они к конкурентам

Что я сделал правильно

✓ Не выбрал сторону сразу — если бы я сказал «маркетинг прав» или «разработка прав», потерял бы доверие одной стороны ✓ Запросил данные, не мнения — спросил про клиентов, метрики, риски, а не просто слушал выкрики ✓ Предложил компромисс, устраивающий обе стороны — MVP удовлетворил маркетинг (быстро), разработку (качественно) ✓ Вовлёк всех в решение — они сами пришли к MVP-идее, а не я навязал ✓ Установил метрики успеха — потом смотрели, сработало ли или нет

Что я выучил

1. Конфликты в tech — это нормально. Разработчики хотят качества, маркетинг — скорости. Обе позиции правильные.
2. Данные решают конфликты лучше, чем авторитет. Факты о клиентах, метрики продакта, риски — вот на чём строить решения.
3. PM — посредник, не диктатор. Моя роль не в том, чтобы приказать, а в том, чтобы найти решение, которое работает для бизнеса.
4. MVP спасает. Вместо долгих дебатов, we shipped something, узнали правду и итерировали.

Итог: MVP запустили через 10 дней, маркетинг был доволен, разработка — тоже, и потом фишка переросла в полнофункциональный модуль, который стал конкурентным преимуществом.