Как принимать решения, когда интересы стейкхолдеров конфликтуют

Что делать, если все заинтересованные стороны по-своему правы Одна из сложных ситуаций в работе менеджера продуктов: когда в обсуждении вариантов решения каждый стейкхолдер приводит свои веские аргументы, конфликтующие друг с другом, — но нужно договориться. ➡️ Отдел продаж хочет добавить интеграцию с конкретной системой, потому что без нее крупный клиент не подпишет контракт. ➡️ Команда разработки говорит, что интеграция потребует серьезных изменений в архитектуре и создаст новую статью расходов на поддержку. ➡️ Менеджер продукта уже провел исследование среди действующих клиентов и считает, что ресурсы стоит вложить в другую проблему, которая касается большого сегмента пользователей. ➡️ CEO напоминает, что выход в сегмент, из которого пришел крупный заказчик, — одна из стратегических целей года. Решение предстоит принять, учитывая все аргументы, интересы и последствия. Что особенно важно при этом не упустить — рассмотрим ниже на примере. 1️⃣ Сначала разберитесь, что именно стоит за позицией участника Допустим, менеджер по продажам хочет закрыть сделку, чтобы выполнить KPI и закрыть свои личные финансовые нужды. В разработке треть команды уходит в отпуск, и ресурсов на быстрый запуск интеграции просто нет. Команда продукта уже прошла часть пути для повышения LTV действующих клиентов и не хочет бросать, пока есть возможность вовремя добавить востребованную функцию. А CEO делает на новый сегмент большую ставку из-за его платежеспособности — и надеется за счет этого вывести компанию на самоокупаемость, потому что привлекать инвестиции стало сложнее. 2️⃣ Сведите аргументы к общим критериям Когда каждая сторона защищает свою ценность, нужно привести аргументы к одному знаменателю — стоимости: 🔵 Каковы минимальные требования конкретного клиента и сколько ресурсов потребуется на разработку? 🔵 Какие технические последствия и статьи расходов создаст? 🔵 Какой коммерческий эффект ожидаем? 🔵 Можно ли использовать решение для других клиентов и какой объем рынка им можно охватить?  Тогда становится понятно, между какими величинами стоит выбор. 3️⃣ Проверьте цену отказа от каждого варианта Если не делаем интеграцию, то: 🟦 сохраняем архитектуру; 🟦 экономим ресурс и можем завершить разработку функции для действующих пользователей, от которой ожидаем прироста LTV на 2%; 🟦 рискуем потерять крупного клиента; 🟦 откладываем выход в новый сегмент на 3–4 месяца и теряем возможность получить критически важные Х миллионов, а это означает необходимость срочно искать инвесторов или сокращать издержки. Так становятся ясны возможные последствия не только активных действий, но и бездействия. 4️⃣ Распишите все возможные варианты и последствия Чтобы понять, какой вариант решения действительно будет оптимальным, полезно создать канву для дальнейшего обсуждения:  🔵 исходный контекст и данные; 🔵 варианты решения и их стоимость; 🔵 возможные последствия и риски по каждому варианту, в том числе в денежном выражении; 🔵 необходимые для проверки вопросы.  Это позволяет сделать логику выбора ясной для всех участников. 5️⃣ Найдите способ проверить самое дорогое неизвестное Недостаток каких данных может привести к самой дорогой ошибке в выборе решения? В нашем случае это может быть вопрос о клиенте: действительно ли для заключения сделки нужна полноценная интеграция или основную потребность можно закрыть минимальной версией или даже ручной обработкой данных?  Может быть вопрос о рынке: нужна ли интеграция с этим сервисом еще кому-то из стратегически важного сегмента?  Или технический вопрос: сколько реально будет стоить решение и можно ли сделать его проще и дешевле? На этом этапе важно понять, какой сценарий может сделать решение ошибочным, и найти самый дешевый способ это проверить. 6️⃣ Зафиксируйте, какой вариант выбрали и чем будете жертвовать, если компромисс невозможен Предположим, вы выбрали делать частичную интеграцию для одного клиента с ручными процессами на начальном этапе. Потому что стратегическая ценность клиента очевидна, но другим представителям целевого сегмента интеграция с конкретным сервисом может не понадобиться.  Если стоимость такой разработки все равно высока, нужно понять, с какой инициативы будет переброшен ресурс, который пойдет на интеграцию. А также зафиксировать, в каком случае возможен пересмотр решения. Проделав все шаги, вы получите не только матрицу оценки вариантов и рисков, но и план принятия решений для дальнейших инициатив. Если через месяц отдел продаж снова предложит сделать полноценную интеграцию, не придется заново все обсуждать: понятно, какое решение приняли, на каких основаниях и что должно измениться, чтобы его пересмотреть. @productsense