Um erro que custou caro

Ano passado, eu decidi lançar o Tintim 2.0. Seria uma nova versão do produto, completamente inovadora. Resultado? Não saiu nada.

Na edição de hoje da Newsletter do Moa, eu vou contar um pouco sobre esse erro e aproveitar para dizer como eu acho que podemos entregar produto de forma ágil.

Foco total em produto

Eu era o meu ICP, no começo. Foi assim que comecei o Tintim. A ideia inicial era transformar todo aquele monte de script que a gente tinha na DevPro em um software que fosse simples e intuitivo. Apesar de bagunçado, o sistema de tracking que eu tinha desenvolvido era bem sofisticado.

Imagina só: você tem menos de 30 dias para investir cerca de R$ 300 mil em anúncios. Depois desses 30 dias, você faz um evento gratuito e, ao final do evento, você faz a venda. Estamos falando de quase 45 dias entre o investimento e o retorno. Nesse meio tempo, como vou saber se estou investindo corretamente os R$ 300 mil? Essa era a pergunta que esse sistema respondia.

O sistema funcionava muito bem, afinal, a gente nunca teve prejuízo, mesmo investindo cifras altas (esse valor de R$ 300 mil é real). Acontece que, quando eu fui para mercado validar essa solução em outros clientes, o negócio não virou. Então, tive que fazer um ajuste de rota.

Quando, num mastermind de empresários, um amigo me falou das dores de quem vende pela internet usando WhatsApp como canal de comunicação. Quando decidi validar se esse poderia ser o caminho do Tintim, eu deixei de ser o meu ICP. Apesar de o ICP continuar sendo o gestor de tráfego, antes, eu estava desenvolvendo um software para quem vende de infoproduto. Agora, eu estava construindo um software para gestores que atendem negócios locais. Os fundamentos são os mesmos, mas, existem diferentes peculiaridades em cada perfil.

No começo do Tintim, meu foco foi encontrar product market fit. A gente construía, tentava vender, entendia os problemas, voltava, ajustava e tentava vender de novo. Repetimos esse ciclo inúmeras vezes, até acertar a mão. Foi esse foco e essa determinação que nos fizeram acertar a mão rápido.

Erramos na estratégia

Depois de acertar a mão, eu tirei um pouco o olho do produto e passei a focar em receita. Somos uma empresa que quase não teve investimento externo, portanto, nossa grande fonte de financiamento sempre foi o próprio cliente.

Não me arrependo, em hipótese alguma. A Brahma não é a melhor cerveja do mercado, mas é a mais vendida. O BigMac não é, nem de longe, melhor que o hamburguer artesanal da esquina da sua casa. Ainda assim, ele vende muito mais. Eu acredito piamente que ganha o jogo quem vende melhor. Foi nisso que foquei.

Esse foco deu resultado, afinal, em cerca de dois anos de existência, crescemos para R$ 400k MRR. Mas, esse foco cobrou um preço…

Eu sou “solofounder”. Minhas lideranças (que hoje são sócias) chegaram um pouquinho depois, e focaram muito mais em executar do que planejar junto comigo. A estratégia acabou ficando exclusivamente sob minha responsabilidade. Acontece que é MUITO difícil tocar estratégia de receita e de produto ao mesmo tempo. Tanto que acabei focando muito mais em receita.

Mas, a partir do segundo semestre de 2024, decidi que isso iria mudar: “vou voltar a olhar para o produto!”. O Tintim estava bem e estável, gerando valor para seus clientes. Ainda assim, ele pedia por algumas funcionalidades-chave que, devido à falta de tempo, nunca eram implementadas.

Esse projeto foi chamado de “Tintim 2.0”, um conjunto de funcionalidades que iria melhorar a vida do usuário e, ao mesmo tempo, resolver vários de nossos problemas internos. E de onde saíram as ideias dessas funcionalidades? Da minha cabeça.

Erro crasso.

Eu decidi partir da premissa de que eu era o meu ICP. Fazia algum sentido, afinal, quem toca a área de marketing e performance aqui no Tintim sou eu. Só tem um problema: eu não era/não sou o meu ICP. Pra você ter uma ideia, na época, a gente ainda nem fazia campanha para *WhatsApp, *que é o carro chefe do software.

O Tintim resolve o problema de gestores de tráfego que estão em outro nível de jogo. Eles fazem gestão de orçamentos bem menores que o nosso, que demandam um nível de complexidade de operação bem menor que o nosso. Por mais óbvio que isso seja, a minha arrogância e a minha ansiedade não me permitiram enxergar isso na época.

Essa decisão de considerar que eu era o ICP fez a gente pular várias etapas de concepção e validação. Eram entregas gigantes, mal especificadas e mal planejadas. Resultado: em seis meses de trabalho, não saiu nada na mão do usuário. Ok, ok. Muita coisa que foi feita dá pra ser aproveitada, e será. Mas, ainda assim, perdemos um tempo valioso que poderia ter sido direcionado para resolver os problemas do nosso ICP, de fato.

Como entregar produto de forma ágil

Há algumas semanas, eu encontrei alguns antigos amigos que a comunidade Python me deu. A linda filha do meu amigo Augusto Goulart nasceu, e resolvemos fazer uma visita para conhecer a neném e matar a saudade. Foi um final de semana muito gostoso de muito papo, muita cerveja, muito queijo, muito torresmo e muito pão de queijo, bem à moda mineira.

Conversa vai, conversa vem, eu e Ronaldo (meu CTO) engatamos num debate com nosso amigo Henrique Bastos (já citado aqui algumas vezes) sobre como entregar produto de forma eficaz. A gente contou um pouco do nosso sistema de entregas aqui no Tintim, e acabamos engatando numa discussão.

De um lado, eu defendendo que eu tinha conhecimento suficiente para pular algumas etapas. Do outro, HB dizendo que eu não tinha esse conhecimento e, por isso, estava fazendo merda. Eu defendi meu ponto, ele defendeu o dele, até que, depois de ele dar um exemplo muito claro e didático de um ponto em que estávamos errando, eu percebi que eu estava errado.

Na hora, fiquei puto: “como eu não pensei nisso?”. O exemplo dele era óbvio e fazia todo sentido. Pior de tudo: o exemplo dele me remeteu aos primórdios do Tintim. Fiquei puto, não por estar errado, mas, por ter “perdido a essência”.

De novo: não me culpo. Eu sou um só e não consigo pensar em tudo ao mesmo tempo. Eu “perdi a essência” em produto justamente porque meu foco estava em outro lugar. Mas, fato é que estávamos errando. Independentemente de culpa, esses erros precisavam ser corrigidos.

Por isso, eu decidi resgatar o espírito de produto do começo do Tintim e escrever alguns princípios básicos sobre entrega ágil de produto que sei que dão certo.

Mantenha dois roadmaps

Eu gosto de manter dois roadmaps de produto. Um roadmap para grandes entregas, geralmente novas funcionalidades, e outro roadmap para o resto, que são pequenas melhorias, conserto de bugs, quitação de débito técnico, etc.

Para entregar o roadmap de melhorias não tem muito segredo. Basta que o time de engenharia sempre tenha um estoque de demandas para ser consumido a cada nova sprint.

Esse estoque nasce de solicitações dos próprios usuários, que chegam através de entrevistas, do suporte, ou de ferramentas de feedback (como o dorable.ai). Ele também pode nascer de demandas do próprio time, que são os casos de débitos técnicos, por exemplo. Importante que esse estoque tenha qualidade. Essas demandas devem ter boas especificações funcionais, bons protótipos e boas especificações técnicas.

Com esse estoque preenchido, basta o time de engenharia revisitar essa fila a cada novo começo de sprint. Como eu disse, sem segredo.

O bicho pega, mesmo, quando estamos falando de novas funcionalidades…

Grandes entregas devem ser experimentos

Esse tipo de demanda nasce da área de negócios, e são a resposta para uma dessas três dúvidas:

1. Como aumentar meu tamanho de mercado?

2. Como aumentar meu ticket médio por cliente?

3. Como aumentar a retenção do meu produto?

A forma de responder a essas dúvidas é uma só: resolvendo problemas do cliente.

Não vou entrar no mérito de como descobrir o que devemos desenvolver. Meu ponto aqui é te conscientizar de que fazer grandes entregas custa caro. Muito caro!

Duvida? Então vamos fazer uma conta de padeiro simples para eu provar meu ponto…

Imagine que, somando todos os salários do seu time de desenvolvimento, você gaste R$ 50 mil por mês. Imagine que, a cada mês, seu time entregue duas sprints (cada sprint custa R$ 25 mil). Imagine que, para entregar uma nova funcionalidade completa, seu time gaste 4 sprints. O custo de desenvolvimento dessa funcionalidade é de R$ 100 mil.

Não sei pra você, mas, pra mim, R$ 100 mil é muito dinheiro para ser arriscado em uma hipótese. Sim, uma hipótese. Enquanto a funcionalidade não está na mão do seu usuário sendo usada e comprovadamente gerando valor, ela não passa de uma hipótese.

Colocar R$ 100 mil em uma hipótese que não foi validada é quase a mesma coisa que apostar R$ 100 mil no Bet365. Antes de desenvolver uma grande funcionalidade, você precisa validar se essa funcionalidade vai resolver o problema do seu usuário.

Como realizar um experimento para validar uma hipótese

É bem simples, na real. Basta aquietar seu ego e aceitar que você NÃO SABE o que o seu usuário precisa. A partir daí, você vai conversar com o usuário, com o suporte, com o cliente que cancelou, com o cliente que acabou de entrar. Converse, entenda o problema, e elabore algumas hipóteses.

Depois que você fez tudo isso, aí sim você planeja a funcionalidade. Planeja ela completinha, como você imagina que deveria ser. Coloca filtro, gráfico, ordenação, paginação, integração, etc, etc. Mas, só pensa, não faz nada.

A funcionalidade ficou linda? Perfeita? Agora pensa: “como eu consigo resolver esse mesmo problema, mas, escrevendo o mínimo de código possível?”.

Como eu resolvo esse problema com apenas uma tela? Sem alterar banco de dados? Sem mexer em outras partes do sistema? Sem filtro, sem paginação, sem ordenação, sem integração? A ideia aqui é pensar na forma mais rápida e tosca de resolver o problema. A forma mais barata de validar se você está no caminho certo.

Voltando ao nosso exemplo de antes, se você conseguir fazer uma primeira entrega em apenas uma sprint, você está investindo apenas R$ 25 mil. Apenas ¼ do valor inicial, e com muito menos risco, porque você, deliberadamente, pensou em mitigar erros antes de meter a mão na massa.

Coloque essa versão zero na mão de alguns usuários e valide com eles se essa versão resolve o problema. Naturalmente, eles vão pedir os penduricalhos que você removeu. Normal. Explique para eles que seu objetivo aqui é validar a funcionalidade, e depois lapidá-la.

Validou? Então, se pergunte: dá pra soltar essa funcionalidade assim, do jeito que tá, para o resto da base? Esqueça o purismo, o perfeccionismo. Seja pragmático e empático. Se você liberar do jeito que tá, você vai ajudar seu usuário, ainda que de forma incompleta? Se sim, libere.

Colocando a funcionalidade rapidamente na mão do usuário, você terá feedback. A partir daí, seu desenvolvimento não é mais orientado a hipóteses, mas, sim, a feedbacks reais de pessoas que estão tendo seus problemas resolvidos por você.

Foi assim que o Tintim decolou no seu começo. E foi esquecendo desses princípios básicos que a gente acabou se perdendo no meio do caminho.

É assim que o Tintim vai evoluir como produto em 2025.

---

✉️ Esta foi mais uma edição da Newsletter do Moa!

💪🏻 O meu objetivo com essa newsletter é ajudar profissionais de tecnologia que desejam desenvolver uma visão mais estratégica.

Além disso, pretendo também compartilhar outras coisas, como um pouco dos bastidores da construção de um negócio SaaS, as minhas opiniões e meus aprendizados. A ideia geral é ser uma documentação pública e estruturada dos meus pensamentos e aprendizados ao longo dos anos.

Portanto, se você se interessa por soft-skill, desenvolvimento pessoal, empreendedorismo e opiniões relativamente polêmicas, sugiro que você se inscreva para receber as próximas edições. ⬇️

Toque aqui para se inscrever

Fonte: https://moacirmoda.substack.com/p/nao-chame-atencao-compre-atencao