Apaixone-se pelo problema, não pela solução
Criar um protótipo ficou mais fácil. Descobrir se alguém precisa dele ainda exige observar trabalho real, testar hipóteses e abandonar boas ideias.
neste artigo
Um protótipo pode ficar pronto antes de você conseguir marcar a primeira conversa com um cliente. Isso é útil. Também facilita passar uma semana construindo algo que ninguém pediu.
A parte perigosa é que a tela funciona. O formulário envia, o painel mostra números e a demonstração impressiona. Cada detalhe pronto aumenta a vontade de defender o produto. Só falta descobrir se ele merece existir.
Apaixone-se pelo problema, não pela solução, de Uri Levine, dá nome a essa disciplina. Minha leitura da ideia é prática. Antes de escolher o que construir, descubra qual trabalho alguém está tentando terminar e o que o impede.
Peça para ver a última vez
"Você usaria um sistema que organiza seus pedidos?" é uma pergunta confortável. A pessoa pode dizer sim sem mudar nada na própria vida.
Prefiro pedir que ela mostre o último pedido que deu trabalho. Qual mensagem chegou primeiro? Onde anotou o valor? Como descobriu que faltava uma informação? Quanto tempo esperou até conseguir continuar?
Imagine uma distribuidora que recebe pedidos pelo WhatsApp e depois copia tudo para uma planilha. A primeira ideia seria criar um portal. Ao acompanhar o processo, você pode descobrir que copiar os dados leva pouco tempo. A espera está na aprovação de descontos, que depende de uma única pessoa.
Nesse exemplo hipotético, um portal pode organizar a entrada e manter o atraso intacto. A fila mudou de endereço.
Escreva o problema sem citar uma tecnologia
Uma descrição útil seria "a pessoa responsável pelo pedido espera uma aprovação antes de confirmar a entrega". Dá para investigar quem aprova, quando isso acontece e quais pedidos poderiam seguir sozinhos.
"Precisamos de um agente de IA" já escolheu uma resposta. Não explica por que um pedido está parado.
Antes de desenhar a interface, registre:
- Quem faz o trabalho e em qual situação.
- O que essa pessoa usa hoje, inclusive mensagens e papel.
- Onde ela perde tempo ou precisa refazer uma etapa.
- Qual mudança observável justificaria trocar de processo.
Use exemplos recentes. Uma conversa sobre o que aconteceu ontem costuma render mais que uma previsão sobre o que alguém faria no próximo ano.
Teste a mudança no trabalho
No caso da distribuidora, o primeiro teste poderia ser uma regra de desconto para pedidos comuns. Durante um período combinado, alguém aplica a regra manualmente e registra as exceções. Não é necessário desenvolver um sistema para descobrir se a aprovação era mesmo o atraso principal.
Defina antes o que pretende observar. Por exemplo, reduzir o tempo entre receber um pedido completo e confirmá-lo, sem aumentar as correções posteriores. Essa é uma proposta de medida para o teste, não um resultado prometido.
Anote também o que invalidaria a ideia. Se os pedidos continuam parados porque falta estoque, o diagnóstico estava incompleto. O teste valeu a pena justamente por mostrar isso antes do desenvolvimento.
Um protótipo entra quando ajuda a responder uma dúvida específica. A equipe consegue preencher o pedido sem ajuda? A pessoa que aprova entende o contexto? Se o teste só termina com "ficou bonito", faltou uma pergunta.
Separe interesse de compromisso
Elogiar uma demonstração custa pouco. Reservar tempo para um piloto, trazer dados adequados ao teste e mudar uma rotina custa mais. Esses compromissos dão uma indicação melhor de prioridade.
Ainda assim, um piloto aceito não prova que existe mercado. Acompanhe o uso depois da primeira semana e veja se a pessoa volta quando você deixa de lembrá-la. Pergunte o que ela abandonaria para continuar usando o produto.
Também pode acontecer de o problema ser real e pequeno demais para sustentar um negócio. Uma melhoria que economiza alguns minutos pode ser útil sem justificar uma assinatura, uma implantação e mais uma ferramenta para administrar.
Decida o que faria você parar
Antes do próximo ciclo de desenvolvimento, escreva uma condição para continuar e outra para parar. Compartilhe as duas com quem está construindo.
Esse acordo fica especialmente útil quando já existe código pronto. O tempo gasto pesa na conversa, mas não torna a próxima semana de trabalho obrigatória.
Se você está prestes a pedir mais uma funcionalidade, volte ao último caso real. Descubra o que ficou preso, quem precisou intervir e se a mudança proposta teria ajudado naquele momento. É uma base melhor para decidir o que entra no produto.