Notas sobre construir um produto quieto

O Mole para Mac passou de um marco pequeno de vendas cerca de três semanas depois do lançamento. Em vez de escrever sobre os números, quero anotar algumas escolhas que fiz no caminho, porque a maioria delas vai contra os instintos de um engenheiro em atividade, e são as escolhas que eu defenderia primeiro. Se você está construindo o próprio produto, talvez alguma destas te poupe um desvio.

Eu respondo cada e-mail eu mesmo

Todo o suporte desde o lançamento foi feito à mão: reembolsos, redefinições de ativação, devolver a diferença de preço depois de um desconto, perguntas comuns. O volume é pequeno, bem abaixo de 1% dos usuários chega a escrever, e eu poderia ter ligado um agente para cuidar disso em meia hora. Escolhi não fazer, por dois motivos.

Primeiro, o suporte é onde o produto te conta a verdade. Um pedido de reembolso diz por que o produto decepcionou alguém. Uma pergunta torta diz qual parte do app falha em se explicar. Algumas idas e voltas de e-mail trazem à tona o que a pessoa realmente queria, que muitas vezes não é a coisa que ela pediu primeiro. Filtrar isso por automação no primeiro dia faz você perder o sinal exatamente quando mais precisa dele.

Segundo, cuidar de cada caso te deixa fluente. Depois de rodadas suficientes você sabe a melhor resposta para cada classe de problema, e sabe quais problemas o produto deveria absorver para a pergunta nunca mais ser feita. Quando o volume crescer e eu de fato trouxer automação, ela vai codificar essa fluência, em vez de chute.

Meu limiar para automação não é uma contagem de chamados. Quero que a pergunta se repita, que a resposta continue estável e que as exceções estejam entendidas. Até lá, a conversa bagunçada é a pesquisa. Depois desse ponto, a automação pode cuidar do caminho conhecido e ainda deixar fácil um caso incomum chegar a uma pessoa.

Até agora a abordagem se sustenta: não gastei nada com marketing, o crescimento é boca a boca, e a taxa de reembolso está abaixo de 0,8%.

O andaime pode esperar

A mesma lógica vale para a infraestrutura. Não montei um sistema de chamados, um help desk nem uma base de conhecimento antes do lançamento. Engenheiros adoram construir a maquinaria de apoio primeiro porque é a parte que sabem construir, e a IA transformou isso num trabalho de meio dia, o que deixa mais tentador e igualmente fácil otimizar cedo demais. O meio dia é real; o custo contínuo de cuidar de um sistema de que você ainda não precisava também é. Eu acrescentaria o sistema quando a ausência começasse a perder pedidos, esconder o tempo de resposta ou tornar a mesma resposta inconsistente. Antes disso, a caixa de entrada é mais simples e mais informativa.

Decidir o que não construir

A diferença entre um bom produto e um mediano está sobretudo nas coisas que ele recusa fazer. Quais recursos cabem em qual versão, quais pedidos são necessidades reais e quais só soam como se fossem, quais ideias genuinamente boas ainda não cabem neste produto. Já pedi desculpas a usuários que sugeriram recursos bons nos próprios termos, porque um Mac tem um monte de truques bonitos que o Mole não deveria executar. Dizer sim a tudo produz um ensopado, e um ensopado é difícil de manter e mais difícil ainda de confiar para apagar arquivos.

Guardo na cabeça cerca de meio ano do caminho do produto: o que cada versão acrescenta, o que fica de fora e onde as coisas pousam para uma pessoa que abre pela primeira vez encontrá-las sem instruções. Se a primeira tarefa comum precisa de um manual, a interface falhou com as pessoas que eu mais quero alcançar. Documentação continua importando para profundidade, casos de borda e confiança, mas não deveria resgatar a forma básica do produto. A velha navalha diz melhor: não acrescente uma entidade se ela não for necessária.

Agora uso três vetos antes de um recurso chegar ao roadmap. Ele não deve acrescentar um timer, um ouvinte ou um custo de amostragem sempre ligados, a menos que a pessoa tenha entrado no recurso. Não deve alargar o auxiliar privilegiado nem pedir uma permissão nova só para tornar uma pequena conveniência possível. E não deve acrescentar um ajuste quando um padrão calmo pode tomar a decisão por todo mundo. Não são regras universais de software. São um orçamento para este produto: trabalho residente, privilégio e configuração são formas de superfície que os usuários têm de confiar para sempre.

A posição

A posição do Mole cabe numa frase: um zelador quieto para o seu Mac. Ele limpa, desinstala, otimiza, analisa e observa, e no resto do tempo sai do caminho. A ambição é simples de dizer: se um em cada cem usuários de Mac ficar com o Mole, ele terá se tornado genuinamente útil. Há pouco, alguns usuários com deficiência visual começaram a usá-lo e esbarraram em arestas ainda grosseiras, então as correções de acessibilidade passaram na frente de recursos novos. Estou curioso para ver como o app fica para eles; um zelador quieto deveria ser quieto para todo mundo.

Manter produtos humanos na era da IA

A IA tornou boa parte deste produto possível. Ela não substituiu falar com as pessoas que o usam, e eu não acho que deva substituir. Eficiência está fácil de comprar agora; a sensação e a confiança entre um desenvolvedor e os usuários ainda precisam ser conquistadas uma conversa de cada vez. Talvez seja assim que produtos feitos com IA conservem o calor humano: o código pode ser gerado, a relação não.

Este é o meu primeiro produto pago, e algumas destas decisões podem se mostrar erradas. Se você já andou mais tempo nesta estrada do que eu e me vir fazendo algo tolo, eu gostaria de ouvir. Como o Mole chegou aqui em primeiro lugar é uma história mais longa, contada em De um script de shell de 500 linhas a um app para Mac.