Produto
Valide a necessidade de uma feature antes de construí-la
Um memorando de decisão que testa se uma feature proposta atende a um problema verificado de usuário ou negócio e escolhe construir, descobrir, adiar ou rejeitar.
O processo
Faça nesta ordem.
- Declare a capacidade proposta, o resultado pretendido, os usuários afetados, o prazo da decisão, as alternativas atuais e quais evidências mudariam a decisão.
- Reúna comportamento do usuário, evidências de suporte, pesquisa, dados de produto e contexto de negócios, distinguindo um pedido declarado de uma necessidade observada.
- Mapeie a necessidade para trabalhos dos usuários, frequência, gravidade, adequação estratégica, restrições e custo de deixar o problema sem solução.
- Projete o menor teste de descoberta seguro, como protótipo, tentativa com atendimento, funil instrumentado ou conversa com cliente, com critérios de sucesso e de parada.
- Compare construir, comprar, mudar o processo, adiar e rejeitar em termos de valor esperado, custo, reversibilidade, risco e valor de aprendizagem.
- Registre a decisão, a confiança, o responsável, a data, as premissas, as evidências que a contradiriam e o teste ou métrica de acompanhamento que acionará uma mudança.
- Entregue o memorando com evidências e riscos não resolvidos e pause antes de comprometer gastos, expor usuários ou anunciar uma decisão de construção.
Traga isto
Entradas que o gato vai pedir.
- proposta de recurso e resultado-alvo
- evidências de usuário e negócios
- alternativas e restrições
- responsável pela decisão e horizonte do teste
Roteador + um playbook
Roteie primeiro. Escolha um.
O Cat Paw carrega um playbook por tarefa, sem misturar vários. Comece por este roteador; os outros caminhos são candidatos específicos do workflow.
- Roteador:
minimal-code-pack skills/minimal-code-pack/feature-necessity-decision/SKILL.md
Limites
As fronteiras viajam com o prompt.
- Verifique as ferramentas, contas, permissões e o espaço de trabalho reais antes de começar; nunca afirme que uma ferramenta, conta, fonte ou capacidade indisponível existe.
- Use Latch/target-workspace para código privado, artefatos, sondagens ao vivo ou dados não públicos; se esse acesso estiver indisponível, pare no limite e relate o bloqueio em vez de substituir por uma suposição.
- Pause para aprovação explícita antes de ações externas consequentes; retorne evidências, riscos não resolvidos, premissas e qualquer ação que ainda esteja aguardando aprovação.
Pronto significa
Um fim que dá para checar.
Um memorando revisável de validação da necessidade recomenda construir, descobrir, adiar ou rejeitar, com evidências de usuários, alternativas, confiança, um teste de acompanhamento e riscos não resolvidos explícitos.
Fontes
De onde veio este processo.
- github.com/DietrichGebert/ponytail/tree/e3ba2aa6f1e6f0bc4d69eb09c9f0d0a93af56156/
- www.gov.uk/service-manual/user-research
- www.gov.uk/service-manual/service-assessments
As fontes estabelecem o padrão do workflow. Posts de Reddit e da comunidade, quando aparecem, valem como anedota de quem pratica — não como fato universal.
