Ep. 221 - Jornada de Produto: Formação de times de alto desempenho

Esse papo surgiu da conversa sobre o que o Estevam estava vivendo: o processo de construção de uma área de produtos do zero. O que a gente faz quando isso acontece? Do zero ao produto, o que acontece quando não existe a área de produtos, ou para que deve existir, precisa existir, tudo isso a gente vai falar. O que de fato é uma área de produto? Que rolê é esse? Por que isso precisaria ou deveria existir? De onde surgiu essa viagem?

Eu fui dentro da Widgetech, que foi o de criar uma área de produto do zero. E qual foi o motivo do porquê o CEO queria estruturar uma área? Basicamente, ele queria ter uma estratégia de produto, que é entender o que vai ser desenvolvido ou aprimorado e por quê, que tipo de alavanca eu vou conseguir mexer a partir de determinado desenvolvimento, como eu consigo transmitir esse valor para o cliente, ouvindo do cliente, o que faz sentido desenvolver, não faz sentido desenvolver. Organizar a área, de fato. Então, entender um pouco qual é a performance dos squads dos desenvolvedores. Eu entrei muito com o chapéu de produto e agilista, de team lead, porque eu tive que entrar de cabeça em temas, pra entender como eu consigo avaliar isso, qual é a visão de consultoria daquilo, e deixar de ser um tirador de pedidos, fazer com que a área de desenvolvimento deixasse de ser, a gente pediu aquilo, a gente faz aquilo, não pergunto porquê, não entende escalabilidade interna pra outros clientes. Tudo isso fomentou a criação de uma área de produto internamente dentro da Widgetech. Eu cheguei numa hora bem propícia pra conseguir olhar de uma forma estratégica, porque olhar de uma forma estratégica é muito mais o que a gente não vai fazer do que o que a gente vai fazer. A gente sabe que o pessoal quer fazer tudo, não, vamos atender todos os clientes, vamos pegar todos os pedidos, e não, pera, porque a gente vai pegar determinadas solicitações e seguir adiante. Então a gente precisou entender que tipo de critérios avaliar pra dizer: isso vamos fazer agora, isso vamos fazer depois, isso não vamos fazer.

No contexto de consultoria, a gente se depara muito com a necessidade de resolver problemas de negócio e de resolver os problemas do cliente. Eventualmente a gente tem esse tipo de conversa sobre como que a gente pode ter uma área cada vez mais voltada pra necessidade do cliente, sendo que eu coloco de fato esse cliente no centro da tomada de decisão. Isso tem a ver com a estruturação de modelos organizacionais. A gente pode ter modelos organizacionais que olham tarefas, um modelo mais voltado pra atividade, pra execução, um pouco mais operacional. A gente tem um modelo organizacional mais voltado pro business, que olham pra indicadores de negócio, saúde do negócio, mas as áreas basicamente atuam isoladamente entre si. Existe até uma noção de cliente, mas ele não tá presente na tomada de decisão do dia a dia. E existe um modelo organizacional que de fato coloca o cliente no centro. Quando a gente fala de estruturação de áreas de produtos, a gente também tá falando sobre isso, que é como que eu cada vez mais coloco esse meu cliente pra ele ser o direcionador da minha tomada de decisão. Toda organização que a gente vê hoje tá tentando se modernizar de alguma forma, buscando se tornar cada vez mais customer-centered, e surge de fato as estruturas de produto, que coloca o cliente, as necessidades e experiências em jogo pra discussão. Sem isso a gente não consegue tomar boas decisões. As grandes organizações, as que têm sido bem sucedidas, têm utilizado esses conceitos na hora de pensar nas suas estruturas internas.

Quando a gente ouve pela primeira vez, área de produto, pode rolar uma interpretação equivocada de que é bem operacional, descolada da estratégia. Mas na verdade é uma área que deveria estar muito próxima da estratégia, porque tudo que vai acontecer ali vai impactar diretamente. Na perspectiva de competências, eu penso muito em entendimento do negócio, porque a área de produto, antes de ser uma área de tecnologia, ela é uma área ligada a negócios. Eu preciso entender o contexto no qual eu tô inserido. Eu tô na Widgetech, a gente atua em um subsegmento do food service, que é de refeições coletivas. Eu preciso entender qual o tamanho desse mercado, quais os principais players, quais movimentações relevantes estão acontecendo, quantas pessoas empregam diretamente, qual o potencial de mercado. Conhecimento de negócio é fundamental. Junto com essa questão, eu preciso ter adaptabilidade. Eu não posso ficar numa contínua sempre. Eu tinha uma estratégia trimestral que era X, opa, mas aconteceu Y, X vai ter que ser mudada. É importante se desprender quando for necessário. Vi que determinada hipótese a gente testou, não se mostrou a realidade, vai pra próxima, não se apegue às ideias. Valide o quanto antes, se der certo, legal, vamos entender se dá pra escalar ou não, deu errado, posso até tentar uma coisinha ou outra, mas não se prenda a ela, porque isso pode te custar muito tempo, esforço, capital político dentro da organização.

Essa é uma mentalidade que a gente precisa ter, sobre testar e aprender com consistência, mais do que a gente ter certezas. E mais do que só a pessoa que é um líder de produto ou um agilista, o time inteiro precisa ter essa mentalidade, senão não funciona. O conceito de time é a gente ter objetivos em comum e perseguir isso. Se uma única pessoa fica responsável por ter essa mentalidade, mas os demais continuam tendo a mentalidade de executor, primeiro que a gente tá jogando 50% da capacidade das pessoas fora, e o outro é que a gente não está de fato como um time. Todo mundo precisa ter essa mentalidade de crescimento, de testar e aprender. Somado a isso, eu destacaria também um poder de influência, principalmente em alguns papéis chave, quando eu falo de uma pessoa líder de produto, uma influência junto aos stakeholders, pra tomada de decisão e pra mostrar de fato quais são os números, o que faz sentido pro negócio. Se a gente não tiver essa habilidade de negociação, de trazer pra mesa o que de fato é importante nesse momento, a gente também não ganha essa confiança. Um time de produto precisa ser empoderado pra poder de fato tomar essas decisões. A influência e o relacionamento com os stakeholders são habilidades fundamentais, principalmente pra liderança desse time.

Quando a gente olha numa perspectiva organizacional, como essa área ou esse time de produtos vai se alinhar com a estratégia da companhia? Quando eu cheguei na Widgetech, eu já tinha experiência em algumas outras empresas, na Sodexo, no Itaú, na área de produtos, mas foi um desafio bem grande entender como eu poderia criar uma área de produto do zero. Primeira coisa que eu fiz foi no primeiro mês, entender o que era a empresa. A Widgetech tem um portfólio de produtos bem extenso, são complexos, não tem uma interface simples. O meu primeiro mês foi muito de sentar e mexer nas plataformas. Eu queria entender de alguma forma mensurar quantitativamente como tava a cultura ágil dentro da Widgetech. A Fê me apresentou os quatro domínios de conhecimento de agilidade, pra eu conseguir separar em caixinhas: como eu avalio a maturidade dentro de agilidade da organização, levando em consideração negócio, cultura, tecnicalidade e organização. A partir disso eu consegui mensurar com uma certa facilidade. Eu criei uma métrica interna pra conseguir fazer essa avaliação. Eu tive one-to-ones com cada integrante do squad. Me fala aí, o que você acha da organização nesse sentido? E aí eu comecei a coletar muitos feedbacks. Em especial, o que você acha que pode melhorar? Eu não dava nenhuma sugestão. Eu esperava o desenvolvedor, o PO, o pessoal, falar pra mim. Depois desse primeiro mês, eu mandei uma documentação mostrando quais itens a gente deve atacar. Os itens que foram mais citados foram o que eu comecei a olhar com mais ênfase. Foi algo criado, não fui de fora, externo, cheguei de fora, fiz uma avaliação e pronto. Eu dei um espaço pra todo mundo se manifestar. A partir do momento que todo todo mundo se manifestou, eu consegui elencar os principais problemas: histórias com poucos detalhes, história que só tinha um título, não tinha nenhum detalhe adicional pra ajudar. E falta de testes por conta de um QA, falta alguém pra centralizar testes antes de ir pra produção, antes de ir pro cliente. É muito melhor se a gente testar o máximo possível internamente.

Como a Widgetech é nativa digital, o negócio da Widgetech são produtos digitais, a estratégia de negócio é a mesma coisa que a estratégia de produto. Não tem uma desassociação de ação. A estratégia que a gente tem pros nossos produtos é diretamente a nossa estratégia de negócios. Quando eu fiz esse levantamento, eu fui acompanhando com o meu CEO, o que ele achava, se ele tinha algum adendo. Como a gente queria aumentar o rendimento dos nossos desenvolvedores, eu precisava, antes de mais nada, metrificar isso. Eu precisava ter alguma forma de acompanhar quanto tempo cada desenvolvedor tava levando por história, levando em consideração complexidade, levando em consideração quando a história está em produção. Outra coisa que a gente fez foi criar o nosso DOD, o Definition of Done e o Definition of Ready. Antes isso não existia. Eu falava com o desenvolvedor, essa história está no ar? Não, essa história tá no ambiente de desenvolvimento. E alguns consideravam isso como estar no ar. Por falta de definições, tinham muitas confusões nesse sentido. Eu precisei fazer algumas definições internas pra colocar todo mundo na mesma sintonia, pra aí sim a gente começar a mensurar e, a partir da mensuração, conseguir fazer acompanhamento, follow-up, entender o que tá acontecendo.

Sobre os quatro domínios, ele ajuda a gente a ter uma visão holística sobre o que de fato é importante quando a gente tá olhando pro nosso negócio. Ele ajuda a gente a fazer um diagnóstico, tanto da parte cultural, quanto organizacional, técnica e de fato de negócios. Como ele abrange tudo, a gente consegue fazer um diagnóstico da posição atual e de repente olhar pra uma posição desejada, onde a gente gostaria de estar. Sobre a estratégia, quando a gente tá falando de uma empresa que é puro digital, a estratégia tende a ser mais conectada com o produto. Mas quando a gente tá falando de empresas que têm segmentos físicos, um banco, por exemplo, que tem um aplicativo, tem um site, mas não necessariamente tudo é online, a gente tem estratégias que podem ser direcionadas também pra outros lugares do negócio. Pode ter um certo descolamento. Mas pode ser que o seu produto ajude a potencializar a estratégia, que eu acho que é a parte mais importante.

A gente conecta o que a gente chama de Flight Levels. O Flight Level 3 é a definição da estratégia da empresa, o que a gente quer mudar, como que a gente quer mudar o nosso negócio, e pra isso a gente pode usar algumas metodologias, dentre elas os OKRs. Aí de fato a gente desce pro Flight Level 2, quando a gente tá falando de um nível de coordenação, coordenando o que tá sendo feito no nível de épico, no nível de projeto, iniciativa, com o que de fato foi definido na estratégia. E depois no que foi definido no time, no nível operacional. Quando eu conecto lá a minha história, minha task, com esse épico e com a estratégia, eu tô percorrendo toda a estrutura organizacional, conectando os meus itens de voo. Na prática, o que a gente faz pra poder conectar a estratégia ao operacional é, através de momentos ágeis, conectar de fato essa estratégia ao operacional, porque senão a gente tem descolamento da estratégia, e a gente vai ter pessoas falando: no dia a dia o que eu faço não tem nada a ver com a estratégia da minha empresa. O maior desafio do time de produto é conectar o seu propósito de existência com essa estratégia da empresa. Por isso que é importante conhecer sobre o negócio, porque a estratégia mora ali, no conhecimento do negócio, do cliente. Cada time deveria estar fazendo no dia a dia: como eu contribuo? O que faz sentido? Esse exercício tem que ser constante, principalmente se a gente tiver revisão de estratégia ao longo do ano.

Pra identificar o propósito, gosto muito de utilizar o Golden Circle do Simon Sinek. O Golden Circle é uma ferramenta muito simples. Ela fala basicamente por que, o que e como. Quando a gente chega numa organização que a gente está estruturando times de produto, a primeira coisa que a gente faz é voltar pro propósito. Por que que a gente existe? Existe um porquê, a gente quer resolver problemas. Que problemas são esses? E como que a gente vai ajudar a entregar esse valor? É uma ferramenta simples, o que, como e porquê, que já ajuda a gente a ter uma clareza e um alinhamento com o time pra poder dar a largada. Pra entender o nosso propósito, a nossa missão, visão, valores, a gente fala muito com o cliente. Tem uma frase que eu ouvi da Helena Werner, que ela fala: se você como produto não fala com o seu cliente, não tem contato com o seu cliente com certa regularidade, você está fazendo seu papel errado. Um dos nossos valores é Customer Centricity. A gente precisa estar próximo do cliente. E isso, por estar no nosso propósito, faz com que seja muito mais fácil falar com o cliente quando eu achar necessário. Um dos nossos clientes é a Sodexo, a Sodexo atende escolas com refeições preparadas dentro da própria escola. A gente tem um produto que é a Wallet, e eu precisava entender melhor como as crianças lidavam com a Wallet for Schools. Eu fui até uma unidade, falei com uma gerente de unidade, ela me acompanhou, me levou pra conversar com algumas crianças, rapidinho eu fiz algumas anotações, peguei o feedback, entendi o que elas gostavam, o que elas não gostavam. Consegui falar no mesmo dia. Já trabalhei em lugares que não era assim, pra eu conseguir falar com um cliente era uma logística gigantesca. Por estar dentro do nosso propósito, facilita muito. Usar o Golden Circle não significa que eu não farei isso. Um dos clientes que a gente usou, uma grande rede varejista, pra criar um propósito pra essa equipe, usando o Golden Circle, foi: o que ela quer, na hora que ela quer, do jeito que ela precisa. A gente também trouxe a visão do cliente na hora de colocar o propósito. Não podemos esquecer da pessoa mais importante da sala.

Pra um time de produto funcionar e não cair no lugar de descolamento da estratégia, a gente precisa imprimir isso no dia a dia. A minha missão, visão, valores, propósito, ele vai continuar saindo uma frase se eu não imprimir na prática. Eu preciso, antes de mais nada, que o meu CEO compre a ideia. Uma vez que a figura de máxima liderança comprou a ideia, a ideia de cascatear fica muito mais fácil, fica possível. Sem ter uma figura de alta liderança, fica impossível pra conseguir dar essa voação. Uma vez isso tendo sido alinhado, a questão do dia a dia, porque eu preciso transmitir isso em todos os momentos. A gente tem o valor não temos braço curto, que é só uma frase, mas quando a gente tem um comprometimento do desenvolvedor pra concluir uma história a tempo, considerando o nosso DOD, às vezes a gente precisa ficar até a noite, às vezes a gente precisa virar um final de semana pra segunda ficar pronto. Não é sempre que acontece, mas acontece. Eu preciso de pessoas que digam: beleza, tamo junto, vamos fazer acontecer, vamos entregar. Isso é algo impresso na prática. Os nossos desenvolvedores têm um rendimento hoje consideravelmente alto. Pra uma startup que tem um foco amplo, a gente tem um portfólio com oito produtos pra mais, a gente consegue fazer a gestão, entrega, melhoria contínua, correção de features em um tempo relativamente rápido. Precisa imprimir no dia a dia, se ficar só no aspiracional, esquece, não vai servir de muita coisa.

Se a gente não vive aquilo que a gente coloca como nossa aspiração, nosso propósito, de nada adianta. E se a gente também não revisa isso constantemente, porque pode ser que em determinado momento meu time de produto cresça, o meu negócio cresça, e talvez o que eu esteja fazendo não esteja mais alinhado com aquele propósito. A gente pode tomar decisões: faz sentido isso ficar dentro desse time, faz sentido a gente ter um novo time que olha pra isso, porque de repente vai atender melhor o meu cliente. A gente pode inclusive segmentar o time se fizer sentido. De tempos em tempos a gente tem a humildade de falar: talvez não esteja mais fazendo sentido, talvez a gente precise adaptar uma coisa ou outra. Mas tudo colocado em perspectiva, porque a gente não pode olhar de forma isolada. Se a gente olhar os times de produto de forma isolada, a gente vai perder justamente a conexão sistêmica, que é onde tem valor no final das contas. O cliente de fato não procura só o PIX na sua organização e o CHECK na outra. Quando ele quer ser bem atendido, ele vai escolher a sua organização pra atendê-lo com todos os produtos. Se eu tiver olhando só pro meu, talvez eu possa perder esse cliente, ter o melhor time de PIX possível, mas eu perco porque de fato ele não tá sendo bem atendido ali no CHECK. Eu preciso de tempos em tempos ser visitável, se faz sentido o escopo desse trabalho com o nosso propósito, com o momento que o cliente tá vivendo e também com as mudanças do mercado.

Metrificar é uma palavra que assombra muita gente, mas que é extremamente importante. Eu preciso de alguma forma quantitativa mensurar o que eu tô fazendo. Isso eu vejo que é um gap muito grande, inclusive em grandes organizações. Quanto tempo em média o meu squad demora por sprint pra entregar uma feature de complexidade média, média alta? Eu preciso ter essa informação. Se eu não tenho isso mensurado, eu não vou conseguir entender se na próxima sprint o que que eu vou conseguir entregar. Não é uma conta simples, até hoje a gente tem formas de melhorar, de aprimorar ainda mais. Mas pelo menos a gente tem isso. Eu consigo saber como foi a performance no mês de cada um dos desenvolvedores, quando eu olho só pra desenvolvedor front-end, só pra desenvolvedor back-end, quando eu olho pra quais histórias foram pra determinados clientes. A gente criou tags: essa história, esse épico, ele foi pra nível Brasil, nível Colômbia, nível Costa Rica, foi pra qual cliente, foi planejada, foi uma goal horse, ou seja, foi uma história que não foi apresentada na planning, ela entrou no decorrer da sprint. No final do mês eu consigo ter um recorte exato de como foi a nossa atuação, a comparação desse desenvolvedor em relação a sprint anterior. Acho que falta muito isso, fica muito no qualitativo e pouco no quantitativo quando a gente faz a avaliação.

Pra falar de métricas voltadas pra eficiência, a gente entende qual a eficiência do nosso time pra ser cada vez melhor e buscar alta performance. Somado a isso, não se esqueçam de trazer métricas de negócio. Se a gente tá resolvendo problemas, se a gente tá resolvendo as dores do nosso cliente, a gente precisa equilibrar métricas de eficiência com métricas de eficácia. Qual é a dor do cliente? Como essa dor se representa em uma métrica? Se hoje ele tem uma dor que ele tem um nível de atendimento ruim no SAC, o tempo de atendimento dele é super alto, aparece lá no meu NPS, demora pra ter a resolução dele atendida e aí meu NPS acaba sendo um 6, um 7, por conta disso. Como que eu posso colocar esse meu NPS em evidência e a partir daí vou fazendo ações pra melhorar esse atendimento no SAC e vou acompanhando se ele vai mudando, se essa métrica vai mudando. Definir o que é essa dor do cliente, conseguir tangibilizar essa dor em uma métrica e acompanhar também essa métrica junto das métricas de eficiência.

A Widgetech vende produtos pra outras empresas que por sua vez repassam pros consumidores finais. Teve um case bem legal esse mês. Eu comecei a fazer um evento mensal que eu chamo de imersão Widgetech. Eu pego o ponto focal de cada um dos nossos clientes, por ser B2B dá pra fazer isso, eu preparo um material e exibo esse material pra essa pessoa. O material é dividido em três partes. O primeiro é novidades que a gente teve nos produtos: o que que a gente teve de novidade no aplicativo, a gente tem essa nova feature que agora funciona assim. A gente já envia e-mail, marca em cada data de release divulgando. Só que a gente sabe que e-mail marketing muitas vezes o pessoal não vê, não vai dar a mesma atenção, vai ficar com dúvida em relação a contexto. Com esse ponto mensal, as pessoas falam o que a gente teve de novidade, se tiver qualquer tipo de dúvida, como eu acesso, como eu configuro, eu já consigo trazer um direcionamento. Segundo ponto, eu faço uma avaliação de mercado. Dentro do subsegmento de refeições coletivas, eu pego muita referência do setor de food service. O que que teve de relevante? Teve uma coisa interessante do nosso setor que alguém adquiriu outra empresa. Isso talvez o cliente não sabe no dia a dia. Eu dou uma contextualização e pra ele é relevante. Depois de cada uma dessas reuniões, eu salvo esse material em PDF e envio pro cliente, e vários clientes já falaram: eu tô compartilhando internamente e tá sendo bem legal, o pessoal tá gostando do conteúdo. Porque eu entendo que o cliente não tem tempo pra fazer algumas coisas. Quando eu crio algo pra ele estudar e ele ganhar reputação dentro da própria empresa dele, porque ele compartilha internamente, eu tô ajudando muito esse cliente. E aí, o terceiro é uma mini retro. Cliente, me fala aí, o que que a gente tem que continuar a fazer, parar de fazer, começar a fazer e algumas observações gerais. Nesse mês, a K da menu alimentação, eu falei: e aí, vamos fazer a retro? O que que você precisa, K? E ela falou: de nada, tá tudo bem. Ela não tinha nenhuma sugestão, tava tudo certo, não tinha nenhum problema a ser reportado. Cliente satisfeito. Ela ficou feliz, só pediu pra eu enviar o material depois. É esse tipo de métrica que dá pra avaliar. Chegou no final do mês, ela não preencheu nada. Por quê? Porque não tinha nada que ela queria adicionar, acrescentar. Isso me deixou bem feliz.

Agora que ela não queria nada, muito provavelmente ela tava 100% satisfeita com o que ela tava recebendo, mas também não quer dizer que necessariamente ela não ficaria feliz se recebesse mais alguma coisa. Como que funciona, na prática, o processo de fazer o que precisa ser feito, o dia a dia, mas paralelamente também olhar pra inovação? De qual é o próximo passo, de qual é a minha próxima novidade, o que que eu vou entregar pra minha cliente, pra além dela falar que ela não precisa de nada, ela ficar surpresa com algo que ela não tava esperando? A gente começou a utilizar o conceito de OKRs anuais. Uma vez eu tendo visibilidade no decorrer do ano do que vai ser entregue e quando, são grandes blocos. O que que a gente acredita que é valor e que precisa ser entregue em um mês, em um semestre. Muitas vezes os clientes pedem: e se a gente fizesse aquilo, isso? Como a gente seleciona o que vai ser priorizado? Tirando os casos em que tem um orçamento destinado a isso, essas solicitações que entram na esteira geral, a gente pega e compara com esses OKRs. O cliente solicitou uma feature que a gente já tinha mapeado antes, a gente já ia fazer. Faz sentido a gente priorizar, porque faz sentido do ponto de vista de produto essa feature. A definição do que entra no OKR tem várias formas. Esse link é muito mais fácil quando a gente tem isso, porque aí chegou uma solicitação, vou entender se tem feature ou não com o meu OKR. Se não tiver, ou eu faço um orçamento pra ser algo paralelo, ou eu deixo no final do meu backlog, porque não é minha prioridade agora. Mesmo um cliente que não precisa de mais nada, ele vai continuar tendo inovação, ele vai continuar tendo novas features, isso não vai parar, porque todo produto digital tem uma questão incremental muito forte. É por isso que é um produto e não é um projeto, porque tem uma melhoria contínua que não para.

Uma coisa que muitas organizações têm dúvida é a diferença entre o business as usual e os OKRs. OKR, por definição, ele ajuda na mudança. Algo que eu quero mudar no meu negócio, algo que eu quero fazer de diferente. É um pouco mais ali médio prazo. E quando a gente fala de business as usual, eu tô falando de manutenção do meu negócio. E a manutenção do meu negócio não pode parar. Se acontecer algum problema em produção, eu preciso ir atrás, senão meu cliente vai gritar mais do que o meu item ali previsto pra inovação. Mas, ao mesmo tempo, aquele meu 1% que eu não dedico pra inovação, meu concorrente tá fazendo. Então a gente não pode parar. O OKR é uma técnica que a gente pode usar, uma forma de priorizar, pra organização, pra ajudar de fato a conectar esse backlog com a mudança necessária pra organização, que é muito poderosa. Uma outra forma, pra quem ainda não trabalha com OKRs, é definir um sprint a cada X meses que você vai trabalhar em algum item do backlog dedicado pra inovação. Você vai estudar um pouquinho sobre o que é inovação, o que faz sentido ter de diferente naquele produto e dedicar um tempo pra aquilo. Às vezes, você blocar a agenda, que seria a sprint, pra gente poder dedicar um tempo pra isso, também pode ser importante. No final do dia não tem como não fazer o que a gente tá falando de manutenção. A manutenção precisa acontecer. Um dos maiores desafios que eu vejo, inclusive, é a resistência nos times quando a gente entra nas organizações, é que fazer a manutenção dá trabalho. E às vezes é chato. É resolver um problema que a gente tem que catar milho de onde tá esse problema pra fazer funcionar. E alguns times só querem trabalhar em itens novos. Querer é diferente da necessidade. A gente precisa ser flexível. Tem que resolver os problemas de manutenção, tem que criar coisas novas, e ao mesmo tempo dedicar um percentual ali pelo menos da sua inovação. Porque senão o mercado já vai estar fazendo isso.

Às vezes a inovação, eu não preciso depender da equipe de desenvolvimento. Às vezes tem coisas que a equipe de produto, por si só, pode fazer, que pode ter um ganho gigantesco. A gente tá fazendo um setor de refeições coletivas, ele é muito desconhecido pro grande público. Se você não trabalha com isso, dificilmente você vai saber do que se trata. A gente tendo em vista isso, criou um evento pra lançar um material bem extenso pra detalhar o que é o setor, as tendências do setor. Nunca foi criado um material de tendências a nível nacional. A gente viu isso, a gente falou: a gente trabalha com o setor, a gente atende o setor, ninguém nunca fez isso, por que a gente não faz algo do tipo? A gente criou um levantamento, um evento. Não é pelo ganho financeiro propriamente dito direto, mas muitas pessoas, muitos players do mercado vão passar a ter acesso ao material, por consequência vão nos procurar pra entender como a gente faz. Mas também é a questão do: eu não sou mais uma software house apenas, eu conheço o negócio, eu consigo atuar quase como um consultor pra você, player. É uma inovação que eu não precisei parar o desenvolvedor pra fazer algo. É muito mais ligado a growth do que efetivamente o desenvolvimento e dá pra fazer. É cansativo, tem que ter esse bloco, eu preciso me programar, mas é factível.

A partir do momento que a gente começou a metrificar algumas coisas e a gente começou a definir prioridades, um case que eu gosto muito é que a gente tinha uma pessoa que atuava no suporte, essa pessoa tinha um desejo de ir pra uma área mais técnica e hoje em dia ela é o nosso QA júnior. Teve todo um processo de treino. Eu conheço muita gente da área que atua como QA em empresas bem legais, eu trouxe essas pessoas pra falarem com ele e viraram uma figura de mentoria. Essa pessoa agora automatiza testes, tá fazendo um trabalho bem legal. A partir do momento que eu consegui definir minhas prioridades e eu consegui tomar ação. Foi a base do sangue, suor e lágrimas, nada foi simples, foi muito difícil trazer uma pessoa de suporte, treinar, defender o budget pra ela estar aqui na área técnica. Teve uma curva de aprendizado. Mas você pega o resultado final, vê essa pessoa se desenvolvendo, vê uma joia bruta, ela vai com muita tranquilidade chegar no nível de senioridade daqui a algum tempo, ela tem o drive de ir atrás, ela é muito dedicada. Produto é muito ligado a dar um jeito. Não é uma pastelaria, mas eu preciso me adaptar conforme a necessidade. Eu precisava de alguém, conseguir achar alguém. Hoje essa pessoa tem um futuro que eu acho que é bem promissor.

Nesse tempo todo que eu tenho trabalhado com times de desenvolvimento, times de produto, times de negócio, estruturação de times de produto em si, a gente tem encontrado alguns padrões que sempre se repetem e que acabam sendo desafios comuns quando a gente tá estruturando times, às vezes do zero, às vezes ressignificando times já existentes, ou às vezes até desmembrando um time e criando um novo propósito pra ele. Um dos primeiros desafios que a gente encontra é na gestão de dependências. O tanto de dependências que os times têm em relação à sua empresa. A primeira dúvida que surge é: mas o que eu faço com esse trabalho aqui? Eu passo pra esse próximo time? Ou eu chamo essa pessoa desse time e agora ele vai fazer parte do meu time? Crio uma área cross pra poder atender todos esses times? Começa a surgir uma série de discussão de como resolver essas dependências. Elas são de diversos tipos: tem dependência do tipo de autorização, eu não tenho autorização pra fazer determinado processo. Tem dependência de expertise, é só tal pessoa que sabe fazer tal coisa e ela tá em outro time. Tem dependência do tipo de etapa, essa etapa não mora dentro do meu time, ela mora num outro time. São decisões que a gente precisa tomar e são trade-offs que a gente precisa fazer. Um dos pontos que eu sempre coloco em jogo é: se a gente coloca o cliente no centro, o que que é melhor pra esse nosso cliente? Nem sempre a gente vai resolver todas essas dependências, mas a gente precisa buscá-las minimizá-las. A gente tem diversas formas de fazer essa gestão das dependências. Às vezes incorporar sim essa pessoa aqui, às vezes fazer uma gestão visual, uma coordenação. Possibilidades são mil. Eu sempre apresento pros times o modelo Anfits pra fazer gestão de dependências, ele classifica todos os tipos de dependências existentes. Outro ponto que tem a ver com as dependências são as especialidades ciladas. A gente tem pessoas que sabem fazer determinada tarefa, mas não sabem fazer outra. Tem a ver com o novo formato do profissional, o profissional T-shaped, que sabe da sua especialidade primária, mas também precisa ajudar o time de uma especialidade secundária. A gente começa a desenvolver esse tipo de profissional dentro dos times de produto. E também tem a ver com as dependências, que é isso do trabalho passar por vários times até ser concluído, essa fragmentação do trabalho, que às vezes pode ocasionar aquilo que o Estevam falou: tá pronto, mas tá em produção? Não, então não tá pronto. Na hora que a gente tá estruturando times, esse é um ponto que sempre surge e que a gente precisa buscar formas de resolver. E não é tudo de uma vez, não é agora a gente vai mapear todas as dependências e resolver todas. Vamos priorizar como tudo na vida, mas a gente precisa listar e resolver. Eu já fui em clientes que tinha uma lista de todas as dependências mapeadas, parecia uma teia de aranha absurda. E aí quando você perguntava pra pessoa, mas o que que você tá fazendo com isso? Não nada, a gente só tá desenhando, tô só olhando. E quanto que a gente vai quebrar essa primeira linha? Ah não, na verdade a gente não tem plano pra isso. Se a gente tá estruturando times de produto, a gente precisa entrar nessas conversas difíceis. O que vai orientar a decisão da estrutura desses times é o nosso negócio, é o nosso cliente, a nossa arquitetura de software. Softwares mais modulares, se a gente tá falando de microserviço, a gente tende a ter equipes menores também. Se a gente já tá falando de monolito, a gente tende a ter essas equipes gigantes. Tudo isso vai influenciar nessa decisão, mas são conversas que a gente precisa ter e padrões que a gente precisa quebrar.

Essa organização tira também a necessidade daquele profissional, aquela persona de profissional que é o super-herói. Que as pessoas sempre vêm com bons olhos, mas é horrível. Se você tem um profissional super-herói, quer dizer que tem alguém precisando ser salvo por ele. E se tem alguém que precisa ser salvo por ele, quer dizer que o fluxo não tá legal, que não tá sendo legal de alguma forma, a estrutura em si. Eu vejo já vi isso em alguns lugares: ah não, deixa com um determinado fulano, determinado fulano vai fazer tudo. Não, eu não quero deixar com determinado fulano. Se ele sair da empresa, se ele sair de férias, e aí, o que a gente faz? Então precisa ter fluxo estruturado justamente pra não depender de ninguém. Senão a gente cria as famosas single points of failure. Só fulano sabe fazer.

Pra quem tá num processo de construir e estruturar um time, uma área de produtos, ali na posição de liderança, a dica é: não desista, segue firme, porque é um baita desafio. Normalmente quando a gente fala de área de produto, vem um mundo muito sexy, uma coisa muito glamourosa, e cara, área de produto não é isso. Área de produto, especialmente organizações pequenas, médias, é de sangue, suor e lágrimas. Você vai precisar tomar decisões difíceis. Estratégia é muito mais decidir o que você não vai fazer do que o que você vai fazer. E fazer essa definição, esse recorte, você tem que tomar decisões data driven, sempre com dados pra justificar, e mesmo assim, pode ser uma briga de foice. Não deixa essas coisas te desvirtuarem do caminho, porque elas vão acontecer, é inexorável. Mas não perca de foco o porquê você como profissional de produto tá lá. Você acaba sendo a cola pra um monte de especialidades diferentes, pra áreas se conversarem, pra que as pessoas não estejam fazendo duas coisas, as mesmas coisas, se não tem alguém de produto que tá olhando pro todo, que tá olhando pra estratégia e falar: opa, peraí, não precisa fazer isso, trabalha com essa outra pessoa aqui que já tem algo mais avançado. É muito importante não desistir e metrificar tudo. Desde o desempenho da equipe, até, se possível, o uso do seu aplicativo, da sua plataforma, quais são os fluxos pelos quais os usuários mais passam. Use um mês e contrata alguma outra plataforma pra você conseguir ter essa visão. Metrifique, porque se eu dou uma opinião, ninguém quer ouvir opinião de ninguém, as pessoas querem ouvir indicações pautadas com dados. Se virar uma discussão só de opinião, quem tiver o cargo mais alto vai ganhar sempre. Então eu preciso, de qualquer forma, sempre tomar decisões, sugerir coisas bem embasadas com dados. E pra quem é um PO, é um dev, alguém que tá passando por algo nesse sentido, o principal ponto é: seja participativo. Você não precisa só ouvir as coisas e falar amém. Tenta sugerir alguma coisa, tenta buscar a lógica de por que essa decisão é assim. Às vezes tem um racional que você não sabe o porquê, e é legal você saber, porque você sabendo você vai ter uma visão completa, uma visão do todo. Às vezes são coisas que efetivamente não passaram pela cabeça de alguém, e aí você pode agregar. Tem mais a ganhar do que a perder quando você muda esse posicionamento.

Três dicas que eu separei: a primeira, não se apegue ao desenho do time. Seu modelo atual, ele é pra atender às necessidades atuais. A gente precisa estar sempre disposto a adaptar e ver o que vai fazer sentido daqui um ano, dois. A segunda, não olhe só pro seu time. Os melhores profissionais que a gente encontra por aí, eles não tão olhando só pro desempenho do seu time, ou só pras entregas do seu time, mas eles tão olhando pro todo, tentando entender como o todo se conecta com a estratégia, e isso vale pra qualquer tipo de cargo dentro de um time. Entenda do todo, você vai ser muito mais relevante pra organização. E a terceira, busque referências. Ninguém é isolado numa ilha perfeita. Busque referências no momento do mercado, como que o mercado tem lidado com aqueles desafios, como que a sua concorrência tem lidado, como que esse setor tem lidado. Busque eventos, networking, converse com pessoas pra entender como que elas têm lidado com aquilo, porque você vai descobrir que você tem, de repente, uma forma que você não tá olhando e que você pode se incorporar. Ninguém é perfeito, mas a gente pode trocar uma experiência um no outro. Busque conhecimento.