Fundamentos de produto · Iniciante

De uma ideia a um problema que dá para resolver

Em uma linha: Antes de escolher tecnologia, escreva quem sofre com o problema, o que essa pessoa faz hoje no lugar e como você vai saber que ele foi resolvido.

A maioria das ideias chega formulada como solução: “quero um sistema que responda aos clientes”. É uma formulação natural e também a principal razão de projetos travarem no terceiro mês. Uma solução sem problema definido é um alvo móvel: cada pessoa na mesa imagina uma coisa diferente e não há como encerrar uma discussão.

Três perguntas que precisam de resposta por escrito

Quem, e em que momento do dia. Não “os clientes”, mas a atendente que abre um chamado e passa oito minutos procurando em documentos. Quanto mais específica a descrição, mais claro fica o que o sistema precisa fazer — e, mais importante, o que não precisa.

Qual é a solução atual. Todo problema já tem uma solução, mesmo que ruim: uma planilha, uma pergunta no grupo, o veterano que todo mundo consulta. Essa é a sua base de comparação real.

Como o sucesso aparece em número. Tempo de atendimento, percentual de casos fechados sem gente, minutos economizados por semana. Se não dá para formular uma métrica, a ideia ainda é uma intuição — tudo bem, mas então o próximo passo é investigar, não desenvolver.

Um documento de uma página

Antes da primeira linha de código: a pessoa e o momento, a solução atual e sua fraqueza, a métrica de sucesso, três exemplos reais de entrada e saída desejada, e uma lista do que não entra na primeira versão.

Os três exemplos são a parte importante: transformam uma discussão abstrata em conversa sobre um caso concreto. Se for difícil escrevê-los, essa é a descoberta: ainda não há acordo sobre o que o sistema deve devolver.

Indo mais fundo

Os exemplos reunidos na definição são a semente do seu conjunto de avaliação. Junte de 20 a 50 casos reais do campo — incluindo casos limite e casos sem boa resposta — antes de começar a desenvolver. É o investimento que se paga mais rápido.