Foco no problema

16 min readMay 20, 2021

É da natureza humana resolver problemas. Sempre que ouvimos falar de problemas, entramos quase imediatamente no modo de solução: começamos a buscar soluções para o problema. No entanto, se antes conseguirmos um melhor entendimento sobre o contexto em que o problema ocorre e a motivação para resolvê-lo, há mais chances de conseguirmos encontrar soluções mais simples e fáceis de implementar.

É comum ver outras áreas pedindo à equipe de desenvolvimento de produtos que implemente o recurso A ou B porque precisamos dele para fechar um negócio ou para não perder esse grande cliente. Um exemplo comum que tenho ouvido atualmente é “precisamos implementar o Apple Pay e o Google Pay como um novo método de pagamento”. A questão aqui é que, falando em soluções, perdemos o foco no problema que originou essa solução.

Qual é o problema?

Para ajudar as pessoas a se focarem no problema, pergunte sempre “Qual é o problema?”. Quando uma nova solicitação de funcionalidade chega à equipe de desenvolvimento do produto, devemos agradecer ao solicitante pelo pedido e, em seguida, devemos perguntar sobre o problema que gerou a solicitação. Cada membro da equipe de desenvolvimento de produtos precisa ter esse comportamento sempre que uma solicitação de nova funcionalidade for recebida.

Ao colocar isso em prática, em breve as solicitações virão não apenas com uma solução, mas também com muitas informações sobre o problema. É interessante ver essa mudança cultural, mas requer a disciplina dos membros da equipe de desenvolvimento de produtos para sempre perguntar sobre o problema. E quando menciono os membros da equipe de desenvolvimento de produtos, estou me referindo a todos, não apenas aos gestores de produto, mas também aos designers e às engenheiras e engenheiros de produto.

Mentalidade de problema vs. solução

A principal vantagem de nos focarmos em entender melhor o problema é que, quanto mais tempo investirmos nisso, mais fácil será encontrar uma solução e há boas chances de que essa solução seja mais simples e rápida de implementar do que a primeira solução que pensamos.

Aqui está uma ótima citação de Albert Einstein:

“Se eu tivesse uma hora para resolver um problema, gastaria 55 minutos pensando sobre o problema e cinco minutos pensando nas soluções.”

Einstein acredita que a qualidade da solução que você gera está em proporção direta com sua capacidade de identificar e compreender o problema que espera resolver.

Deixe-me contar uma pequena história para ilustrar isso. Durante a corrida espacial, os cientistas se depararam com o problema de escrever no espaço onde não houvesse gravidade para fazer a tinta cair em uma caneta esferográfica. Os americanos começaram seus esforços de P&D e depois de algum tempo e alguns milhões de dólares, eles construíram uma caneta com um pequeno motor que bombeia tinta para o papel, mesmo sem gravidade. Enquanto isso, os russos decidiram usar lápis.

Essa história mostra um bom exemplo de como pular direto para a solução pode nos fazer gastar tempo e dinheiro desnecessários para chegar a soluções incompletas ou exageradas. É uma questão cultural, ou seja, um comportamento que podemos e devemos mudar. E o primeiro passo para mudar um comportamento é reconhecer quando ele acontece. Quando um membro da equipe de desenvolvimento de produto recebe uma solicitação para implementar algo, ele deve perguntar à pessoa que trouxe a solicitação qual é o problema que esse “algo” deve resolver e por que é necessário resolvê-lo.

Aqui estão alguns exemplos das empresas em que trabalhei.

Na Locaweb, provedora de hospedagem web no Brasil, os serviços de hospedagem e e-mail podem parar de funcionar devido a fatores externos como o domínio que está associado à hospedagem e ao e-mail não ser renovado.

Primeira solução: Registro.br, o registrador brasileiro de domínios .br lançou uma API para permitir que a Locaweb cobrasse o domínio do cliente em nome do Registro.br. A princípio, a ideia parecia boa, já que a Locaweb cobrar o domínio parecia a forma mais fácil de garantir que o cliente saiba que tem que pagar pelo registro do domínio para manter os serviços de hospedagem e e-mail funcionando corretamente. Porém, quando analisamos mais a fundo, vimos que essa solução poderia gerar alguns problemas. O cliente seria cobrado duas vezes pelo mesmo registro de domínio porque o Registro.br continuaria cobrando o domínio. O que acontece se o cliente pagar as duas contas? E se ele pagar apenas o Registro.br? E se ele pagar apenas Locaweb? Além disso, implementar um novo tipo de cobrança em que cobraríamos por um serviço de terceiros era algo novo para a equipe da Locaweb. Novos processos teriam que ser cuidadosamente projetados.

Solução real: começamos a nos perguntar se haveria maneiras mais simples de resolver o problema de ajudar nosso cliente a não esquecer que ele tem que pagar pelo registro de domínio no Registro.br. Como seria possível cobrar pelos serviços do Registro.br, foi possível acessar as informações sobre o domínio prestes a expirar. Decidimos desenhar uma solução mais simples: implementar uma régua de comunicação com este cliente avisando-o da importância de pagar ao Registro.br para garantir que os serviços de e-mail e hospedagem continuem funcionando normalmente. Esta é uma solução muito mais simples do que implementar um processo de faturamento dobrado. Se o Registro.br nos fornecer a URL de cobrança, podemos enviar as informações desse link ao cliente e as chances de solucionar o problema aumentarão ainda mais. E uma sequência de comunicação é muito mais simples e rápida de implementar do que um processo de faturamento duplicado.

Na Conta Azul, um ERP SaaS para MPEs (micro e pequenas empresas), usamos contadores como um de nossos canais de distribuição e queríamos aumentar as vendas por meio de contadores.

Primeira solução: compras em lote, onde os contadores adquiririam um número fixo de licenças do Conta Azul para revender aos seus clientes. Um sistema de gerenciamento de compras em lote levaria cerca de 3 meses para ser implementado, pois deveria permitir que os contadores comprassem licenças da Conta Azul a granel, mas só deveria começar a cobrar do cliente da contadora quando esse cliente realmente ativasse a licença.

Solução real: os contadores não se importavam com as compras em lote. O que eles queriam era dar um desconto aos seus clientes para que eles pudessem assinar a Conta Azul com esse desconto exclusivo proporcionado por seu relacionamento conosco. O custo para implementar isso foi zero, pois o sistema já tinha um recurso de gerenciamento de descontos.

No Gympass, um parceiro de fitness que estava ingressando em nossa rede solicitou que apresentássemos seu waiver (termo de isenção de responsabilidade) a todos os usuários que fizessem o check-in em suas instalações.

Primeira solução: mudar nosso aplicativo para pedir aos usuários que vão a este parceiro de fitness que leiam seu waiver em nosso aplicativo e marquem um checkbox informando que leram e estão de acordo.

Solução real: nenhuma alteração em nosso aplicativo. Usamos um campo de texto personalizável na configuração de uma academia em nosso sistema que normalmente é apresentado aos usuários que farão check-in nessa academia para apresentar o seguinte texto: “Ao fazer o check-in, você concorda com os termos e condições localizados em http://fitnesspartner.com/waiver”.

Não me interprete mal, é muito bom que todos tragam soluções sempre que quisermos discutir algo a ser feito pela equipe de desenvolvimento de produto. Quanto mais ideias de solução tivermos, melhor. No entanto, precisamos nos educar para ter um entendimento mais profundo do problema por trás dessa solução, para que tenhamos a chance de encontrar soluções mais simples e rápidas para implementar. E é, em última análise, o trabalho da gestora de produto e de todos os membros da equipe de desenvolvimento de produto perguntar qual é o problema e por que precisamos resolvê-lo.

Projetos vs. problemas

O ano novo é tempo de retrospectiva e planejamento. O que normalmente é feito a cada trimestre pela maioria das equipes de desenvolvimento de produtos é feito de forma mais intensa na virada do ano, em conjunto com outras áreas da empresa. É o processo de planejamento anual, que normalmente vem junto com o processo de orçamento. O que faremos neste novo ano que está chegando? Quais são os principais projetos que trabalharemos ao longo do ano?

Mesmo que o planejamento seja superimportante para ter clareza sobre quais projetos são prioridades para o novo ano, esta lista de projetos pode fazer você perder de vista um aspecto muito importante do planejamento, o “porquê”.

Não é incomum ver o planejamento de ano novo para uma equipe de desenvolvimento de produto, e até mesmo para toda a empresa, como uma lista de projetos. Para ajudá-lo a ver sua lista de projetos em um ângulo diferente, adicione 2 colunas:

uma para descrever quais são os problemas que você está tentando resolver em cada projeto;
e outra para descrever para quem você está tentando resolver este problema.

Já discuti as questões de ter uma mentalidade orientada para a solução versus uma mentalidade orientada para o problema, mas quando se trata de planejamento de ano novo, esse problema fica ainda mais evidente. Os benefícios de ter clareza sobre os problemas que deseja resolver e para quem você planeja resolvê-los são:

Garantir que os problemas estejam alinhados com a visão e estratégia da empresa: quando focamos em projetos, é fácil perder de vista os problemas que estamos tentando resolver, para quem planejamos resolver, e se são esses problemas que realmente precisamos resolver.

Definir quais problemas são mais importantes para resolver: priorizar projetos sem saber quais problemas esses projetos resolvem, e para quem, pode tornar as prioridades não alinhadas com o que é realmente importante para a empresa. Porém, para sermos mais eficazes em trazer o resultado desejado, devemos priorizar os problemas a serem resolvidos e garantir que a priorização esteja alinhada com a visão e estratégia da empresa.

Resolver mais de um problema com o mesmo projeto: às vezes, você pode descobrir que está tentando resolver mais de um problema com um projeto, e isso pode não ser um problema. Mas você precisa saber disso. Talvez você possa ter soluções mais simples se tratar cada problema separadamente. Talvez nem todos valham a pena resolver neste momento.

Verificar se os projetos são as melhores soluções: quando mudamos o foco dos projetos para os problemas e temos uma visibilidade clara da prioridade dos problemas, fica mais fácil verificar se os projetos listados são a melhor solução para o problema em questão. Às vezes, podemos encontrar soluções que são mais fáceis de implementar quando mudamos nosso foco para a compreensão dos problemas.

Então pegue sua lista de projetos e crie essas duas colunas, problemas a serem resolvidos em cada projeto e para quem os problemas serão resolvidos. Isso ajudará você a se concentrar nas coisas mais importantes para este novo ano.

Equipes solucionadora de problemas vs. equipes implementadoras de solução

Marty Cagan, uma referência bem conhecida na comunidade de produtos digitais, escreveu há algum tempo um artigo interessante sobre equipes de produtos x equipes de funcionalidades, onde explica a diferença entre três tipos de equipes, as equipes de entrega, as equipes de funcionalidades e as equipes de produto. Ele define de cada tipo de equipe da seguinte forma:

As equipes de entrega não são multifuncionais (basicamente apenas desenvolvedores mais um product owner que administra o backlog), não estão focadas no resultado (as pessoas são todas orientadas à entrega de funcionalidades) e não têm autonomia (estão lá para codificar e entregar).
As equipes de funcionalidades geralmente são multifuncionais (têm pelo menos uma designer e uma gestora de produto), mas ainda se preocupam com a produção e entrega de funcionalidades.
As equipes de produto são multifuncionais, focadas e avaliadas pelo resultado, e têm autonomia para apresentar soluções que funcionem.

Ele explica que os melhores resultados para a organização dona do produto e para os usuários desse produto vêm das equipes que ele chama de equipes de produto. Ele tem usado muito a palavra empoderado (empowered) para descrever esses times.

Qualquer produto digital existe para dois propósitos principais:

Ajudar a empresa dona do produto digital a atingir seus objetivos.
Resolver os problemas e atender as necessidades de seus usuários.

Portanto, qualquer produto digital e suas funcionalidades são soluções para problemas da empresa dona do produto e soluções para resolver os problemas do usuário e atender às suas necessidades.

Neste contexto de produto digital, quando digo que gastar mais tempo entendendo o problema produz as melhores soluções, quero dizer que somos capazes de entregar o mais rápido possível o melhor produto e funcionalidades para resolver o problema em mãos com software de boa qualidade e boa experiência de usuário.

Solucionar problemas vs. implementar solução

O que Marty descreve como equipes de entrega e equipes de funcionalidades são equipes de implementadores de soluções. Essas equipes 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, um diretor, um vice-presidente ou um fundador. Em tal equipe, 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 mesmo se a solução implementada realmente resolve o problema. Podem também ser chamadas de “fábrica de funcionalidades”. Sua performance é medida pela quantidade de funcionalidades que o time produz.

Por outro lado, o que Marty descreve como equipes de produto empoderadas são equipes de solução de problemas. Essas equipes 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, eles são capazes de implementar a melhor solução para o problema em questão.

Existem três razões principais pelas quais as equipes de solução de problemas são mais eficazes do que as equipes de implementadores de soluções:

Conhecimento de produto digital: não há ninguém melhor do que os membros da equipe para encontrar a melhor solução de produto digital para um problema. Uma solução entregue o mais rápido possível, com boa qualidade de software e boa experiência do usuário. Isso acontece porque uma equipe de solucionadores de problemas é uma equipe multifuncional composta por engenheiros que entendem a tecnologia disponível, designers de produto, que têm um conhecimento profundo dos usuários, suas dores e necessidades, e gestores de produto, que têm um bom entendimento do contexto empresarial do problema a ser resolvido.

Duas cabeças pensam melhor do que uma: este velho ditado significa que é mais fácil para duas pessoas que se ajudam resolverem um problema do que para uma pessoa resolver um problema sozinha. Uma equipe de solucionadores de problemas não descarta nenhuma sugestão de solução das “áreas de negócios”. Na verdade, essas sugestões de solução são muito úteis para ajudar a equipe a entender melhor o problema, mas elas devem ser consideradas dessa forma, sugestões. Uma equipe de solucionadores de problemas primeiro entende profundamente o problema e, em seguida, analisa as opções de solução.

Compromisso: um efeito colateral adicional de uma equipe de solução de problemas é que os membros dessa equipe estão profundamente comprometidos com o sucesso da implementação da solução, uma vez que estão profundamente envolvidos no processo de busca da solução.

Criação de equipes de solução de problemas

Agora que expliquei por que as equipes de solução de problemas são o melhor tipo de equipe de produto que uma empresa pode ter, explicarei como construir equipes de solução de problemas. Existem três aspectos que precisam ser considerados:

Ambiente: é fundamental que toda a organização entenda o poder de ter equipes de produtos digitais para solução de problemas. A velocidade e a qualidade das soluções entregues por uma equipe de produto digital que sempre começa a resolver os problemas a partir de um entendimento profundo do problema é muito melhor do que as soluções entregues por equipes de implementadores de soluções. Consequentemente, os resultados do negócio serão melhores e mais rápidos. É função e responsabilidade do head de produto ajudar a organização a entender isso.

Qual é o problema: uma maneira muito eficaz de enfocar toda a organização para longe da mentalidade de solução e mais próximo da mentalidade de problema é perguntar constantemente “Qual é o problema que estamos tentando resolver?” e “Por que é importante resolver este problema?”. Isso ajudará as pessoas de toda a organização a mudar sua perspectiva e, consequentemente, perceber a importância de um entendimento profundo do problema antes de implementar uma solução. Essa é uma mudança de comportamento que toda a equipe de desenvolvimento de produto digital pode ajudar sua organização a fazer. Sempre que alguém pede à equipe de produto para implementar algo, pergunte “Qual é o problema que estamos querendo resolver?”.

Confiança: este é um aspecto crítico para construir equipes bem-sucedidas de produtos digitais de solucionadores de problemas. Normalmente as pessoas da “área de negócios” acreditam ter um melhor entendimento do negócio do que as da equipe de produto. Esse comportamento fica ainda mais visível quando a equipe de produto digital é nova na organização. Como uma pessoa nova na organização pode entender mais sobre o negócio do que quem está na empresa há anos? Provavelmente ela não pode, especialmente se ela vier de um mercado diferente. No entanto, quem faz parte da equipe de produto digital normalmente tem muita experiência na construção de produtos digitais, provavelmente mais experiência do que qualquer outra pessoa na organização.

Por isso, é fundamental que a “área de negócios” eduque a equipe de produto digital sobre os aspectos de negócios da organização. Essa busca por educação é papel e responsabilidade dos gerentes de produto, que devem aprender com a “área de negócios” e educar designers e engenheiros de produto sobre o negócio. Uma forma prática de acelerar esse aprendizado é trazer pessoas da “área de negócios” para as sessões de discussão sobre o problema. É assim que a equipe de produto ganha a confiança das demais áreas da organização.

Acredito que estão claros os benefícios de ter equipes de produto digital de solucionadores de problemas versus implementadores de solução. Toda a organização precisa entender a diferença a fim de pressionar por mais e mais equipes de resolução de problemas. A head de produto tem essa como uma de suas maiores responsabilidades, ajudar a construir o ambiente e a confiança necessária para o sucesso das equipes de solução de problemas.

A armadilha do top-down

Quando falo sobre as diferenças entre equipes solucionadoras de problemas vs equipes implementadoras de solução, normalmente ouço comentários como “Queremos ser uma equipe de solucionadores de problemas, mas na minha empresa todas as soluções são top-down e a única coisa que podemos fazer é implementá-las”.

Essas situações agravam-se quando surge pressão. A pressão mais recente que muitas empresas estão sofrendo é a crise do COVID-19. Na ânsia de resolver os problemas o mais rápido possível, os líderes da empresa pedem às equipes que implementem esta ou aquela solução de maneira rápida, muito rápida.

A armadilha

Deixe-me agora abordar o elefante na sala, o ambiente de tomada de decisão top-down. Isso tem um impacto enorme em qualquer equipe neste tipo de ambiente. Sem fazer parte da decisão sobre a solução, as pessoas que implementam a solução acabarão por ficar desmotivadas.

Por que estou chamando de armadilha do top-down? Porque muitos dos ambientes de tomada de decisão percebidos como top-down são isso que acabei de escrever, uma percepção.

Vamos usar a principal característica que toda gestora de produto deve ter, empatia. A habilidade de alguém se colocar no lugar de outra pessoa para entender suas aspirações, motivações, necessidades e problemas. Pessoas com quem tive a oportunidade de falar sobre as características essenciais de um gestor de produto sabem o quão importante considero a empatia como um traço crítico para PMs de sucesso.

Aqui estão 2 dicas para ajudar os membros da equipe de produto a ter empatia com os chamados tomadores de decisão top-down e escapar da armadilha de cima para baixo:

Compreendendo a situação: coloque-se no lugar do solicitante da implementação de solução. As pessoas resolvem problemas, é a natureza delas, e sempre que se deparam com um problema, pulam para o modo de solução e tentam encontrar e implementar soluções o mais rápido possível. Sob maior pressão, como a crise COVID-19, o desejo de encontrar e implementar soluções é exacerbado. Na maioria dos casos, as pessoas não querem ser tomadores de decisão top-down, elas simplesmente têm uma necessidade de resolver o problema o mais rápido possível.
Alterando o status quo: faça perguntas sobre a solicitação de implementação de solução. Que problema estamos resolvendo? Para quem? Por que é importante resolver esse problema? Por que agora? Por que precisamos entregar algo rápido, mesmo comprometendo a qualidade? Se lhe perguntarem o motivo de tantas perguntas, explique que está tentando entender melhor o problema para ver se existem outras soluções mais baratas e rápidas.

Essas dicas ajudarão todos na equipe de produto a fazer a mudança para um processo de tomada de decisão mais colaborativo.

Na maioria das vezes, as pessoas entendem os benefícios de um processo colaborativo de tomada de decisão. Mesmo sob pressão, as soluções colaborativas produzirão melhores resultados. Soluções concebidas em um processo colaborativo são normalmente mais baratas e rápidas de implementar porque mais pessoas tiveram a chance de discutir as opções de solução e a equipe que implementará a solução selecionada estará verdadeiramente comprometida com seu sucesso.

Para construir, manter e melhorar as equipes de solução de problemas e evitar transformá-las em equipes de implementação de soluções, especialmente quando sob maior pressão, é fundamental evitar a armadilha do top-down.

Os heads de produto têm o papel e a responsabilidade de promover essas mudanças de comportamento para ajudar a construir um processo de tomada de decisão mais colaborativo e, consequentemente, mais eficaz.

Resumindo

Um passo muito importante para criar uma boa solução é a compreensão do problema. Quando ouvimos sobre um problema, imediatamente começamos a pensar nas soluções. No entanto, quanto mais tempo gastamos aprendendo sobre o problema, mais fácil será encontrar uma solução e há boas chances de que essa solução seja mais simples e rápida de implementar do que a primeira solução que pensamos.
Se você tiver uma lista de projetos para fazer, crie duas colunas a mais nessa lista, uma para problemas a serem resolvidos em cada projeto e outra para quem os problemas serão resolvidos. Isso ajudará você a se concentrar nos problemas a serem resolvidos, e não nos projetos, que são a solução.
Equipes de implementação de solução são equipes trabalham na implementação de uma solução concebida por outra pessoa. Equipes de solução de problemas são equipes 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, eles são capazes de implementar a melhor solução para o problema em questão.
A armadilha top-down é a percepção do processo de tomada de decisão sendo feito pelos líderes da empresa, sem oportunidade de participação do resto dos funcionários. Essa percepção é exacerbada quando uma empresa enfrenta uma pressão crescente, como a crise do COVID-19.
As pessoas são orientadas para a solução e, quanto maior a pressão, mais rápido as pessoas desejam que as soluções sejam implementadas.
Para ajudar a lidar com essa situação, use a empatia para entender o ponto de vista do solicitante de implementação da solução e pergunte a ele por que é necessário implementar a solução solicitada.
Os heads de produto têm a função e a responsabilidade de promover essas mudanças de comportamento para ajudar a construir um processo de tomada de decisão mais colaborativo.

No próximo capítulo vamos entender mais sobre o foco em entrega de resultados.

Liderança de produtos digitais

Este artigo faz parte do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros: