"Если хотелку завёл хотельщик, то не очень понятно про бюджет и тем более про задумку. На гитхабе я закинул фича-реквест. Мне либо ответили "спасибо, но нет", либо решили что-то да сделать. Что именно - полностью остаётся на той стороне. Я попросил что-то небольшое, но они осознали бОльшую картину и там, где мне виделся одноколесный велосипед, они соорудили космолёт, держа в голове свои какие-то цели. Про учёт именно "хотелок" - как будто много лишнего в описании и некоторые подробности, что называется, не отсюда. Если это работы, выполняемые по контракту, то опять не понятно, что здесь делают фрагменты сценариев про фича-реквесты от рандомных персонажей. А хотелось бы понять"

Рандомные персонажи конечно могут тут быть, если разрабатываемая система имеет публичный характер и большое количество внешних пользователей. Однако, CAB подразумевает не звать на встречу всех подряд, а собрание ключевых лиц заинтересованных сторон. Если прилетают какие-то запросы на изменение от большого числа внешних пользователей, то через тех поддержку эти запросы могут быть также формализованы и вынесены на CAB, где и решится их судьба. Это уже специфика конкретного проекта.

"Слегка попахивает инструкцией, как потратить кучу времени толпы людей на бессмысленные созвоны. Но возможно я чего-то не знаю или вы так называете процедуры, которые мне привычнее называть иначе. Интересует судьба Product Owner'а в такой картине мира. Он же ничем не владеет, получается. Возможно понятнее станет, если опишете, что за продукт, кто все эти люди, которые друг с другом постоянно ходят на совещания."

Надеюсь про специфику проектов, где это применимо, ответил выше. Что касается траты времени и судьбы Product-а.
Конечно, как и любое новое начинание - трата времени будет казаться бессмысленной на первых порах, здесь эффект накопительный и приходит с выработкой проф привычки всех участников процесса.
Соглашусь, что не совсем корректно указал Product-а как участника данного процесса. Просто сейчас каждая компания по-своему видит работу Product-a, и единого понимания лично я не встречал - поэтому ввел в заблуждение и сложилась путаница. Что подразумевалось - со стороны разработки привлекаются люди, которые владеют техническими компетенциями и знаниями по системе, и способные оперативно давать оценку. Это могут быть: Архитектор, Руководитель проекта (Product Owner - если он есть, а может эта роль собирательная), Аналитик (или несколько), Тех лид и тд.

Есть такой момент, когда овладел новыми для себя дисциплинами/навыками, то потом кажется что все вокруг тоже это знают, все так просто.)

На самом деле это далеко не так.

В вашем случае, обязательно надо попробовать себя в менторинге, таким опытом надо делиться с нуждающимися!