Сильно портится мотивация и качество работы.
У деливери команда мотивация побыстрее закрыть задачу и скинуть ее в саппорт команду со всеми багами и проблемами.
Саппорт команды это депрессивное место, оттуда быстро вымываются все специалисты, никто не хочет заниматься постоянным багофиксом некачественных решений без каких-либ оперспектив на будущее.


Я за принцип dogfooding и команды полного цикла,
тогда есть мотивация не делать плохо, ибо сам будешь разбираться со своими проблемами.

Что такое продукт - это всегда очень интересный вопрос на который слышал очень разные ответы 😁

Я вас искренне поддерживаю 👍

И ладно если повезло и толковые люди вымываются в «разработку» - обычно вымываются в другое место работы.

Т.е. саппорт всё-таки часть команды или нет?) Уж простите искреннее любопытство)

У нас есть отдельная служба поддержки пользователей, занимаются общением с пользователями и заведением инцидентов.
Техническое сопровождение компонент системы, то есть анализ и работы по инцидентам, ведет команда, занимающаяся разработкой продукта.

Ну, у вас все-таки нет кастомизаций под заказчика, у вас ровно одно внедрение. В этом кейсе разработка и поддержка - конечно одна команда.
А я про кейсы, когда есть базовый продукт и 100 внедрений (иногда с заметными отклонениями и доработками). И тут проблемы разделения продуктовых команд и саппорта совсем другие (
По сути вообще четыре процесса - разработка, внедрение/кастомизация, поддержка базовой функциональности, поддержка кастомизаций (

не путай B2B и B2C, они по разному устроены)

все равно у вас есть базовая платформа и пакет внедрений,
по сути во многом это технологическая платформа и конечные продукты для клиентов

Лично для меня в этой дискуссии очень важен и близок тезис (Геннадия, в частности) -- что юнит {производительности, масштабирования, развития} = это команда.

Интересно, что есть вполне industrial grade обратные примеры: меня в этом плане поражает современная гражданская авиация.
Но к матричным командам разработки отношение сложное (возможно, это личное).

Есть кейсы, когда получалось построить продуктовые команды в матричной структуре

Интересно. Я почему то думал что только так и работает, в кейсах когда в создании продукта «условно» больше десятка человек.

Либо «прям суровый эджайл, где по/см/ак а остальные - «разработчики».

Над продуктом могут работать люди и команды из разных подразделений, но в стиле пинг понга. Не всегда возможно выстроить командную работу. Людей может быть сильно больше 10-ти, разумеется

Над продуктом могут работать люди из разных компаний, иногда конкурентов. И при этом продуктовая команда может быть, а может и нет

Речь о построении доверительных отношений и сотрудничестве

Есть ощущение что термин «продуктовая команда» - понимается по-разному в зависимости от «point of view». Для меня - ПК - команда людей способная(имеющая ресурсы/рычаги воздействия) реализовать любое изменение в продукте от начала (идеи) до реализации (доставки до пользователей продукта) и отвечающая за полный жизненный цикл продукта. Понятно что это немного «идеальное» определение и в жизни всё сложнее. А как вы видите это определение?

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

Явно нужны разные определения, потому что точки зрения действительно разные

Кажется, что такое имеет смысл для b2c или для 1-2 внедрений на продукт.
Продуктовая команда- команда, занимающаяся развитием продукта. А вот, что будет результатом их работы, зависит от ситуации