nunca, enquanto outro, se durar cinco anos, ja estara otimo para ofabricante. Para construir as fabricas destes carros e um pouco diferente, noentanto; ambas, e claro, foram feitas para durar e entregar varios modelos pormuitos anos. Em software, nao podemos abrir mao da qualidade, ja que ela edeterminante para a aceitacao de um produto.A qualidade do ciclode desenvolvimento deve ser vista como absoluta, e e essa qualidade que aequipe luta para manter, enquanto muitas vezes os stakeholders nao sabem do quea equipe esta falando. A falta de qualidade no ciclo de producao gera umacumulo de divida tecnica, que funciona como uma divida de juros altos ecompostos, ou seja, quanto mais postergamos o valor da divida, maior sera, ecom crescimento exponencial.A divida tecnica,quando acumulada, diminui a capacidade de mudar de direcao e de se adaptar asnecessidades dos negocios, que surgem em todo momento. Acaba com a agilidade.Em pouco tempo, a equipe comeca a perder a velocidade de desenvolvimento e otempo de vida util do sistema se reduz, com crescentes custos de manutencao eevolucao e capacidade de inovacao seriamente limitada. E do interesse do POmanter a agilidade e a velocidade do seu projeto, entao nao criar dividatecnica e fundamental para todos.Portanto, o PO deveconseguir explicar bem se a cada entrega estamos fazendo o carro popular ou ocarro de luxo. E a equipe tambem deve deixar claro se o foco esta no carro emsi ou na fabrica que faz os carros.PO,equipe e produtoA tentacao de ir alemdo produto minimo viavel (MVP, na sigla emingles) deve ser combatida a todo momento. E o obvio: "o produto minimodeve ser minimo". O PO tera mais chance de sucesso se conhecer muito bemos seus clientes e, ao mesmo tempo conhecer muito bem o produto e a equiperesponsavel pela criacao efetiva do software. Ser um PO significa conhecer emdetalhes cada funcionalidade do produto que lidera e ser capaz de explicar aos stakeholderso que esta acontecendo a qualquer tempo.Com este entendimentonos detalhes e o feedback constante, o PO ganha embasamento para perceber novose melhores caminhos, estabelecendo hipoteses que necessitam de um curto ciclode entrega e feedback. Com uma boa equipe, o PO podera validar tais inovacoesde forma rapida e eficaz.Ao mesmo tempo, enecessario cuidado para nao confundir o conhecimento dos detalhes com o microgerenciamento. A equipe de desenvolvimento temcapacidade e conhecimento tecnicos para entregar o software pedido, e o PO sebeneficia quando evita dizer a equipe como fazer o seu trabalho. O PO, emprimeiro lugar, deve falar de negocios! Ele passa para a equipe suasnecessidades nao em termos tecnicos, mas do ponto de vista do cliente, daempresa. Quando o PO permite a equipe com conhecimento tecnico tomar asdecisoes que lhe cabem, nao so a solucao tecnica e melhor; ele tambem poderacontar com uma equipe muito mais motivada e envolvida com o resultado doprojeto. E assim, todos ganham.Conhecer bem a equipesignifica entender do que ela e capaz, especialmente saber traduzir as demandasde negocio para as tecnicas e vice-versa . Quanto mais se estabelece esteconhecimento mutuo, melhor e a comunicacao e o PO se torna mais eficiente paraplanejar.Deixede empurrar funcionalidadesCom isso, chego aoponto