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

Маленький трюк, чтобы усилить договоренности Когда люди делают что-то своими руками, они больше это ценят. Вот два классных примера, которые иллюстрируют этот эффект. 1️⃣ Эффект IKEA:

В исследовании IKEA люди собирали мебель, оригами или фигурки из Lego. После этого они оценивали созданные своими руками объекты существенно выше, чем аналогичные объекты, созданные другими людьми. Когда человек сделал что-то своими руками, вложил силы и время, у него появилась микро-связь с этим чем-то. Благодаря связи, ценность растет в разы (часто непропорционально сильно).

2️⃣ Кейс про конверсию в длинной форме vs короткой

Интуитивно кажется, что чем больше в форме полей, тем больше “трение” и ниже конверсия. Но вот одни ребята

протестировали

несколько вариантов формы на сайте и обнаружили неожиданное: длинная форма с понятными вопросами сработала так же хорошо, как короткая — обе дали ~100% прирост лидов по сравнению с оригиналом. Ключевым оказалось не количество полей, а то, объясняет ли форма пользователю, зачем она задаёт каждый вопрос. Когда человек формулировал свои задачи и цели прямо в форме, он психологически вкладывался в процесс и с большей вероятностью доходил до конца. Усилие, потраченное на заполнение осмысленных полей, сработала не как трение, а как инвестиция в собственное решение.

Как это использовать в управлении проектами? Просите стейкхолдеров подтвердить ваши договоренности. Их собественными руками. Например, обновить дату поставки фичи в трекере. Или, поставить чекбокс в плане проекта напротив “я отдам бекендера на 1 неделю на ваш проект”. Мелочь, а работает. Когда человек сам пишет такой комментарий, это уже гораздо больше его решение, его слова, чем когда написал кто-то другой. Так договоренности прочнее.

Лишить права на незнание Важнейший менеджерский прием - лишить права на незнание. И я вот за последние 2 недели очень удивился, осознав, как много людей о нем не знают и даже стесняются использовать. Давайте вместе разберемся: вы можете и даже должны регулярно отправлять статус о проделанной работе/текущем состоянии ваших проектов вот таким товарищам уважаемым: 1. Руководитель! 2. Стейкхолдеры. 3. Кто-то важный в вашей системе координат. Зачем? Да потому что ваша задача все время рассказывать о вашем прогрессе. А что делать, если они не хотят слушать? Ну давайте так: я еще ни разу не встречал, чтобы кто-то в ответ написал: «Зачем ты мне это присылаешь, прекрати!» А что делать если они не читают? Ну так Ваша задача постараться «лишить права на незнание» и минимизировать возможность человеку сказать, что он о чем-то не в курсе. Очень простой шаблон, который почти всегда заходит: • Progress: что продвинулось (1–2 пункта) • Next: что дальше • Risks: где может поехать • Ask: нужно ли что-то от тебя

Важно! Если в отчете нет Risks или Ask, то лучше писать его пореже: 1-2 раза в квартал. Иначе фигня получается.