Trabalho há algum tempo em empresas em transformação digital ou que possuem pessoas (inclusive C-levels) não familiarizadas com métodos de desenvolvimento de produtos digitais.

Um dos maiores desafios dessas empresas é passar de uma mentalidade de “o time de negócios demanda → o time de tecnologia implementa” para uma mentalidade de “o negócio traz problemas/necessidades → a tecnologia trabalha na compreensão desses problemas/necessidades com o usuário, testando hipóteses de solução e implementando uma hipótese de solução validada”.

Normalmente, as pessoas de negócios tendem a pensar e dizer coisas como “Eu sou a pessoa de negócios, então sou a pessoa que mais entende sobre nossos problemas/necessidades de negócios e como resolvê-los. Você apenas tem que implementar o que eu digo”. Essa pessoa de negócios está pensando na equipe de tecnologia como uma equipe de implementadores de soluções, não uma equipe de solução de problemas.

Equipes de implementadores de soluções são equipes que trabalham na implementação de uma solução concebida por outra pessoa. E essa outra pessoa normalmente é alguém da chamada “área de negócios”, que pode ser alguém de vendas, marketing, sucesso do cliente, suporte ao cliente, finanças, operações, ou até mesmo uma diretora, uma vice-presidente ou uma fundadora. Nessas equipes, o gerente de produto gerencia principalmente o backlog e ajuda a equipe a entregar a solução solicitada, o designer de produto se concentra principalmente em desenhar uma interface agradável e os engenheiros têm que codificar e implantar a solução solicitada.

As equipes de implementação da solução fazem o que foi solicitado, com pouco ou nenhum compromisso com a qualidade da solução ou até mesmo se ela realmente resolve o problema. Essas equipes podem também ser chamadas de “fábrica de funcionalidades”, “time de funcionalidades” ou “time de entregas”. Sua performance é medida pela quantidade de funcionalidades que o time produz.

Por outro lado, as equipes de solução de problemas são equipes que trabalham para compreender profundamente as causas do problema, o contexto e a motivação que as pessoas têm para resolvê-lo. Ao fazer isso, elas são capazes de testar diferentes possibilidades de solução e de implementar a melhor solução para o problema em questão. Esse tipo de time também é conhecido como “time de produto” ou “time de produto empoderado”.

Então, por que o modelo “negócios demanda → tecnologia implementa” não funciona?

Em vez de dar apenas um motivo, vou listar seis motivos:

1. O modelo “negócios demanda → tecnologia implementa” dificilmente produzirá produtos inovadores que os clientes amem. Isso acontece porque as pessoas de negócios não sabem o que é possível. Saber o que é possível e testar hipóteses de solução é uma das principais responsabilidade de um time de desenvolvimento de produtos.

2. Empresas de tecnologia de sucesso como Apple, Amazon, Google e Netflix não usam o modelo “negócios demanda → tecnologia implementa” para construir seus produtos de sucesso. Eles preferem o uso do modelo de desenvolvimento de produto “negócio traz problemas/necessidades → a tecnologia trabalha na compreensão desses problemas/ necessidades com o usuário, testando hipóteses de solução e implementando uma hipótese de solução validada”, pois sabem que esse modelo traz os melhores resultados.

3. O modelo “negócios demanda → tecnologia implementa” gera uma posição de adversário entre os times de negócios e de tecnologia e, consequentemente, o comprometimento e engajamento da equipe de tecnologia diminui, o que causa alta rotatividade de pessoal e aumento da frustração das pessoas de negócios, o que acaba gerando um círculo vicioso.

4. As pessoas de tecnologia não se sentem responsáveis pelo resultado do que constroem, pois a área de negócios definiu o que fazer.

5. A área de negócios pode exigir desenvolvimentos que sejam bons para os interesses individuais de cada área de negócios, mas não necessariamente bons para a empresa.

6. A área de negócios pode pedir coisas complexas, que causarão longos ciclos de desenvolvimento — e quanto mais longos forem estes ciclos, maior a frustração gerada e maiores as chances de a entrega não satisfazer as necessidades e gerar os resultados esperados.

O outro modelo realmente gera melhores resultados?

O fato de o modelo de trabalho “negócios demanda → tecnologia implementa” ter muitos problemas não significa necessariamente que o outro modelo realmente gera melhores resultados. Para responder a essa pergunta, se o modelo de trabalho em que o “negócio traz os problemas/necessidades → a tecnologia trabalha na compreensão desses problemas/ necessidades com o usuário, testando hipóteses de solução e implementando uma hipótese de solução validada” entrega melhores resultados, compartilharei um case interessante.

Quando entrei na Lopes, a equipe estava trabalhando em um “MVP” de um aplicativo para seus corretores. Coloquei aspas porque estava em desenvolvimento há 7 meses e ainda faltavam 2 ou 3 meses para ele ser entregue. Quando me aprofundei um pouco mais sobre o processo e por que estava demorando tanto, aprendi algumas coisas:

• O discovery durou algo em torno de 5 meses!;
• O discovery foi focado apenas na descoberta do problema, não na descoberta da solução;
• O discovery foi feito apenas internamente, com levantamento de demanda das áreas de negócios e benchmarking com outros aplicativos para corretores disponíveis no mercado, sem nenhuma conversa com clientes;
• O “MVP” foi definido com 58 requisitos e funcionalidades e já havia mais 90 requisitos e funcionalidades com escopo definido para serem desenvolvidos após o lançamento do “MVP”;
• O principal problema a ser resolvido foi baseado na hipótese de que, se a corretora recebeu um lead, que é um potencial cliente interessado em um imóvel, quanto mais rápido ela receber esse lead e interagir com o cliente, maiores serão as chances de fechar um negócio;
• Em seguida, a equipe analisou a jornada da corretora e percebeu que, quando um lead chega, a corretora precisa pesquisar no banco de dados de potenciais clientes da Lopes para verificar se o potencial cliente do lead já está em nosso banco de dados e, caso não esteja, cadastrar seus dados em nosso sistema.
• A partir dessa análise da jornada da corretora, o time percebeu então que, se a corretora pudesse enviar algumas outras opções de imóveis para o cliente em potencial, isso aumentaria as chances de fechar um negócio;
• Esse processo criou o escopo a ser implementado, que levou em torno de 5 meses de discovery, mais 7 a 8 meses de desenvolvimento para construir o aplicativo “MVP”.

Há alguns pontos a se destacar desse processo:

• O processo de descoberta do problema foi muito longo, o que gerou uma enorme lista de problemas da corretora a serem resolvidos;
• A fase de descoberta da solução não foi executada. A equipe passou da descoberta do problema diretamente para a entrega, sem qualquer oportunidade de testar hipóteses de solução;
• A enorme lista de problemas a serem resolvidos impactava diretamente o processo de desenvolvimento de produto, tornando-o muito longo também;
• Se o trabalho de descoberta de solução fosse iniciado assim que o problema principal fosse descoberto (velocidade em colocar o lead na mão da corretora), provavelmente a equipe conseguiria conceber uma solução mais simples, que levaria dias e não meses para ser implementada.

Em relação a esse último ponto, após algumas discussões, pensamos em um aplicativo com apenas uma notificação push para cada lead recebido, e a corretora poderia continuar as outras tarefas como já estava habituada a fazer. E, para ser ainda mais simples de testar a hipótese da solução, pensamos em nem construir um aplicativo, mas enviar um SMS ou uma mensagem de WhatsApp para a corretora. Um teste A/B pode ser feito para comparar as taxas de fechamento de negócios dos corretores que receberam notificação por SMS com as taxas de fechamento dos corretores que não receberam.

Mesmo tendo avançado bastante no desenvolvimento do app, acabamos tomando a decisão de implementar a notificação por SMS. Demoramos 10 dias para implementá-la e logo em seguida conseguimos testar a hipótese de que, quanto mais rápido um corretor receber um lead e interagir com o cliente, maiores as chances de fechar um negócio.

Esse exemplo do app para corretores da Lopes mostra a importância dos dois princípios que acabamos de ver: a necessidade de 1) entregarmos rápida e frequentemente, e 2) de focarmos no problema e entendê-lo bem para criarmos e testarmos hipóteses de solução antes de desenvolver o produto.

Como transformar um time de funcionalidades em um time de produto?

Uma equipe de produto recebe um problema para resolver e um resultado para alcançar. A equipe tem total autonomia para decidir como resolver o problema e alcançar o resultado e é incentivada a fazê-lo o mais rápido possível. Idealmente, a equipe também tem autonomia para definir qual problema resolver e qual resultado alcançar.

As equipes de produto precisam alcançar resultados, não apenas entregar produtos e funcionalidades. Os produtos e funcionalidades entregues são meios para gerar resultados para a empresa proprietária do produto e solucionar um problema ou suprir uma necessidade da cliente. Esse resultado para a empresa pode significar mais receita, redução de custos, aumento do engajamento do cliente etc.

Algumas equipes e pessoas não estão dispostas a se preocupar com os resultados do negócio. Elas preferem que lhes digam o que entregar e trabalham para entregar o que foi pedido. Nesse caso, elas devem procurar por empresas em que receber instruções sobre o que fazer seja a prática comum. Contudo, tenho notado que o número de locais que trabalham dessa forma está diminuindo, e em breve será difícil encontrar empresas assim, da mesma forma que hoje é muito difícil encontrar locais onde o waterfall (modelo cascata) seja o processo de desenvolvimento de software preferido.

Por outro lado, algumas equipes e pessoas podem estar dispostas a se preocupar com os resultados de negócios, mas não estão equipadas com o conhecimento necessário para entender o negócio. Essas pessoas precisam ser educadas sobre como o negócio funciona para que possam criar maneiras de gerar impacto por meio da tecnologia.

A equipe de funcionalidades está pronta para se transformar em uma equipe de produto.

Ok, então você acredita que o time de funcionalidades está pronto para se tornar um time de produto! O time de funcionalidade não só está disposto a se tornar um time de produto como também tem o entendimento de negócio necessário para impactá-lo com tecnologia. Então é hora de trabalhar na transição da equipe de funcionalidades para uma equipe de produto.

Essa transição deve ser considerada sob duas perspectivas:

1. Pessoas de negócio: sempre que as pessoas de negócio trazem novas solicitações para uma equipe de produto, elas precisam trazer essas solicitações no formato de problemas a serem resolvidos e resultados a serem alcançados. Devem abster-se de trazer soluções ou, caso tragam uma solução, deixar claro que se trata de uma hipótese de solução, não de uma solicitação de implementação de solução, e o time de produto tem total autonomia para levantar outras hipóteses de solução a serem testadas. É normal que as pessoas da empresa participem da descoberta da solução, mas a contribuição deve vir sempre na forma de colaboração, não de imposição.

2. Time de produto: o time de produto precisa ser proativo para impactar o negócio. Sempre que ao time for solicitado implementar uma determinada solução, ele deve perguntar qual é o problema que estamos tentando resolver com essa solução solicitada e quais são os resultados esperados. Se a pessoa que está perguntando (pessoa de negócios, gerente, C-level, founder) não estiver disposta a responder, explique a ela que se o time de produto souber o problema a ser resolvido e o resultado a ser alcançado, ele poderá descobrir soluções que podem ser mais rápidas de implementar.

E se as pessoas de negócios disserem que a equipe deve apenas implementar o que foi pedido?

Em alguns casos, pode acontecer de as pessoas de negócio não estarem dispostas a dizer qual o problema a ser resolvido e o resultado a ser alcançado. Elas podem simplesmente dizer que sabem o que estão pedindo e que a equipe deve focar em implementar o que foi pedido. Nesse caso, a minha recomendação para as pessoas do time de produto é: procurem outro lugar para trabalhar, a menos que estejam dispostas a trabalhar como time de funcionalidades.

Um time de produto sempre recebe problemas para resolver e resultados para alcançar. A equipe deve ter total autonomia para descobrir formas de resolver o problema e chegar ao resultado o mais rápido possível. Essa autonomia é necessária porque a equipe de produto possui o conhecimento e a experiência em tecnologia e em desenvolvimento de produtos digitais necessários para chegar às melhores soluções. Idealmente, o time de produto também tem autonomia para definir qual problema resolver e qual resultado alcançar. Esse é o estágio maior de maturidade de um time de produto. Nesta etapa, o time entende muito sobre o negócio para definir, com contribuições das pessoas de negócios, em quais problemas focar e quais resultados alcançar.

Transformação digital e cultura de produto

Esse artigo é mais um trecho do meu mais novo livro “Transformação digital e cultura de produto: Como colocar a tecnologia no centro da estratégia da sua empresa“, que vou também disponibilizar aqui no blog. Até o momento, já publiquei aqui:

• Sobre o livro
• Parte 1: Conceitos
  • Capítulo 1: A tal da transformação digital – Projeto e Produto
  • Capítulo 2: Incerteza e transformação digital
  • Capítulo 3: Tipo de empresa
  • Capítulo 4: Tipo de empresa x maturidade digital
  • Capítulo 5: Modelos de negócio
  • Capítulo 6: Cultura ágil, digital e de produto
• Parte 2: Princípios
  • Capítulo 7: Entregas rápidas e frequentes – Medindo e gerenciando a produtividade – Estudo de caso: Grupo Dasa – Estudo de caso: Itaú Unibanco
  • Capítulo 8: Foco no problema – O Famoso Discovery de Produto