Erre Rápido!

Pensando em produtos digitais é a melhor coisa a fazer. O Product Discovery existe exatamente para isso: descobrir o que vale a pena ser feito antes de gastar tempo, dinheiro e energia com ideias que parecem boas, mas não se sustentam. No artigo Erre Rápido!, você vai entender como pensar em produto, como validar hipóteses, quais riscos evitar e por que o erro, quando bem usado, é o melhor amigo da inovação.

Mas, além do artigo Erre Rápido!, aqui no blog também temos diversos outros artigos sobre kubernetes, desenvolvimento, gestão, devops, etc. Veja alguns exemplos: Diferenças entre Paradigmas, Axiomas e Hipóteses, Desenvolver na empresa ou comprar pronto, Fuja da otimização prematura, entre outros.

O que é Produto?

Produto é algo que entrega valor de forma contínua, adaptando-se ao tempo, ao mercado e ao usuário. Diferente de um projeto que tem início, meio e fim bem definidos, o produto é vivo. Ele até pode nascer de um projeto, mas continua evoluindo depois que esse projeto termina. Melhorias, correções e novas funcionalidades surgem constantemente, muitas vezes por meio de novos projetos que o alimentam. Um serviço nasce quando acaba um projeto, sendo algo vivo, mas melhorias ocorrem sempre que novos projetos o incrementam.

O produto é, na verdade, a mistura dessas duas ideias: nasce como projeto, vive como serviço e cresce com ciclos contínuos de evolução. Essa dinâmica casa perfeitamente com a mentalidade ágil, que pressupõe adaptação constante, entregas incrementais e feedback contínuo. Ao pensar em produto, a equipe assume o compromisso de entregar valor hoje e continuar relevante amanhã, sempre de olho no problema real que precisa ser resolvido.

Erre antes, erre Rápido!

Product Discovery é o processo de descobrir, com o mínimo de desperdício possível, o que realmente vale a pena ser construído. Ele ajuda times a criarem produtos relevantes, desejáveis e viáveis. Investir energia nessa etapa aumenta muito as chances de sucesso. Pode parecer estranho, mas a ideia central é: erre Rápido!

Ciclo de vida do produto: Discovery x Delivery

Discovery é sobre o o quê um produto deve ser e delivery é o como: um precisa do outro. O Discovery nutre o delivery e o delivery retroalimenta o discovery, é um ciclo infinito motivado por resultados.

O ciclo do produto costuma seguir quatro fases. Primeiro, temos a Introdução: onde poderia gastar muito dinheiro, onde a aposta é grande. O time precisa entender o cliente o mais rápido possível. Por isso técnicas como MVP são muito bem vindas nessa etapa. Depois vem o Crescimento: o produto dá sinais de sucesso, ainda não se pagou, mas tem tração. Em seguida, a Maturidade: agora o produto está em “voo de cruzeiro”. O produto é lucrativo (ou dá o retorno esperado, para empresas que não pretendem se pagar no curto prazo) e o foco é sustentar esse estágio o maior tempo possível. Por fim, o Declínio: quando o mercado muda, concorrentes aparecem ou simplesmente o produto perde o sentido.

Note que o gráfico tem o tempo no eixo x e o dinheiro retornado no eixo y. É comum esperar o breakeven na fase de maturidade, mas isso varia muito de caso a caso. De todo modo é ali que o negócio visa pagar todos os custos e passar a ser lucrativo. Nessa fase o capital gerado pode servir para remunerar os sócios ou para crescer o negócio.

Retornando o investimento

Quando falamos sobre investimento em produtos digitais, é essencial olhar além do código. Ferramentas como VPL (Valor Presente Líquido) e TIR (Taxa Interna de Retorno) ajudam a entender se vale a pena colocar dinheiro em determinada iniciativa. O VPL calcula quanto um projeto vai gerar de valor ao longo do tempo, descontando os custos e ajustando tudo para o valor de hoje (para fins de comparação). Já a TIR mostra a taxa de retorno esperada: se ela for maior que a taxa mínima exigida pela empresa, o projeto pode ser interessante. Essas métricas tornam tangível a ideia do “gerar valor” de um produto. Outro indicador importante é o Payback, que mostra em quanto tempo o investimento será recuperado. Ele é mais simples que o VPL e a TIR, mas muito útil para decisões rápidas.

Por fim, vale também comentar sobre o Custo de Oportunidade, que é basicamente o que se deixa de ganhar ao escolher uma opção em vez de outra. Não pensar nisso pode ser fatal. Não é razoável criar qualquer funcionalidade que der na telha, mas sim priorizar de maneira inteligente, observar os resultados e reorganizar esse backlog.

Sistema de Troca de Valor

Pensa comigo, quando se faz o discovery se estrutura as necessidades, e quando se faz o delivery se produz e entrega das funcionalidades. Elas são entregues para clientes, que por sua vez, gostam ou não. Esse feedback, de alguma maneira é dado, cabendo a empresa dona do produto saber ler isso.

Vamos ver isso de outra forma, temos de um lado o negócio, dono do produto. Ele tem a responsabilidade de entender a necessidade, resolver, observar, melhorar a jornada, criar a experiência e entregar as emoções certas no momento certo da jornada. Se o negócio faz isso adequadamente ele gera valor. Mas como saber se o valor foi efetivamente gerado? Aí entra o cliente que reconhece isso remunerando-o ou apenas consumindo (a depender do tipo de produto). Mas quando ele não consome, quando ele age de modo não desejado, cabe ao negócio saber extrair esses dados e voltar para o discovery, melhorando tudo o que comentamos. Chamamos tudo isso de sistema de troca de valor.

O PO/PM são profissionais que caminham no meio do discovery e do delivery, garantindo que esse fluxo de melhoria contínua ocorra do melhor modo, dos dois lados.

O Discovery

Apaixone-se pelo problema, não pela solução

A tentação de sair defendendo uma solução é grande. A questão é que você dificilmente é o cliente real do produto que está desenvolvendo ou mesmo está dentro da jornada do mesmo jeito que se espera de um cliente. Desenvolvedores costumam ter soluções rápidas para os cenários, já que muitas vezes são demandados assim. Acontece que ao dar soluções de arquitetura ou de código acabam gerando impactos na experiência que pode não fazer qualquer sentido para o usuário. Veja, estou dando como exemplo negativo o desenvolvedor, mas mesmo alguém focado no discovery pode falhar nesse aspecto. Não se apaixone pela solução, mas sim pelo problema.

O produto de verdade nasce da obsessão por entender profundamente a dor do usuário, suas frustrações, desejos e contexto. É preciso esquecer a solução por um tempo e mergulhar na raiz do problema. É aí que entra o framing do problema. Antes de sair criando, é preciso investigar: qual a dor real que queremos resolver? Qual é a necessidade não atendida? O que o negócio ganha se resolvermos isso? Formule hipóteses. Colete dados com ferramentas como Amplitude, Google Analytcs, Hotjar. Analise os padrões, os comportamentos, os silêncios. Crie dashboards, compartilhe aprendizados e valide tudo com o time. Essas são algumas ferramentas que costumam ser utilizadas no discovery:

• Mapeamento da Jornada do usuário
• Design Thinking
• Roadmap
• Definição da Persona
• Mapa de empatia
• Visão
• Experimentos
• Testes A/B
• Canvas
• etc.

Note que todo Discovery precisa lidar com quatro riscos principais: o risco de valor: será que o cliente realmente quer ou enxerga valor nisso, o risco de usabilidade: ele vai conseguir ou querer usar, o risco de negócio: isso traz resultado pra empresa e o risco de viabilidade: é realmente possível fazer isso com as restrições (exemplo: tempo e dinheiro).

Valide as hipóteses

Validar hipóteses é o coração do Discovery. Não adianta acreditar que algo é uma boa ideia, é preciso testar. Tudo começa com uma suposição: aquilo que você acredita ser verdade sobre o problema ou o comportamento do usuário. Em seguida, você define um experimento para colocar essa crença à prova. A hipótese é a combinação dos dois: uma suposição estruturada, com um experimento claro para obter evidências.

Escreva suas hipóteses com método. Ferramentas como os Test Cards do Strategyzer ajudam a dar clareza ao que está sendo testado e ao que se espera aprender. Depois de escritas, priorize as hipóteses com base em impacto potencial e grau de incerteza. Vá do mais arriscado ao mais importante. Execute os testes, colete dados reais e registre os aprendizados com Learning Cards.

E para testar sem gastar uma fortuna, use protótipos. Um wireframe simples já pode validar fluxo, que pode ser rabiscos simples sem detalhes. Num passo seguinte, um mockup já pode dar uma ideia da cara do produto, com layout, cores e identidade visual, mas ainda sem interações. Quando a validação estiver mais madura, o protótipo é o que mais se aproxima da experiência real: ele permite simular a navegação, sentir o fluxo, testar jornadas. Usar o tipo certo de prototipação vai economizar dinheiro e alocar melhor seus preciosos recursos.

Conclusão de Erre Rápido!

Descobrir o que não fazer é tão valioso quanto acertar o caminho certo: erre Rápido! Ao adotar uma cultura de Product Discovery, você não evita o grande erro, você aprende com ele, rápido o suficiente para que ele vire alavanca, não prejuízo. No fim, o que diferencia produtos que crescem dos que fracassam é justamente isso: a coragem de errar rápido e a sabedoria de aprender antes de investir pesado.