00:00 - роль степени близости к чаяниям пользователя для бизнес результата
02:51 - дисфункция когда задачи менеджмента это минимизация факапов
04:20 - почему стараются делать продуктовые команды, минимизация потерь информации
07:40 - value-stream map vs текущая орг структура
08:17 - вопрос про активности заранее чем возникнет проблема у пользователя
09:35 - ответ: фичи как побочный эффект, отсылка к ТРИЗ, пример refund в Amazon
14:30 - вопрос какая есть альтернатива платформенным командам
15:29 - инвестиция в архитектуру (Conway's law) с учетом бизнес-составляющей, в знание домена и пользователя, формат команд в зависимости от того что получится, Logistics/Payments/UX, а не по Java/DBA/Admin
18:55 - вопрос как поделить input от запрос по командам
19:31 - трансляция user journey в user story, product owners, аналитики, ux servant
22:20 - вопрос product role vs команды
22:40 - есть доменные эксперты и кто то из них выполняет роль транслятора в user story; роль следует из того что пользователю нужен какой-то продукт и роль ux servant, интерпретатор пользователя
24:14 - product как компонент информационной системы, если продукты говорят что, а разработчики как, то через какое то время продукты будут не успевать генерировать что;
26:50 - как обеспечить наблюдаемость продакт принес не то или разработчик сделал не то, чтобы понять кого не хватает
28:42 - баланс полномочий и ответственности усли нужно убрать продакта
30:00 - как понять в каком состоянии находится система, проблемные места
31:00 - что если все растут
31:48 - стопор если упереться в количество знаний
33:20 - если нет времени умнеть, то нужно ограничивать поток задач
34:00 - блокер таких изменений если нет ощущения их необходимости, если есть поток ресурсов
38:00 - опыт @vfabr что тот кто в самом верху не против инициировать изменения, главные противники изменений среднее звено