Descoberta de produto como hábito semanal, não fase de projeto

{ "resumo": "## Descoberta como hábito, não fase\n\nO artigo sustenta que product discovery deve ser tocada semanal com clientes pelo próprio time que constrói o produto, em pesquisas pequenas orientadas a um resultado - definição de Teresa Torres em Continuous Discovery Habits. O termo remonta a Marty Cagan (por volta de 2005), que o tomou da indústria farmacêutica, onde se sabe que a maioria dos candidatos falha. Discovery não é um kickoff pré-desenvolvimento nem um tutorial de ferramenta como o Jira Product Discovery.\n\n## Evidência e origens\n\nUma pesquisa da NN/g com 436 profissionais de UX (2019, publicada em 2020) mostra que 75% das organizações dizem rodar discoveries, e quem fez um no último projeto relatou sucesso em 83% dos casos contra 52% sem - dado de autorrelato, não ensaio causal. Na amostra, designers participaram de 74% das discoveries, pesquisadores de 60% e desenvolvedores de apenas 27%; o padrão da NN/g é uma fase de design e pesquisa da qual a engenharia entra tarde. O artigo distingue a fase de discovery da NN/g (enquadramento de problema, como no double diamond) do hábito contínuo de Torres, e cita a origem do dual-track em um paper de Desirée Sy (2007), reforçando que dual-track não são dois times: é um time, dois tipos de trabalho.\n\n## Discovery vs. delivery e os quatro riscos\n\nSeguindo Cagan e Jeff Patton, discovery otimiza aprendizado rápido; delivery, qualidade e previsibilidade - e ambos são contínuos, não fases sequenciais. Cagan apresenta quatro riscos a testar: valor (o cliente trocaria sua alternativa atual?), usabilidade, viabilidade técnica e viabilidade de negócio. A maioria dos esforços falha na solução, não na demanda. Com o barateamento da construção (Cagan citou em 2026 que 10-20 protótipos por semana hoje é fácil), o peso recai sobre decidir o que vale construir.\n\n## Prática semanal\n\nO sistema de Torres combina uma opportunity-solution tree com entrevistas gerativas e testes de suposição avaliativos; as melhores equipes, segundo número de Cagan citado por Torres, fazem 12-15 iterações de discovery por semana. O touchpoint semanal pode ser uma entrevista de 25 minutos, um ride-along de atendimento, um intercepto de cinco minutos ou um teste de protótipo - e recrutamento, não habilidade de entrevistar, é o gargalo: a conversa precisa já estar na agenda na segunda-feira. O artigo reproduz uma semana-exemplo de Andrea López (Get Product People): segunda, checagem de outcome e recrutamento; terça, duas entrevistas; quarta, atualização da árvore; quinta, teste pequeno; sexta, decisão registrada. O product trio (PM, designer e engenheiro) entrevista junto para que discordâncias sejam sobre evidência compartilhada.\n\n## Theater e kill-rate\n\nO diagnóstico de que discovery é real: ela já matou alguma ideia. Ant Murphy, Chantal Botana e Martin Labuschin descrevem, de forma independente, discovery teatral - atividades que geram artefatos sem mudar decisões. Labuschin propõe um protocolo com três campos: critérios de kill escritos antes, evidência considerada (visível) e override nomeado com razão, revisado trimestralmente. Torres ressalva que discovery contínua não substitui pesquisadores qualificados; dissolver UXR e renomear a lacuna é teatro.\n\n## Erros comuns e conclusão\n\nO artigo lista erros: registrar demos e reuniões de stakeholders como entrevistas, sprints de discovery que não podem matar a ideia, dual-track como dois times, medir volume de entrevistas em vez de kill-rate e esperar pesquisa de projeto formal. Conclui que a entrega mais barata por IA eleva o custo de apontar o time para a coisa errada, e que o touchpoint semanal segue necessário.", "hook": "Pesquisas mostram que 75% das organizações dizem rodar product discovery, mas o diagnóstico proposto é simples: se nenhuma ideia já foi morta, o time está especificando, não descobrindo. O artigo argumenta que a prática real é um touchpoint com clientes toda semana - feito pelo trio de produto - e não uma fase de projeto que termina em protótipo.", "entities": ["Teresa Torres", "Marty Cagan", "NN/g", "Jeff Patton", "Martin Labuschin"], "themes": ["gestao-de-produto"], "story_key": "discovery-como-habito-semanal", "reasoning": { "story_key": "Tese canônica do artigo: discovery como hábito semanal do time, não fase de projeto.", "themes": {"gestao-de-produto": "Texto sobre discovery, outcomes, opportunity-solution tree e product trio - núcleo de gestão de produto; sem encaixe em outros temas da taxonomia."}, "entities": {"Teresa Torres": "Autora da definição e do sistema de discovery contínua central ao texto.", "Marty Cagan": "Origem do termo, quatro riscos e split discovery/delivery.", "NN/g": "Pesquisa com 436 profissionais e definições citadas.", "Jeff Patton": "Dual-track e teste de kill-rate citados como referência.", "Martin Labuschin": "Autor do protocolo de kill criteria e da crítica à discovery sem poder." }, "excluded": {"Desirée Sy": "Menção secundária sobre origem do dual-track.", "Andrea López": "Autora do exemplo de semana, menção secundária.", "UX Crush": "Veículo publicador."} } }