Про особенности подходов к формированию бэклога в B2B. (Часть 2 из 2) Мы не раз проходили по этим граблям и выработали принципы, которые помогают держать баланс. Возможно, они смогут быть полезны и вам. 1. Квотирование бэклога. Мы не создаем отдельные «проектные» команды под клиента - это убивает целостность продукта. Вместо этого мы выделяем внутри единой продуктовой команды четкую квоту capacity под обязательства перед конкретными заказчиками. Команда остается одна, управление - единое (в руках держателя видения продукта), но часть её времени легально и прозрачно отведена под клиентские доработки. Задача продакта при этом - не просто выполнять, а минимизировать объем этих доработок, находя более универсальные решения или реализуя их так, чтобы фича была интересна клиентам на широком рынке. 2. Поиск и решение корневой потребности, а не реализация требований ТЗ «в лоб». Клиент приходит не с «хотелками», а с симптомами своей боли, облеченными в форму требований из ТЗ. Наша задача (в тандеме с коммерцией) - докопаться до сути, до корневой проблемы. Часто это приводит к иному, более простому и продуктоориентированному решению, чем изначально предполагал заказчик. Это экономит ресурсы всем и уводит от логики «сделай как написано». После такого разбора у нас появляется не просто список фич, а оцененный и календаризированный пул потребностей, привязанных к договору. 3. В LE тоже можно кое-что узнать о пользователе. Сбор данных в LE - это не про подключение стандартных средств сбора метрик, а про переговоры с ИБ. Мы договариваемся о минимально необходимых способах сбора пользовательских метрик (например, Яндекс.Метрика без вебвизора), внедряем виджеты сбора удовлетворенности (CSAT). Но главный инструмент - это непрерывный диалог на всех этапах: от продажи и внедрения до разбора инцидентов. 4. Разработка сквозь призму TCO (Совокупной стоимости владения). Развитие пользовательской функциональности продукта на рынке LE всё так же важно. Но его фокус смещается: на первый план выходит снижение TCO для клиента. А именно: легкость базового внедрения, скорость обновления, возможность кастомизации силами клиента - вот что становится ключевыми драйверами ценности и, как следствие, источником наполнения бэклога. В итоге: Бэклог для LE - это не просто список ранжированных фич, а сложный механизм балансировки. Баланса между проектом и продуктом, между конкретным «надо» и универсальным «ценно», между давлением контракта и долгосрочным видением. А как вы справляетесь с этим давлением? Что помогает вашей команде сохранять продуктовый фокус, когда крупный клиент настаивает на своём?