Был ли кейс в команде по расхождению с твоим мнением о приоритезации

Кейс расхождения в приоритезации: реальный пример

Да, было. Это идеальный пример как я управляю конфликтом мнений в команде. Расскажу реальный кейс.

Ситуация

Мы работали на SaaS платформе для управления проектами. У нас была бэклог из 15 потенциальных фич на квартал. Мой рекомендуемый top-3 был: Улучшение поиска, Integration с Slack, Dark mode.

Лид инженеров настаивал на другом: Tech debt cleanup, Performance optimization, API redesign.

Моя рекомендация была основана на user interviews где пользователи просили: better search, Slack integration. Dark mode был nice-to-have но несколько users просили.

Лид инженеров был прав что tech debt растет и это замедляет разработку. Но он хотел потратить 8 недель на это когда я думал что 2-3 недели достаточно.

Как это началось

На planning meeting я presented мои 3 приоритета с data: user feedback, search queries analysis, Slack integration requests. Я показал что 40% tickets about search, 30% хотели Slack integration, 15% попросили dark mode.

Лид инженеров не согласился. Он сказал что без tech debt cleanup, next quarter мы будем еще медленнее. Он был технически прав.

Но я видел что мы потеряем монементум если не дадим users что они просят.

Как я разрешил

Шаг 1: Слушал

Вместо защиты я спросил: почему именно это нужно? Он объяснил что код base становится unmaintainable, new features take longer, bugs multiply. Я увидел что это legitimate concern.

Шаг 2: Проанализировал его numbers

Я спросил: сколько именно это займет? Он сказал 8 недель. Я спросил: сколько производительности мы получим после? Он сказал maybe 20-30% faster development.

Шаг 3: Нашел компромисс

Я предложил: What if мы делаем 50/50 split? 5 недель на tech debt, 5 недель на user features (search + Slack integration). Dark mode на next quarter.

Шаг 4: Добавил incentive

Я сказал: Если мы делаем tech debt cleanup, search и Slack integration будут легче реализовать потом. Это win-win. Tech debt cleanup делает foundation solid, потом features быстрее.

Шаг 5: Documented decision

Мы написали в shared doc: Why мы выбрали 50/50 split. Какие assumptions. Какие metrics мы будем трекировать.

Результат

5 недель на tech debt cleanup. Потом 5 недель на search redesign и Slack integration.

Результат был лучше чем я ожидал:

• Tech cleanup действительно ускорил разработку
• Search feature разработана за 2 недели вместо estimated 3
• Slack integration за 1.5 недели вместо 2
• У нас осталось 1.5 недели в конце квартала для дополнительного polish

Так что лид инженеров был прав что tech debt важен. И я был прав что users нуждаются в features.

Лид инженеров later сказал: I appreciate that you listened. Usually PMs just push features. You understood why tech debt matters.

Что я learned

1. Обе стороны были right. User needs AND code quality важны.
2. No perfect solution. Только trade-offs.
3. Data helps. Когда я показал user data, инженеры уважали.
4. Listening more important than talking.
5. Long-term thinking. Комбинация tech cleanup + features был better.

Как это changed мой approach

Теперь я automatically include engineers в user research. Когда they understand why users need something, they buy-in better.

Также я respect когда engineering говорит что tech debt нужен. Не все features нужны, не все cleanup нужен. But prioritizing right combination это art.

Теперь мы have process: каждый квартал we have slot для technical improvements. 20% бюджета. Это prevent situation где tech debt completely ignored.

Финальный совет

Когда есть разногласие в приоритезации, это не конфликт между person'ями. Это разные perspective на same problem. PM видит customer side. Engineering видит technical side. PM должен bridge these views. Не win over them, но find path that respects both. Лучший solution часто это compromise что создает WIN-WIN.