Programar em vez de vender é a procrastinação mais convincente que um fundador tem, porque deixa algo real para trás. Você adiciona uma funcionalidade, o app fica de fato melhor e você sente que trabalhou. Mas se ninguém usou as últimas cinco coisas que você construiu, a sexta não é trabalho de produto.
É fuga com histórico de commits. O sinal de que você está fazendo isso é simples: você continua melhorando um produto que quase ninguém viu.
Criar funcionalidades ou ir atrás de clientes?
Se você precisa perguntar, já sabe a resposta. O que te entrega não é a pergunta, é o seu reflexo quando a prospecção fica desconfortável. O pedido de funcionalidade parece urgente, o roadmap parece atrasado e construir a próxima coisa parece a decisão responsável. Nada disso tem a ver com o cliente.
Tem a ver com você se sentir mais à vontade no editor de código do que na caixa de entrada de alguém.
Em resumo: antes que pessoas reais usem o que você já tem, mais funcionalidades não têm nada a te dizer. Você está acrescentando respostas a perguntas que ninguém fez ainda. No começo, a única informação que importa vem de alguém de fora da sua cabeça que mexe no produto e fica ou vai embora.
Até isso acontecer, cada funcionalidade é um palpite em cima de outro palpite.
Fuga ou trabalho de produto: como saber a diferença
Trabalho de produto de verdade nasce de uma pessoa. Alguém usou o produto, deu de cara com um muro, te contou ou mostrou pelo comportamento, e você está consertando aquele muro específico. A fuga nasce de pessoas imaginárias. Você imagina um usuário que ia querer aquilo e constrói para ele.
A diferença é conseguir dizer para quem é a funcionalidade e apontar o momento em que a pessoa precisou dela. Se a resposta é hipotética ("um usuário pode querer exportar para CSV"), é palpite.
Se a resposta é concreta ("três das sete pessoas que testaram pediram CSV na mesma semana"), é trabalho. Sete pessoas bastam para agir. Zero pessoas não é uma versão menor de sete. É outra categoria, e nenhuma quantidade de código muda isso.
Uma funcionalidade que ninguém pediu não é progresso. É uma aposta feita antes de alguém sentar à mesa.
Excesso de funcionalidades sem nenhum usuário: o esconderijo
Excesso de funcionalidades com usuários é um problema de disciplina. Excesso de funcionalidades sem usuários é um problema de esconderijo, e é pior, porque parece o contrário de se esconder. Você está produzindo. O repositório está movimentado. O changelog está enorme.
E o tempo todo o gargalo real, fazer um desconhecido olhar para o produto, fica intocado, porque é a única tarefa sem código para escrever e sem uma sensação clara de missão cumprida.
Eu já refatorei uma página de configurações para não mandar cinco mensagens. As mensagens teriam me ensinado alguma coisa. A página de configurações não me ensinou nada, a não ser que eu sou bom em evitar mensagens.
Se você já reorganizou o schema do banco num dia em que tinha prometido a si mesmo fazer prospecção, conhece bem essa sensação, e sabe que não é virtude.
Pare de programar e comece a vender: uma regra que funciona
Força de vontade não resolve, porque construir é gostoso de verdade e vender é desagradável de verdade. Você precisa de uma regra que tire a decisão das suas mãos. Esta é a que eu uso, e ela tem uma única variável, de propósito.
Nenhuma funcionalidade nova até que N pessoas certas tenham visto a atual.
A regra é só essa. Como aplicar:
- Escolha o N e a pessoa. Pequeno e real. Algo como "vinte fundadores solo que fazem a própria prospecção". Não um mercado, uma pessoa que você consegue imaginar. Se não consegue imaginar, não consegue contar.
- "Viu" quer dizer usou, não visitou. Uma visualização de página não é uma pessoa. Criou conta, clicou por aí ou assistiu você apresentar o produto: isso conta.
- O produto atual fica congelado até você chegar ao N. Bugs que impedem o uso podem ser corrigidos. Acabamento, telas novas, aquilo que você está doido para construir: tudo trancado.
- Quando chegar ao N, veja o que aconteceu antes de construir. O que as pessoas fizeram, onde travaram, o que pediram duas vezes. Agora você tem uma fila que veio de fora da sua cabeça.
- Aí, e só aí, você constrói o primeiro da fila. E o contador zera. A próxima funcionalidade espera o próximo N.
A regra funciona porque transforma a tarefa desconfortável na única tarefa liberada. Você quer construir, e o único caminho de volta para o código passa direto pela prospecção que você vinha evitando. Deixa de ser uma queda de braço com a força de vontade e vira uma trava.
Onde uma ferramenta ajuda, e onde não ajuda
Dá para aplicar essa regra hoje só com uma planilha e a sua própria caixa de entrada, e você deveria, pelo menos até que fazer as pessoas verem o produto seja a única etapa que ainda não funciona. Se o seu problema é continuar construindo em vez de lançar, nenhum software resolve. A trava acima é de graça, e ela resolve tudo sozinha.
O único ponto em que uma ferramenta se paga é o passo dois, onde "viu" precisa significar N pessoas reais que olharam de fato. Na mão, isso não escala. Uma apresentação de verdade para uma pessoa leva dez minutos, e vinte delas são a sua semana inteira, então aos poucos tudo degringola num disparo genérico que ninguém assiste.
Foi para esse muro que eu criei o Personade, o que faz dele, sim, mais uma coisa que eu construí em vez de vender. A diferença é que ele existe para te empurrar de volta para a prospecção.
Ele roda a sua prospecção no LinkedIn: o convite, a mensagem e os follow-ups, enviados da sua própria conta, e para assim que alguém responde. Se a sua mensagem é uma apresentação em vídeo, um add-on de vídeo feito para você dá a cada lead a própria versão, com uma abertura só para ele, e mostra quem assistiu. É o sinal de "viu", já contado para você.
O que ele não faz é escrever as mensagens, escolher o seu N ou transformar um produto que ninguém quer num produto que as pessoas querem. Essas partes continuam com você.
Se quiser entender melhor por que essa mudança aconteceu, eu escrevi sobre por que construir ficou de graça e vender não, e se o problema mais fundo é que você pulou a distribuição por completo, comece por lá.
Perguntas frequentes
Devo criar mais funcionalidades ou focar em conseguir clientes? Clientes primeiro, quase sempre. Uma funcionalidade só ensina alguma coisa depois que pessoas reais usaram o produto e mostraram onde ele quebra. Sem usuários, uma funcionalidade nova é um palpite sem nada com que comparar. Crie uma regra que você consiga cumprir: nenhuma funcionalidade nova até que um número definido das pessoas certas tenha usado a atual.
Como sei se estou programando para fugir de vender? Faça duas perguntas sobre a funcionalidade. Para quem ela é, e quando essa pessoa bateu no muro que ela resolve. Se você consegue citar pessoas reais e o momento exato, é trabalho de produto. Se o usuário é hipotético e o prazo é "algum dia", é fuga. Repositório movimentado e changelog longo parecem progresso, mas não medem nada enquanto ninguém viu o produto.
Qual é uma boa regra para parar de criar funcionalidades sem ter usuários? Congele o produto até que um número fixo das pessoas certas tenha usado o que você já construiu. Escolha algo pequeno e real, como vinte. "Usou" quer dizer que criou conta e clicou por aí, não que visitou uma página. Só depois de chegar ao número você olha o que elas fizeram e constrói o pedido mais frequente. Aí o contador zera e você recomeça.
As funcionalidades de que você tem orgulho são invisíveis para todo mundo menos você, até que alguém de fora da sua cabeça tenha um motivo para mexer nelas. Isso não é um problema de construção, e o problema de construção você já resolveu.
É a única tarefa sem uma sensação clara de missão cumprida, e é justamente por isso que ela continua perdendo para as tarefas que têm essa sensação. Coloque a trava na sua frente esta semana e deixe que ela decida.