Na semana passada eu comecei a falar sobre a importância da validação na hora de construir um produto.

Na edição de hoje da Newsletter do Moa, eu resolvi explicar a forma pouco ortodoxa que venho usando para validar ideias (minhas e de meus clientes) nos últimos anos.

Quer saber como garantir que sua ideia é boa o suficiente? Então vem comigo!

Uma solução em busca de um problema

Quando eu tinha 19 anos de idade, comecei a trabalhar como estagiário em uma empresa de tecnologia. Eu já sabia programar desde os meus 11 anos, mas nunca havia tido uma experiência profissional. Tudo o que eu codava, até então, era "de brinquedo".

Programar é legal, mas programar profissionalmente é indescritível. Como o Deivison, do Vivendo de SaaS, disse em um de seus posts, um dos prazeres de desenvolver produto é ver ele sendo útil para as pessoas. Quando eu senti esse prazer pela primeira vez, a minha vontade de programar (que já era grande) se multiplicou por 10. Porém, com um temperinho a mais…

Antes, eu ficava codando experimentos ou seguindo tutoriais. Eu programava por programar, sem muita utilidade. Chegou um momento em que eu quis ir além de programar, eu queria construir soluções. Foi nessa época que criei o meu primeiro produto: Publicidade no Twitter.

A ideia do produto era simples: um _bot _que fazia ~~spam~~ divulgação para usuários que postassem determinada frase ou hashtag. Veja o texto que usávamos para divulgar o produto:

Email com divulgação do Publicidade no Twitter

O ano era 2011. A ideia era completamente inovadora. Sistemas de automação como esses começaram a nascer cerca de 2 anos depois. Mas, como esperado, não conseguimos vender nada.

Os motivos do fracasso foram vários. Dentre todos, o mais óbvio: eu não sabia vender. Mas, além disso, teve um outro motivo muito relevante: esse produto não nasceu a partir de um problema, mas, sim, a partir de uma solução.

A ideia do Publicidade no Twitter nasceu quando eu conheci a API do Twitter e me deparei com o que poderia ser feito. Quando eu enxerguei a possibilidade, eu escrevi uma pequena prova de conceito. Deu certo! Consegui validar a possibilidade de encontrar e responder um _tweet _de forma 100% automatizada. Somente depois de ter a solução pronta, eu me preocupei em encontrar um problema.

Começar pela solução é um erro clássico do programador que quer construir um produto. Normal, afinal, seu ofício é construir soluções. O dia a dia do programador consiste, literalmente, em transformar ideias em código. O programador é treinado para enxergar soluções, não problemas.

Não me entenda mal. É possível ter sucesso por esse caminho. Só é mais difícil. Muito mais difícil. Para seguir pelo caminho mais fácil, basta inverter a ordem:** comece pelo problema, e não pela solução.**

Olhe para o seu dia a dia, ou para o dia a dia das pessoas ao seu redor, e pense: o que está ruim e poderia ser melhor? O que está ruim e eu conseguiria melhorar através da programação? Simples assim. Não tem segredo. Basta procurar por ineficiências na sua rotina ou na rotina de pessoas próximas.

Com certeza você vai encontrar alguma coisa. Essa parte é fácil. Agora, será que o problema que você encontrou é um problema que vale a pena ser resolvido?

Como validar um problema?

Sim, eu sei. O que você quer é programar. Essa é a zona de conforto do programador. Café, fone de ouvido, tela preta e 10h seguidas de código. Escreve, testa, escreve, testa, escreve, testa… Faz o deploy, testa de novo. Escreve de novo, testa de novo, faz o _deploy _de novo…

O programador ama essa rotina. Mas saiba que programar é apenas uma das partes de construir um produto. O _software _não é um fim em si mesmo. O _software _é um meio para resolver um problema. O personagem central da história não é o software, mas, sim, a pessoa que usa o software.

Para construir produtos úteis, você precisa conversar com pessoas. Não dá para fugir. Se você não estiver disposto a interagir com pessoas, você estará fadado a ser simplesmente um _escrevedor _de código (e concorrer com o ChatGPT).

Depois de encontrar um problema, é preciso saber se vale a pena resolver esse problema. O meu objetivo, neste texto, não é entrar em critérios de negócio. Não vou falar sobre tamanho de mercado, sensibilidade a preço, ideal customer profile, etc. Minha ideia, hoje, é falar exclusivamente sobre construção de produto. Portanto, o objetivo aqui é, basicamente, ensinar você a descobrir se esse problema incomoda o suficiente para que você invista tempo construindo uma solução.

Como descobrir isso? Conversando com o seu público-alvo. Pergunte para os seus potenciais clientes se esse problema vale a pena ser resolvido. Entreviste essas pessoas e colete a maior quantidade possível de informação sobre o problema.

Eu sempre executei essa tarefa no freestyle, ou seja, sem nenhum tipo de _framework _ou estrutura. Eu simplesmente marcava um papo com a pessoa e perguntava tudo o que eu achava que deveria perguntar. É claro que existe uma lógica por trás dessas perguntas. Acontece que, depois de anos fazendo isso, o processo fica tão natural que você acaba nem percebendo o padrão.

Caso você não tenha essa facilidade, sugiro que adapte o framework mais famoso do mundo usado para vendas consultivas: o SPIN Selling. SPIN é a sigla das palavras Situação, Problema, Implicação e Necessidade. No processo de vendas, o vendedor faz uma série de perguntas que se encaixam nessas quatro categorias.

O SPIN, no fim do dia, é um _framework _que processualiza um ato de descoberta. O objetivo é entender as necessidades do cliente e, a partir disso, oferecer a melhor solução. Dada sua natureza, é possível adaptar esse _framework _para descobrir, justamente, as necessidades, os problemas e as implicações de quem enfrenta aquilo que estamos nos propondo a resolver.

Abaixo, explico um pouco mais sobre esse framework.

Perguntas de Situação

As perguntas de situação costumam vir no início da conversa. O objetivo é mapear a realidade atual da pessoa. Alguns exemplos de perguntas:

Há quanto tempo você tem esse problema?
Como você lida com esse problema atualmente?
Quais ferramentas você usa para lidar com esse problema?
Qual é a urgência de resolver esse problema?
Com que frequência você enfrenta esse problema?

Perguntas de Problema

Aqui o objetivo é explorar as dificuldades e insatisfações que a pessoa enfrenta por causa do problema. Alguns exemplos:

Você está satisfeito com o jeito com que você lida com esse problema hoje?
Quão difícil é lidar com esse problema?
Qual é o impacto desse problema na qualidade do seu trabalho?
Quanto você gasta de tempo/dinheiro para resolver esse problema?
Seus clientes reclamam por conta desse problema?

Perguntas de Implicação

Em um processo padrão de vendas, o objetivo das perguntas de implicação é entender e aumentar o senso de urgência do prospect. Quanto mais urgente for a resolução do problema, mais disposto ele estará a comprar.

Neste caso, descobrir o nível de urgência da pessoa é muito útil para saber o quanto aquele problema dói de verdade, e qual é a disposição ($$) da pessoa para resolvê-lo.

Alguns exemplos de perguntas:

Como esse problema afeta a sua receita?
Como esse problema afeta a satisfação dos seus clientes?
Como esse problema afeta a satisfação dos seus funcionários?
Esse problema te preocupa? Tira o seu sono?

Perguntas de Necessidade

Aqui o objetivo é entender como seria a vida da pessoa se o problema fosse resolvido. Quanto ela deseja que esse problema seja resolvido?

Num processo padrão, esta é a parte que mais se relaciona com o sucesso de vendas. Neste caso, é preciso entender o quanto a pessoa fica empolgada quando imagina o problema resolvido.

Mais alguns exemplos:

Se você resolvesse esse problema, como isso te ajudaria?
Quão valioso seria resolver esse problema?
Resolver esse problema ajudaria sua empresa? Como?

Outras dicas importantes

Parta do princípio de que você não sabe quase nada sobre o problema. Essa é a sua chance de ser surpreendido.
Busque sempre fazer perguntas abertas. Deixe a pessoa abrir o coração.
Evite a qualquer custo interromper a pessoa.
Fique quieto e deixe que o silêncio incomode a pessoa a ponto de ela falar mais e mais.

Validar o problema é uma das partes fundamentais do processo de criação de um produto. Não há nada mais frustrante do que construir um produto que ninguém quer usar.

Essa frustração é, inclusive, perigosa. Existe uma grande chance da gente interpretar essa frustração como uma rejeição pessoal, ou uma rejeição ao nosso trabalho. A chance de essa rejeição abalar nossa moral é grande. A notícia boa? O ser humano é muito egoísta e não está nem aí para os nossos sentimentos. Ele simplesmente rejeita seu produto, pois aquele problema não vale a pena ser resolvido.

Entretanto, é possível evitar essa frustração e, principalmente, evitar perder tempo construindo um produto que ninguém quer usar. Por isso, valide seu problema!

—

A ideia era, neste texto, ensinar você a validar um problema e também a validar uma solução. Acontece que eu falo demais, e o texto acabou ficando grande.

Por isso, não perca a edição #49 da Newsletter do Moa. Você vai aprender a validar uma solução e garantir que o cliente tenha interesse em comprar de você!

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