Привычные паттерны приоритезации не работают в B2B
Задача на блюдечке от сейлз команды. Кажется, вот готовый инсайт. Бери и делай. И нет, так не работает. Выделение ресурсов на 2-3 месяца не укладывается в привычные паттерны оценки и приоритизации.
Новая интеграция, адаптация форм, форматов, дополнительный контроль платежей и еще много всего. Прекрасно понимаем, что есть бэклог. Задачу нужно прочувствовать, понять, оценить, помасштабировать, выбрать вариант решения, определить сегмент, посчитать эффекты, согласовать... И еще много всего. И потом куда-то добавить.
Раз встаёт вопрос «а точно нужно ли делать/делать сейчас», то это несколько месяцев. Неизвестных слишком много. Эффект же всегда довольно туманен, но понять драйверы можно – увеличение оборотов, рост пассивов, которые без реализации точно не доступны. Цена этому — срок, на который продуктовые команды или команды разработки отвлекутся от текущего бэклога. И эффект, который мы не получим, пока заняты большой задачей. Добавим звёздочку - «это срочно», «это важно», «без этого клиента не придёт / уйдёт». И да. Это B2B.
В такой системе координат привычные модели приоритизации начинают давать сбой. Я о RICE и WSJF. Обе так или иначе направлены на быстрые решения с минимальными вложениями и максимальным эффектом. Однако чем крупнее клиент, тем сложнее и масштабнее запрос. Возможности по масштабированию эффекта от реализации далеко не всегда можно найти - идентичный запрос под капотом окажется совершенно другим. И конкурировать такая задача в логике RICE уже не может.
Для B2B есть характерная особенность – издержки по смене текущего решения довольно высоки. Даже если не очень удобно, не совсем эффективно, но рабочее - это оказывается лучше и дешевле, чем перейти на новое решение - потратить кучу времени на то, чтобы договориться со всеми, всё согласовать, переделать привычные процессы, создать новые интеграции, утвердить новые порядки... «Лучшее – враг хорошего» как раз о таких ситуациях. Если же такой клиент решился или готовится к тому, что, может, уже пора заменить что-то, то нужно ему в этом помогать. И как правило это взаимные инвестиции и взаимные интересы.
Такая готовность является якорем. Самым главным якорем для дальнейших взаимоотношений. Если задача выполнена и клиент с нами — те самые издержки по смене решения начинают работать на нас. То, что вчера было барьером, сегодня нас защищает.
Главный фокус в таком сотрудничестве заключается в том, что масштаб, которого нет в упомянутых моделях, достигается внутри совместной работы с одним клиентом. Внутри готовой системы. Для сейлз команды это является истиной. Истиной, которая должна быть очевидной всем. Мой опыт говорит, что это далеко не так, это не очевидно. И всей потенциальной картины взаимоотношений с конкретным клиентом у продакта нет. И эти будущие бенефиты от работы с клиентом точно не покажут ничего хорошего, если их прогнать через RICE или WSJF.
А как вы приоритизируете запросы якорного клиента против массового бэклога?