Na semana passada eu ensinei o passo a passo que uso há anos para validar um problema.

Na edição de hoje da Newsletter do Moa, dou continuidade a essa série sobre validação e falo sobre técnicas para validar a solução que você idealizou.

Quer saber como evitar desperdício de tempo e dinheiro e construir algo que realmente valha a pena ser construído? Então bora!

Construir software é caro!

Comecei a trabalhar como freelancer full-time lá em 2014. Comecei fazendo sites em Wordpress. Os clientes eram os mais variados possíveis. Fiz site para uma empresa de saúde, fiz site para uma grande metalúrgica, e fiz site até para uma famosa dupla sertaneja.

Depois de alguns anos, transformei meu freelance em uma empresa prestadora de serviços: a Codevance. Meu objetivo era deixar de ser simplesmente um freela e me posicionar como uma empresa prestadora de serviços.

Esse movimento nasceu a partir de uma experiência que tive dentro de uma startup alguns meses antes. Essa startup tinha uma empresa prestadora de serviço que faturava bastante, fazendo, basicamente, o que eu já fazia há anos (cobrando muito menos). Já contei essa história com mais detalhes em outro momento.

Devido a esse contexto, a Codevance acabou se especializando em atender startups. Nós éramos parte do time tecnológico de startups que estavam começando e, quase sempre, não tinham um sócio técnico. Passei os últimos 7 anos da minha vida profissional construindo tecnologia para empresas que ainda não tinham uma ideia 100% validada.

Vários perfis de clientes passaram pela Codevance. Havia aqueles que claramente sabiam o que estavam fazendo, e também havia os aventureiros. Alguns clientes fizeram o dever de casa e só construíram depois de validar suas hipóteses. Outros, não.

Dois casos foram bem marcantes. Não vou citar nomes nem dar muito contexto sobre eles, pois seria antiético da minha parte mencioná-los sem a devida permissão. Mas, vou citar alguns fatos que ilustram meu ponto de discussão neste texto.

Primeiro caso. O cliente tinha um conceito muito claro e específico na sua cabeça. Havia uma preocupação extrema com beleza e qualidade. Realmente, o site e o sistema ficaram muito bonitos.

Talvez esse tenha sido o problema: a paixão pela solução. Havia uma empolgação tão grande com o produto, que não havia espaço para questionamento. Em nenhum momento a parte mais interessada foi consultada. Primeiro, veio o produto, depois, o cliente. Resultado? Quase R$ 80k investidos em tecnologia, e um total de zero vendas.

Segundo caso. O cliente tinha expertise no mercado de atuação. Décadas de track record. Essa autoridade o fez seguir pelo mesmo caminho: construiu um produto sem validar a solução. O resultado? Mais de R$ 500k investidos antes de algum resultado minimamente relevante que justificasse o investimento.

Já disse isso antes e repito, novamente: construir software é muito caro. Dificilmente, o desenvolvimento de um MVP sai por menos de R$ 50k. Para a grande maioria das pessoas, isso é MUITO dinheiro para investir no escuro. Por isso, é preciso validar o problema e também validar a solução do problema.

E como fazer isso?

Como validar uma solução

Se você trabalha com tecnologia, com certeza você já ouviu falar do termo MVP. MVP é a sigla para Minimum Viable Product. Em português, Mínimo Produto Viável. Esse é um conceito que veio do Lean Startup.

Um MVP é a versão mais básica de um produto. É o mínimo necessário que um produto precisa ter para resolver um problema. O objetivo de criar um MVP é testar suas hipóteses sobre o mercado, sobre o problema e sobre o produto, da forma mais rápida e barata possível.

O objetivo de um MVP não é vender. Não é faturar. MVP não é produto. Seu objetivo não é resolver o problema em si. O objetivo de um MVP é validar se a solução proposta consegue resolver o problema. Essa diferença é sutil, mas fundamental.

O erro número um do empreendedor de primeira viagem (principalmente se for programador) é confundir MVP com código. Um MVP pode ser, sim, um projeto de software. Mas, também pode ser uma landing page, ou um grupo de WhatsApp. MVP, no fim do dia, é um conceito. A implementação desse conceito fica a cargo da criatividade do empreendedor.

Existem algumas formas comuns de implementar um MVP. A mais conhecida de todas, e a pior delas, é implementar um software com funcionalidades limitadas. Acredito ser a pior, justamente por ser a mais cara e também a mais demorada. Salvo raras exceções, existem opções mais rápidas e baratas de validar sua solução.

Outra forma de validar uma solução é simplesmente copiar um concorrente. A RD, gigante do marketing, é um copy cat da Hubspot. A 99 é um copy cat da Uber. A Mobly é um copy cat da IKEA. Em todos esses casos, os fundadores das empresas brasileiras usaram o sucesso das empresas gringas como validação para a criação de suas empresas.

Eu até gosto desse modelo de validação de ideias, mas com grandes ressalvas. De fato, o sucesso do concorrente pode ser um indicativo de solução validada. Mas, é bastante perigoso simplesmente copiar uma ideia. Se você não tiver um diferencial e, principalmente, se não souber o porquê das coisas, vai ficar pelo caminho. Todos os cases que citei acima são inspirações adaptadas e contextualizadas. Olhando de perto, são operações com muito mais diferenças do que semelhanças.

Se você tiver uma audiência no mercado em que deseja atuar, pode simplesmente perguntar para essas pessoas qual solução elas gostariam de ter para seus problemas. Esse caminho é bom, mas, também, contém ressalvas.

"Se eu perguntasse às pessoas o que elas querem, elas me diriam que querem cavalos mais rápidos". Essa frase é atribuída a Henry Ford. A sua maior fonte de conhecimento, sem dúvidas, sempre será o seu público-alvo. Mas, não basta simplesmente perguntar. É preciso estratégia para interpretar as respostas. A sua audiência com certeza sabe os problemas que tem. Quanto às soluções para esses problemas, eu tenho minhas dúvidas…

Qual é o melhor jeito de validar sua solução?

Fake Until You Make It

Lá em 1770, um húngaro chamado Wolfgang von Kempelen apresentou ao mundo o Turco Mecânico. Tratava-se de uma das invenções mais mágicas de toda a história: uma máquina capaz de jogar xadrez sozinha. A máquina operou por mais de 80 anos e chegou a enfrentar grandes personalidades da história, como Napoleão Bonaparte e Benjamin Franklin.

Hoje, em 2024, o mundo todo ainda segue impressionado com a capacidade do ChatGPT de produzir respostas "inteligentes". Imagine, você, há 250 anos atrás, se deparando com uma máquina capaz de jogar xadrez sozinha. Surreal, né?

Acontece que o Turco Mecânico não operava sozinho. Por baixo dos panos, existia um operador humano tomando decisões. Durante quase um século, as pessoas foram convencidas de que a máquina operava sozinha, quando, na verdade, um ser humano atuava através da máquina.

Voltando ao tema principal… O melhor jeito de validar uma solução é construir seu próprio Turco Mecânico.

Um software, em sua essência, é a automação de um processo. Antes do iFood, as pessoas ligavam para a pizzaria para fazer um pedido, e uma pessoa do outro lado anotava e processava esse pedido. Antes do Excel, uma pessoa somava valores em uma calculadora e anotava em um papel. Antes do Tintim, o gestor de tráfego colocava uma frase de WhatsApp para cada anúncio, e depois planilhava, na unha, cada um dos leads que enviaram mensagem no WhatsApp.

O seu software deve agir como um Turco Mecânico. Um dos caminhos é ter um ser humano executando as tarefas que deveriam ser automatizadas. Agora, o melhor caminho para todos é simplesmente fingir que os processos acontecem de forma mágica.

"Como assim, Moacir?"

O MVP do Dropbox

O time do Dropbox criou um vídeo explicando o produto. Só tem um pequeno detalhe: o produto não existia. O vídeo não demonstrou o produto funcionando, mas sim como ele funcionaria. Apenas "contando" o funcionamento da solução, eles conseguiram validar a solução e levantar o investimento necessário para construir o produto.

Fazer um vídeo explicativo é uma das formas de validar uma solução. Porém, além dessa, existem diversas outras formas.

Verbal commitments/pré-venda

Mais simples do que criar um vídeo demonstrativo é você, simplesmente, bater na porta do seu potencial cliente, contar como será a solução que pretende desenvolver, e fechar uma venda. Simples assim.

Se você conseguir fazer uma venda, significa que a sua solução foi validada. Para facilitar o processo, você pode oferecer um super desconto para compensar a confiança que o cliente está depositando em você.

Essa é, de longe, uma das melhores formas de validar uma solução. É rápido e mexe no indicador mais sincero de aprovação de uma pessoa: o seu bolso.

Landing pages

O processo aqui é similar ao da pré-venda. A única diferença é que você fará uma apresentação através de um site em vez de conversar diretamente com o cliente. Crie uma landing page e coloque um botão de venda (ou um formulário de cadastro para uma waiting list).

Essa solução é muito boa, mas eu ainda prefiro fazer uma venda tete-a-tete. Isso porque, através de uma landing page, você não tem a oportunidade de conversar com a pessoa.

Agora, o ponto positivo aqui é que você consegue simplesmente jogar tráfego para essa página e validar sua solução com mais pessoas.

Formulário de Pesquisa

Uma forma de mitigar o problema de não poder conversar com o seu usuário através de uma *landing page *é acoplar um formulário de pesquisa. O objetivo aqui é entender mais sobre o contexto do usuário que está interessado em sua solução.

Rode uma pesquisa com seu público-alvo fazendo perguntas abertas. Deixe o usuário abrir seu coração. Você pode disfarçar essa pesquisa como um formulário de aplicação, por exemplo.

Não se esqueça de fazer a venda no final do processo.

Mockups Digitais/Demo Interativa

Essa é a evolução do vídeo de demonstração. Crie uma série de telas de como seria seu software. Se quiser, deixe esses mockups interativos e clicáveis.

É mais trabalhoso. Também acredito ser desnecessário, na grande maioria dos casos. Ainda sim, é uma ótima alternativa em comparação a construir um software. Bem mais rápida, bem mais barata, e possui praticamente o mesmo efeito.

MVP Concierge

Esse é o modelo mais próximo da implementação de algo análogo a um Turco Mecânico. Nesse modelo, seu sistema possui uma interface tal qual um produto de verdade. O detalhe está por baixo dos panos. Em vez de software operando, temos um humano.

Esse modelo é trabalhoso e talvez demorado, mas, com certeza, muito mais barato. Sua grande vantagem é chegar o mais próximo possível da execução da solução proposta. Para que você tenha um produto, de fato, basta automatizar o processo.

Esse é um dos modelos que mais gosto.

Como eu fiz para validar a solução do Tintim?

Eu já contei essa história com mais detalhes. Mas, resumidamente, o caminho que eu fiz foi fazer um pitch do que seria o produto para a maior quantidade de pessoas possível. Com isso, eu validei a demanda de forma quantitativa.

Depois, consegui um verbal commitment de dois usuários, e então construí uma pequena fração do software. Nessa etapa, eu abusei das peças prontas do framework Django. Fiz tudo muito rápido. Tudo o que era necessário, mas não havia sido implementado, eu fazia na mão (para você ter uma ideia, a gente só integrou o pagamento com o software depois de 1 ano de operação).

Todo o processo levou menos de 3 meses.

Eu faria algo diferente? Sim. Por mais que eu tenha conseguido verbal commitments, não fiz nenhuma venda antes de ter o MVP. Eu teria vendido antes de construir. Isso teria acelerado o processo e trazido mais segurança.

De resto, faria igual. Não posso deixar de dizer que contexto importa. Eu sou um programador experiente, e eu era o meu próprio público-alvo. Isso fez com que eu tivesse mais segurança para construir código sem algumas validações. Ainda assim, eu validei bastante antes de colocar a mão na massa.

Recomendo que você analise seu contexto e escolha o melhor caminho, com base no que te ensinei neste texto.

Só não vai inventar de escrever código sem fazer validação de problema e de solução.

Abraços

✉️ 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