Tretas entre produto e tecnologia e como evitá-las
Do discovery ao delivery as tretas entre produto e tecnologia podem acontecer, o fato é: produto digital sem desenvolvimento não escala e produto sem estratégia não entrega valor
Olá, eu sou a Pati Duarte, e vou te acompanhar nessa leitura sobre as tretas entre produto e desenvolvimento, trazendo algumas dicas valiosas de como fazer uma melhor gestão desses conflitos.
Já peguei meu chá de camomila, te encontro nas próximas linhas.
Essa news de hoje tem tudo a ver com sucesso ou fracasso de produtos digitais, e o tema está em alta! Estamos vivendo um momento de retrospectiva da última década e você sabe o motivo?
Em 2009, nascia o Uber, que só em 2010 começou a entrar no hype e mudou o cenário da tecnologia, o mesmo aconteceu com o iFood, que nasceu físico com o Disk Cook em 2011 e foi expandindo em tecnologia e mudando a forma que nós nos relacionamos com delivery, Whatsapp em 2009 e por aí vai, ou seja, a última década mudou nosso modo de viver (nas grandes cidades em especial), e os próximos anos prometem.
As entregas estão cada dia mais desafiadoras e esse jogo entre produtos e tecnologia precisa dar certo para vermos mais mudanças significativas na próxima década.
Dito isso, vamos ao assunto polêmico: as tretas.
Quando eu digo que as tretas acontecem do discovery ao delivery não quer dizer que elas são constantes e estão em todo o fluxo de ideação e desenvolvimento de um produto, mas elas aparecem vira e mexe em alguns momentos mais intensos.
Vamos por partes, precisamos balizar dois entendimentos para esse nosso papo de hoje, topologia de times e tipos de produtos.
Topologia de times
Matthew Skelton e Manuel Pais, escreveram um livro chamado Team Topologies em 2019 e até hoje é a literatura mais rica sobre o assunto no mercado - fica a dica, se você gosta do tema, escreva um livro sobre isso, o mercado carece de mais conteúdo sobre o assunto - não vou aprofundar nisso, só quero te dar um norte de quais são os padrões de formação de times atualmente.
Os times são formados, ou ao menos deveriam ser, da seguinte forma:
Obs.: não vou usar o termo literal traduzido do livro e tomei a liberdade de juntar o padrão sugerido pelos escritores com o praticado no mercado aqui no Brasil.
Times de negócio core, aqueles que tem por objetivo criar e/ou manter um fluxo contínuo de negócio, com persona definida, funcionalidade e serviço, chamados no livro de Stream-aligned teams.
Times volantes, aqueles que tem o objetivo de facilitar a construção do produto que o time de negócio está realizando, especialistas em assuntos diversos, chamados no livro de Enabling teams.
Times de alta complexidade, são aqueles especialistas em algo muito complexo e necessário que precisam fluir muito bem entre os times de negócio e o próximo que vou te falar que são os times de plataforma, esse time aqui é chamado no livro de Complicated subsystem teams.
Já os times de plataforma, são os time de apoio que sustentam os sistemas de infraestrutura para que os demais times tenham base de trabalho, chamados no livro de Platform teams.
Skelton, M., & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press.
Segura esse conhecimento de topologia de times aí e segue o fio que você vai entender as tretas já já. Agora vamos dar uma olhada nos produtos.
Tipos de produtos digitais
Produto interno e Produto externo. Simples assim. Brincadeira :) eles são mais complexos do que parecem.
Os produtos internos são aqueles que precisam existir para que o negócio funcione, é uma camada do produto digital que o cliente não vê, mas eventualmente sente e muitas vezes é influenciado por eles.
Para ficar mais claro, o melhor exemplo de produto interno são as APIs (Application Programming Interface), mas temos alguns outros como os produtos internos que são desenvolvidos para analisar comportamento, capturar e nutrir leads, integrações para fluidez no funil de conversão e muito, mas muito mais.
Já os produtos externos, de forma mais simples possível, são os que chegam até o cliente, é uma página da web, um app, uma funcionalidade nova no aplicativo, uma ferramenta de busca, um marketplace e novamente, muito, mas muuuuuito mais.
Pronto, todos na mesma página, vamos às tretas!
ALERTA: não generalize as tretas a partir desta linha, mas não se iludam com a ideia de dream team também. As tretas listadas aqui são fruto de uma coleta de informações com Product Managers de diversas estruturas, modelos de negócio e momentos de carreira diferentes, selecionei as mais recorrentes :)
"Não estava escrito na história”
Vamos começar com uma treta bem chata e que acontece com mais frequência do que gostaríamos.
Nos cenários de times menos colaborativos ou menos experientes é comum que essa situação aconteça no momento de uma entrega em que o desenvolvedor tenta se proteger justificando que uma falha aconteceu por não estar escrito na história.
Sou do time que sempre diz que “o óbvio precisa ser declarado”, mas existem situações em que o óbvio para um, não é obvio para o outro, e é aí que a treta está escondida só esperando os desavisados.
É nesse contexto que o problema parece ser uma falha de discovery, no entanto, o que está escrito na história é uma consequência de conversas e ideias resultantes de desejos de negócio e viabilidade técnica, é uma bola dividida.
Quando o time de desenvolvimento está muito fora do contexto e está pensando somente nos requisitos técnicos, essa treta aparece com mais frequência e o tempo perdido pode custar caro.
Está vivendo essa treta por aí, dá uma olhada como amenizar esse conflito:
1- Valorize a cerimônia de refinamento e garanta que o time técnico está na mesma página, colhendo insights e fornecendo dados de negócio também;
2- Tente alinhar com os integrantes do time que todos estão focados no mesmo objetivo, que é o crescimento da empresa, em tempos de eficiência operacional, tech trabalhando por tech e produto por produto exclusivamente não vai subir a régua do time, só vai gerar custos e atrasos;
3- Inteligência emocional para manter os níveis de colaboração sem julgamento, aqui não é questão de empatia, é negócio. A visão do produto e priorização com foco nos key results são do Product Manager, mas o conhecimento sobre o produto que está trabalhando e qual problema ele resolve é uma responsabilidade de todos;
4- Como Product Manager também é necessário saber jogar em time, dando espaço para que todos falem e promova essa liberdade, instigando as pessoas do time a entenderem cada vez mais do contexto em que estão inseridos e da importância do papel de cada um.
Dito isso, seguimos para a próxima treta.
"A influência de um product manager no produto interno deve ser a menor possível, esse terreno é tech"
Mito e treta grande! O produto interno precisa estar muito alinhado aos objetivos do negócio, sobretudo porque o que é feito na cozinha impacta o que chega na mesa, não é?
Ok ok, não vamos generalizar, como falei aí no alerta, mas isso pode acontecer no seu time ou no time de um amigo seu.
Acontece normalmente quando a engenharia é mais rígida e as pessoas acham que só elas sabem fazer as coisas. É comum nesse cenário ter pessoas de tecnologia que podem estar em dois extremos: não entender nada do negócio ou achar que entende o suficiente para fazer sozinho.
Mas a treta aqui também tem a mea-culpa dos Product Managers e também da liderança. Digo isso porque, se o produto interno é realmente muito complexo é preciso contratar um PM com esse background e quando não é tanto assim, o produto tá ali coladinho no negócio mas é interno, o PM precisa encontrar seu lugar.
Falar é fácil, mas não vamos gerar ansiedade. Está vivendo essa treta por aí? Seguem as dicas práticas:
1- se comunique bem com o seu tech lead e também tenha empatia, é importante vocês lembrarem que são pares aqui nessa jornada;
2- entre no detalhe quando puder, ou seja, toda funcionalidade técnica tem uma razão de ser que pode ser explicada, pergunte, entenda e só então priorize; priorizar sem entender é um tiro no pé;
3- liderar por influência também significa que você precisa falar com os desenvolvedores, essas conversas são muito importantes para você ter clareza do que está acontecendo;
4- estude, o conhecimento só agrega, se você tem o background técnico e o problema é relacionamento, leia sobre como aproximar das pessoas, mas se o que falta aqui é conhecimento técnico estude as ferramentas, você não vai virar um desenvolvedor, mas entender um pouco vai te ajudar a se comunicar melhor e mostrar interesse.
Boa sorte na gestão desse conflito e lembre-se sempre que tretas vão aparecer, e a comunicação é sempre a melhor aliada.
Se deu errado é a culpa é do PM, se deu certo é sucesso do time
Já de partida, parem com essa parada da culpa. O trabalho de construção de um produto não é simples, é uma construção complexa e em conjunto. Não tem que se falar em culpa.
Eu gosto muito de lembrar de um conceito jurídico sobre culpa, para quem não sabe eu sou advogada e migrei para a carreira de Produtos, mas olha só, de forma bem resumida:
Culpa sempre se encaixa em 3 condutas: (i) negligência - quando você poderia fazer algo, mas não faz por opção; (ii) imprudência - é quando você sabe que o que vai fazer vai dar ruim e faz mesmo assim; e, (iii) imperícia - quando você não sabe fazer algo mas diz que sabe e assume o risco ao fazer.
Agir com essas condutas é de fato motivo para se falar em culpa, mas não é isso que vemos no dia a dia de desenvolvimento de produtos digitais, então precisamos manter o foco em dois pontos importantes quando algo dá muito ruim: como solucionar o problema de forma rápida e como não repetir o erro.
Vale refletir aqui sobre responsabilidade. Fazendo um paralelo com o conceito de topologia dos times e também os tipos de produto, quanto mais técnico é o produto, exemplo, um produto externo em desenvolvimento por um time no modelo de Complicated subsystem teams, essas responsabilidades ficam niveladas e o apoio entre produto e tecnologia precisa ser ainda mais intensificado.
Nesse mesmo contexto, quando falamos de times no modo Stream-aligned teams com foco no produto externo, o time de tecnologia não pode ficar muito distante dos objetivos do negócio, porque, certamente, as funcionalidades vão precisar seguir fluxos estratégicos. Mexer em código só por mexer, nesse cenário, é queda de qualidade na certa.
Partiu dicas para amenizar essa culpa, ops, essa treta:
1- gaste tempo procurando a solução e não encontrando os culpados;
2- fale mais sobre histórias, tecnologia e eficiência e fale menos sobre outras pessoas;
3- tenha na rotina como Product Manager apresentar para o time todo como andam os KRs da sua squad, saber o motivo e o resultado do que está sendo feito motiva as pessoas.
São muitas as tretas, mas vamos para a última aqui desse nosso papo.
O papel do Agilista como intermediador de conflitos
Muitos PMs soltaram um sorrisinho nesse momento que eu sei.
Eu deixei essa treta por último por ser uma das que mais geram discussões até mesmo sobre ser positiva ou não a presença do agilista no dia a dia dos times ou até mesmo como uma função mais cross squad.
Já adianto, eu particularmente gosto muito, mas não quero levantar polêmica e vamos falar sobre isso em uma newsletter futura.
Mas quando olhamos para o papel de intermediador, acredito que é um erro. Novamente, os papéis são claros: desenvolvimento para o time de tecnologia, estratégia de negócio e priorização com o time de produtos e o agilista com o processo e cerimônias. O que os três deveriam fazer em harmonia: olhar os números e otimizá-los.
O agilista as vezes se coloca nesse papel de intermediador quando cobra nas cerimônias que cada um realize o que é seu de direito, e nesse caso, no fim do dia é positivo, mas acende um alerta! Precisa mesmo que um facilitador tenha esse papel? Isso demonstra falta de alinhamento do time, e tanto o alinhamento quando a fluidez precisam de tempo para acontecer.
O time como um todo precisa saber quais são suas atividades e obrigações e quando alguém está mais solto é preciso entender os motivos, conversar e achar caminhos para ajudar.
Repare bem, a falta de empatia é algo unânime nas tretas. Mas o excesso dela também gera problemas e sobrecarrega o time. Como diz minha avó: "tudo que é demais estraga".
Soluções para essa treta aqui:
1- ajude a definir os papéis caso eles estejam confusos;
2- alinhe com tecnologia e com o agilista como está a carga cognitiva do seu time e como melhorá-la;
3- lembre que nessa tríade todos são clientes e fornecedores em determinados momentos, bem como stakeholders no processo como um todo, então faça seus reports honrando esse código implícito.
Não se engane com o dream team: se tem, valorize e se não tem, é normal
Trabalhar em time não é tarefa fácil, são muitos aspectos que tornam essa convivência difícil, mas de outra perspectiva, também é uma oportunidade de conviver com pessoas diferentes e diversas. Nos tira da zona de conforto e nos faz crescer.
A busca pelo time perfeito sempre acaba acontecendo, principalmente quando é uma ou no máximo duas pessoas que tem um perfil que destoa dos demais, mas é de fato uma oportunidade de crescimento, de ouvir mais, de entender o contexto da outra pessoa e tentar crescer e entregar resultado independentemente das adversidades.
As dicas aí em cima resolvem muitas, arrisco dizer que quase todas as tretas entre os times de produto e desenvolvimento, mas melhor dica de todas é trabalhar bem a comunicação. Ter coerência no que fala e tentar constantemente encontrar soluções estratégicas para os conflitos são atividades do Product Manager.
E mais uma vez, lembre que você como PM não é responsável pelas pessoas do time, você é dono do produto, da liderança por influência, da gestão dos stakeholders, da gestão de conflitos, de toda uma egrégora que envolve o time e suas entregas, mas não das pessoas.
Deixo você aqui com a reflexão sobre como esses relacionamentos positivos ou não tão positivos assim influenciam nas entregas dos produtos e na eficiência do time.
A nossa newsletter é gratuita e o que nos motiva escrever é ajudar com conteúdo como este, as pessoas. Se gostou, compartilhe com seus amigos e na sua rede social.
Se quiser compartilhar via WhatsApp, clique no botão abaixo…