Escolha uma tarefa recorrente, observe como ela é resolvida hoje e teste uma solução pequena com pessoas que convivem com o problema. Interesse é um sinal inicial; uso real e disposição de pagar são evidências diferentes.
Troque a lista de funções por uma tarefa concreta
“Um aplicativo para empresas” é uma ideia ampla demais para orientar o primeiro passo. “Organizar as informações necessárias para enviar um orçamento” descreve uma tarefa que pode ser observada. Quem a executa? Em qual momento? O que costuma faltar? Como a pessoa resolve isso hoje?
Antes de desenhar telas, registre o percurso de uma tarefa do começo ao fim. Inclua planilhas, conversas, papéis, cópias de arquivo e conferências manuais. É nesse caminho que aparecem os atritos que um software poderia reduzir.
Você não precisa encontrar algo que ninguém jamais tentou. Precisa entender um grupo de pessoas e um problema com clareza suficiente para propor uma melhoria útil.
Pergunte sobre o último caso real
“Você usaria um sistema assim?” costuma gerar uma resposta educada. Perguntas sobre acontecimentos concretos ajudam mais: quando isso aconteceu pela última vez, quanto trabalho deu e o que a pessoa fez para resolver?
- Peça que ela mostre o processo atual, se puder compartilhar.
- Pergunte o que acontece quando uma etapa dá errado.
- Entenda quem usa a solução e quem decide pagar.
- Separe uma reclamação ocasional de uma necessidade frequente.
Anote também o que contradiz sua ideia. Se todos resolvem a tarefa rapidamente com uma ferramenta que já possuem, talvez o problema seja outro. Não force a conversa para confirmar a solução que você imaginou.
Desenhe a menor entrega que ainda tem valor
A primeira versão deve completar uma tarefa, mesmo que faça poucas coisas. Para um orçamento, por exemplo, isso pode significar cadastrar itens, calcular o total e produzir um documento legível. Relatórios elaborados e dezenas de personalizações podem esperar.
Complete: “A primeira versão estará útil quando a pessoa conseguir ______, sem precisar ______.”
Um protótipo pode demonstrar o percurso, mas não comprova que alguém voltará a usá-lo. Depois da demonstração, observe o uso em uma situação real, com limites e condições claros. Não cobre por funções apresentadas como disponíveis quando ainda não existem.
Defina o que você quer aprender
Separe os sinais: elogio à ideia, pedido para testar, conclusão de uma tarefa, retorno ao produto e pagamento não significam a mesma coisa. Registre cada um sem tratá-los como vendas confirmadas.
Em vez de inventar uma meta universal de validação, decida antes quais evidências justificariam investir mais tempo. Pode ser descobrir se as pessoas completam a tarefa sem ajuda e se voltam quando a necessidade reaparece.
Ao final, escreva uma decisão curta: qual problema foi observado, o que a solução resolveu, o que ainda atrapalha e qual será a próxima mudança. Essa nota é mais útil do que uma lista de recursos construída sem contato com quem vai usar.
Um guia do caderno de Jonathan Viana.
Conheça os critérios editoriais e o uso de IA.
