Octocash. Esse era o nome do produto que eu e dois colegas lançamos há quatro anos. Começar a construir o próprio produto tendo apenas dois anos de profissão é uma experiência deslumbrante. Todos os integrantes transbordam otimismo. É tanto otimismo que ele sozinho é mais do que suficiente para desenvolver o produto. É tanta euforia que entender profundamente um problema passa a ser opcional. Após desenharmos um logo e as primeiras telas, programamos loucamente até colocar o produto no ar. Visitante após visitante, começamos a coletar então a amarga métrica de zero conversões. Ops! Ficou evidente que era preciso mais do que só abrir a porta da loja pro negócio prosperar.

Mariscos

Depois do banho de água fria, saímos à caça das razões que ousaram secar nosso oceano de otimismo. Começaram as apostas. A maioria delas carregava consigo a ausência de uma feature. Não temos conversões porque o produto não faz isso. Não temos conversões porque o produto não faz aquilo. Em pouquíssimo tempo, listamos uma enorme quantidade de trabalho pela frente. E quanto mais discutíamos, mais features gostaríamos que o produto tivesse. Acreditávamos que a cada nova feature adicionada ao produto, estaríamos aumentando as chances de alguém se convencer a pagar por ele.

Diante do alto volume de trabalho a ser desenvolvido e sem acreditar que estaríamos oferecendo alguma coisa que os concorrentes já não oferecessem, decidi sair do projeto. A minha conclusão foi que, por maior que fosse nossa boa vontade, a total falta de entendimento do problema nos tornava incapaz de oferecer algo que fizesse brilhar os olhos dos nossos clientes. Queríamos nos convencer do potencial do produto reunindo a maior quantidade possível de mariscos, sem perceber que não tínhamos pérola alguma a oferecer.

Pérolas

Dois anos mais tarde, inspirado pela homepage de um produto que eu gostava muito (WeDeploy), comecei a construir um novo produto. Dessa vez, infinitamente mais modesto. Além disso, eu estava protegido por completo da decepção de ninguém pagar por ele. O produto era open-source, se chamava Glorious Demo e permitia a um desenvolvedor usar JavaScript para construir uma animação que simulava a escrita e a execução de um trecho de código. Com pouquíssimas linhas de JavaScript, era possível criar uma animação capaz de abrir um editor, escrever nele, abrir um terminal, executar comandos e receber respostas. Tornava-se possível com JavaScript fazer algo que até então demandava o uso de GIFs.

Recebo o primeiro feedback positivo justamente de quem liderava o WeDeploy à época, Zeno Rocha. Seu tweet fez o projeto alcançar quase quarenta estrelas no Github. Obter pela primeira vez na vida um pequeno reconhecimento de pessoas que eu sequer conhecia já ecoava dentro de mim como o maior de todos os sucessos. Dias depois, numa quinta-feira à noite, decido publicar o produto no Product Hunt. Na manhã de sexta-feira, acordo atônito ao ver o Glorious Demo como produto mais votado do dia. O projeto ultrapassa 300 estrelas e entra na lista de tendências do Github. Uma das publicações mais populares do mundo sobre CSS divulga o projeto. Um programador em Seattle cria um site chamado Road To Glory que permite o uso do Glorious Demo através de uma interface gráfica. O Glorious Demo se transforma em um plugin para Hexo pelas mãos de um programador Sul Coreano. Blog posts são escritos em árabe e japonês.

Hoje, dezoito meses após o lançamento, aquele pequeno produto feito com 80 commits alcança uma popularidade de três mil estrelas no Github, e o site do projeto contabiliza dezenas de milhares de visitas vindas de mais de 150 países. Não me restam dúvidas de que, em Novembro de 2018, de maneira despretensiosa e acidental, eu tinha de fato descoberto uma pérola.

Impacto ao invés de features

Se a ausência de features costuma ser a explicação para a baixa adesão a um produto, o real problema pode não estar na falta delas, mas sim no fato das features já existentes não fazerem brilhar o olho de ninguém. No livro Rework, Jason Fried e David Hansson comentam concorrência e quantidade de features numa seção chamada Underdo your competition. Desbanque seus concorrentes fazendo menos, não mais.

Conventional wisdom says that to beat your competitors, you need to one-up them. If they have four features, you need five (or fifteen, or twenty-five). If they're spending 0,000, you need to spend $30,000. If they have fifty employees, you need a hundred.
This sort of one-upping, Cold War mentality is a dead end. When you get suckered into an arms race, you wind up in a never-ending battle that costs you massive amounts of money, time and drive. And it forces you to constantly be on the defensive, too. Defensive companies can't think ahead; they can only think behind. They don't lead; they follow.

Rework

De vez em quando nos pegamos em meio ao desenvolvimento de um produto que se considera atrás do concorrente por ter menos features. Alimentamos a crença de que o sucesso do produto consiste necessariamente em superar a enorme lista de features que o concorrente já oferece. Nesse momento, podemos cair na tentação de conduzir o desenvolvimento do produto por um caminho já trilhado. Podemos chegar à conclusão absurda de que os olhos do nosso cliente vão brilhar quando oferecermos exatamente aquilo que o concorrente já oferece. Querer superar um concorrente com a quantidade de features, ao invés de se dedicar ao impacto de cada uma delas, é se reduzir a colecionar mariscos. Não importa quantos você consiga amontoar, jamais vão se igualar ao impacto causado pelo brilho de uma pequena pérola.