Excelente matéria da CIO Online sobre o drama da organização dos times em TI, aqui explorando a lógica de estruturação por produtos:

https://www.cio.com/article/411295/product-based-it-a-blueprint-for-success.html

Quando se fala em implementar Agile, cedo ou tarde, especialmente quando se passa a discutir o ágil escalado, o tema de como organizar os times/squads virá à tona!

A complexidade e extensão da discussão obviamente vai depender da variedade, sofisticação e interdependência dos temas e produtos tratados pela organização, mas de qualquer forma, dificilmente será uma discussão simples.

Primeiro começa por entender e acordar dentro da organização o que é um "produto" efetivamente para ela?

É uma linha de negócio? É uma família de produtos? É um subproduto? É uma etapa do processo ou cadeia de valor? É um sistema? É como nosso cliente nos enxerga e consome? É como nossas áreas e usuários internos utilizam e operam?

A resposta vai variar por organização e por vezes mesmo dentro de uma mesma organização vai variar de acordo por linha de negócio. Acho improvável que exista uma resposta única de prateleira que funcione para todos.

E ainda tem mais, depois de ultrapassada a questão de "o que é um produto", tem ainda a discussão de como ele é processado e como está organizado tecnicamente em IT: como estão os times de canais, por produto, etapa da cadeia de valor, por tipo de entorno/usuário?

Como estão os serviços/API, igualmente existe algum tipo de segregação por canal ou processo? Como está o back-end, por produto, entorno, processo, canal?

Qual recorte, fusão, replicação, sinergia ou composição faz mais sentido considerando aspectos de melhor performance e eficiência, por exemplo na linha de Team Topologies?

O atual nível de modularização dos sistemas core, assim como o nível de desacoplamento entre os sistemas distintos, sistemas e canais, canais, sistemas e APIs, permite a decomposição em times segregados por produto, seja lá o que for o produto para a organização?

Caso não permita, quais os estágios transitórios e evolutivos da organização dos times até se chegar no modelo "ideal"?

Enfim, a discussão é ampla, cheia de alternativas e algumas vezes com múltiplas respostas possivelmente certas mas potencialmente com nenhuma 100% perfeita.

E isso é o que complica ainda mais na hora de decidir pela opção "mais certa" (onde toda escolha é uma renúncia)!

Ao longo de todo 2022 No/Low code foi amplamente divulgado e inúmeros cases reais pintaram por aí.

Sempre fica aquela dúvida se é um movimento real ou se é mais uma hype sendo forçada.

Olhando os números do ano, fica ainda mais forte de que é sim um movimento real, como mostra essa matéria da ComputerWorld:

https://www.computerworld.com/article/3684173/low-code-development-platforms-to-grow-25-in-2023.html

Obviamente, como qualquer tecnologia, No/low code tem seus prós e contras, seus cenários mais ou menos favoráveis de uso, suas necessidades de maturidade de processos, arquitetura e governança para poder ser mais ou menos amplamente utilizada em cada organização.

E da mesma forma, o contexto de cada indústria pode de certa forma limitar ou potencializar o uso do No/low code.

Mas o interesse e o uso efetivo segue aumentando. Acho que vale a pena se antecipar, entender do que se trata e como capturar valor a partir disso, considerando as particularidades de cada caso e avaliando onde de fato esse tipo de solução pode fazer sentido.