Pérolas e mariscos
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 que só abrir a porta da loja pro negócio dar certo.
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, tínhamos de 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 daquele alto volume de trabalho a ser desenvolvido e sem acreditar que estaríamos entregando alguma coisa que os concorrentes já não tivessem entregue, 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 notar que não tínhamos nenhuma pérola a oferecer.
Pérolas
Dois anos mais tarde, inspirado pela homepage de um produto que eu gostava tanto, 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 o desenvolvimento e execução de um trecho de código. Com pouquíssimas linhas de JavaScript, era possível criar uma animação que abria um editor, escrevia nele, abria um terminal, executava comandos e retornava 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. O 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, divulgo 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 permitindo usar o 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 ser a a falta delas, mas o fato das que já existem não fazer 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.
De vez em quando nos pegamos em meio ao desenvolvimento de um produto que se considera atrás do concorrente por ter menos features. Que acredita 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 entregarmos exatamente aquilo que o concorrente já oferece. Querer superar um concorrente com a quantidade de features, ao invés de se dedicar à qualidade 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.