Devemos construir isso? Um framework para decisões de produto

Um pedido de feature pode ser muito claro e ainda esconder a decisão de verdade.

“Adicionar SSO.” “Criar um assistente de IA.” “Fazer dashboards para times.” A entrega pedida é óbvia. O que quase sempre é menos claro é qual problema ela resolve, para quem, o que precisa ser verdade para fazer sentido e o que acontece se o time estiver errado.

Antes de estimar implementação, vale deixar a decisão e suas suposições explícitas o suficiente para serem investigadas.

1. Escreva a decisão por trás da feature

Comece pela decisão que realmente precisa ser tomada.

Uma pergunta formulada como feature pode ser:

Devemos construir dashboards compartilhados?

Uma formulação de decisão adiciona o contexto que pode ser investigado:

Devemos investir agora em dashboards compartilhados porque falta de visibilidade está impedindo contas de time de adotar melhor o produto?

A segunda versão expõe público, problema e consequência esperada.

2. Liste o que precisa ser verdade

Toda decisão de construir depende de suposições. Deixe-as explícitas.

No exemplo dos dashboards, talvez seja necessário acreditar que:

• contas de time realmente têm um problema de visibilidade;
• esse problema afeta adoção ou retenção;
• dashboards resolvem melhor do que alternativas mais simples;
• o segmento afetado importa o suficiente para justificar o custo.

Se o time não consegue dizer o que precisa ser verdade, ainda falta estrutura para confrontar a decisão com evidências. Veja suposições vs evidências em Product Discovery.

3. Investigue explicações concorrentes

Perguntas focadas apenas na demanda podem fazer a primeira solução sugerida parecer inevitável.

Uma investigação mais forte pergunta quais outras explicações poderiam produzir o mesmo problema observado.

Talvez a adoção esteja baixa porque o setup é difícil. Talvez os gestores precisem de permissões, não de dashboards. Talvez a demanda venha de um prospect grande enquanto clientes atuais resolvem o problema de outro jeito.

Hipóteses concorrentes reduzem o risco de usar pesquisa principalmente para justificar a primeira solução sugerida.

4. Ajuste o nível de confiança ao custo de errar

Decisões diferentes justificam níveis diferentes de esforço de pesquisa.

Um experimento barato e reversível tolera mais incerteza. Uma mudança de plataforma de seis meses, uma migração ou uma alteração de pricing deveria enfrentar uma barra de confiança mais alta.

Pergunte:

• quanto custa construir e manter?
• quão difícil é voltar atrás?
• o que deixaremos de construir se escolhermos isso?
• qual evidência ausente poderia realmente mudar a decisão?

A quantidade de evidência necessária depende da decisão, da reversibilidade e das consequências de errar.

5. Mantenha mais de um resultado possível

Um bom framework de decisão deveria permitir vários resultados:

• construir, quando evidência e risco justificam o compromisso;
• rodar um experimento menor, quando a direção parece promissora e ainda há incerteza;
• reformular, quando a pesquisa revela outro problema;
• adiar, quando ainda existem lacunas importantes e a pergunta continua relevante;
• parar, quando o caso é fraco demais para justificar mais atenção.

Adiar pode ser uma decisão disciplinada quando as evidências atuais ainda não justificam o compromisso.

Registre por que a decisão parece defensável

Qualquer que seja o caminho escolhido, o raciocínio precisa continuar compreensível depois.

Um registro útil conecta pergunta, suposições, hipóteses, evidências, contradições e gaps à direção escolhida naquele momento.

Esse histórico dá ao time uma base clara para revisitar a decisão quando novas evidências aparecerem.