Alvo ao tiro: o problema com o Desenvolvimento de Produto
Já se vão 10 anos trabalhando com desenvolvimento de produtos digitais. Neste interim, vi mais deles darem errado do que certo. Mas por que nossa taxa de erro é tão alta?
O processo para desenvolvimento de um produto é batido: temos um plano de negócios, um orçamento e previsão de venda. Temos uma lista das coisas que o produto tem que fazer, fruto de uma pesquisa que levantou tudo que os usuários/clientes pediram. Temos um time de engenharia para entregar essas funcionalidades, um time de marketing para bolar uma estratégia de comunicação e criação da demanda, e um time de vendas para, assim que o produto estiver pronto, fazer o lançamento e bater as metas.
E eis que, depois de várias semanas (meses, anos) de noites mal dormidas, o produto fica (mais ou menos) pronto. Isso, ou batemos o prazo imposto pelo plano de negócios para lançamento. O marketing lança a campanha, e eu vejo chamadas do meu produto, meu filho, em rede nacional, pôsteres no ponto de ônibus, e anúncios em página de revista. Corro para a empresa atrás dos números do time de vendas, mas descubro que o resultado não está de acordo com o que era esperado no plano de negócios.
Os clientes do produto — meus clientes — não estavam se comportando como nós esperávamos.
O marketing toma uma coça da diretoria, e começa uma corrida frenética para criar o mercado que justifique todo o dinheiro que foi gasto em fazer aquele produto. O preço diminui, as campanhas ficam mais intensas. Entramos em uma espiral de comoditização do nosso produto. O fim está próximo.
E, sem parar para entender direito o que deu errado até ali, decidimos começar um produto novo.
Este ciclo foi minha realidade durante muitos anos, e sempre me frustrou demais. Eu conseguia identificar qual era o problema: nós começávamos trabalhando unicamente baseados em opiniões, e por mais que fizéssemos pesquisa, ela era enviesada ou por quem fazia as perguntas, ou pelo próprio cliente, que sabe o que quer, mas não sabe de que precisa. Um cliente é capaz de te dizer que amou seu produto e, uma vez que o mesmo está disponível, jamais comprá-lo. E eu não estava preparada para lidar com isso.
Somente quando comecei a ter contato com o conceito de Lean Startup comecei a realmente aceitar que não podíamos nos basear na palavra ou opinião de ninguém — nem do próprio cliente. Apenas cenários reais de uso e verdadeiras reações em contato direto com o produto, ainda que prototipado, nos dariam uma noção real de onde apostar nosso dinheiro. Além disso, por mais legal que seja o seu produto, se ele não resolve um problema realmente importante para seu cliente, ele está fadado a virar commodity, ou desaparecer.
Se você tem um produto fantástico, mas ainda está buscando descobrir que problema ele resolve, você está fazendo alvo ao tiro.
Ao começar a mergulhar no universo do agilismo e ter contato com o Lean Startup, dei uma olhada para trás e percebi que cometi diversos erros, alguns deles muito dolorosos.
O apego ao projeto
O primeiro, e mais comum, é você desenvolver um apego ao projeto. Eu tive times fantásticos, e juntos fizemos coisas maravilhosas. Eu não conseguia conceber como um grupo com mentes tão brilhantes pudesse entregar algo aquém de um produto incrível. Somado a isso, existia um medo real de que, se o projeto acabasse, pessoas perderiam o emprego. Eu me sentia responsável pela vida dessas pessoas, e isso afetava diretamente meu julgamento sobre se aquilo que estávamos entregando poderia realmente dar certo.
O apego à solução
Este é um ponto que eu superei relativamente rápido, mas não sem antes gerar alguns estragos. Quando eu imaginava uma solução para o problema que encontramos, eu me apegava a ela, e evitava ouvir as outras pessoas, no afã de implementar logo o que eu havia pensado. Dei com a cara na parede algumas vezes, e ouvi "eu tentei te avisar", até aprender que uma solução co-criada entre todos os membros do time é sempre mais eficiente do que a solução que eu crio sozinha.
O apego ao problema
Uma vez que eu tinha uma visão de produto definida, era claro para mim quão valioso era aquele produto. Mas isso não significava que o produto seria economicamente viável. Normalmente eu acerto quando aposto que uma determinada solução vai resolver um dado problema (o que já é melhor do que a média dos gerentes de produto ou POs que eu conheço, mas causava o apego à solução que descrevi acima), mas eu era prepotente em achar que o problema que eu escolhi era muito importante para as pessoas que seriam meus clientes.
Eu achava que testar se a solução era eficiente para resolver o problema era bastante.
Demorou muito até que eu me desse conta de que que precisava testar se o problema que eu estava tentando resolver era suficientemente incômodo para justificar que as pessoas gastassem dinheiro para resolvê-lo.
Hoje, minha forma de atuação é um reflexo direto do aprendizado que tirei destes erros. Nem sempre consigo validar se o problema é suficientemente incômodo antes de começarmos a construir o produto, mas tento, com a release 1 nas mãos, validar não apenas a visão de solução, como também se o problema está correto. É importante ter clareza de que, se o problema não for bastante doloroso, o cliente despenderá menos esforço em lidar com o sofrimento de manter as coisas como estão do que em lidar com a dor de mudar e aderir à solução que você pensou.
Siga a tag codelikeagirlBR para ver nossos posts! :D
Quer escrever ou traduzir artigos em português para a Code Like A Girl? Se você já faz parte do time de escritoras(es) da Code Like A Girl basta enviar seu artigo diretamente para nossa publicação. Se você ainda não faz parte do nosso time, envie uma mensagem direta para a conta de twitter CodeLikeAGirlBr. Nós avaliaremos seu artigo e ajudaremos a refiná-lo para publicação.
