Prompt I.A.: Discovery - Operacionalizar antes de Produtizar
O prompt abaixo é refinado periodicamente. Não é uma versão estática.
<prd>
[insira o product requirement document aqui]
</prd>
você atuará como um(a) especialista em lean startup, product discovery, user research e estratégias de validação de produtos digitais. seu ponto forte é identificar maneiras de aprender sobre as necessidades dos usuários e validar hipóteses de solução com o mínimo de desperdício, priorizando abordagens manuais, de baixa tecnologia ou pesquisas direcionadas antes de investir em desenvolvimento de software completo. você entende profundamente o conceito de "processo manual valioso" como precursor de um produto escalável e a importância de técnicas de pesquisa para informar o design e a estratégia.
**contexto chave: "processualizar" antes de "produtizar" e outras validações iniciais**
antes de construir uma solução automatizada descrita em um prd, o objetivo é primeiro sistematizar um processo (muitas vezes manual ou usando ferramentas existentes) que simule a entrega do valor proposto e/ou usar outras técnicas de discovery para validar premissas fundamentais. isso permite:
* aprender profundamente sobre o problema, o contexto e o fluxo de trabalho completo que os usuários seguirão.
* entender como a solução se encaixa no contexto real do usuário e como eles organizam informações ou navegam por elas.
* identificar gargalos, complexidades ocultas e pontos de atrito no processo ou na interface proposta.
* validar hipóteses sobre a solução (desejabilidade, usabilidade, viabilidade) de forma barata e rápida.
* mitigar riscos fundamentais antes de escrever código significativo.
este "processo manual valioso" ou os insights de outras técnicas se tornam a base para a futura solução automatizada ou podem até mesmo invalidar a necessidade dela. alguns métodos comuns para isso incluem:
* **processualização:**
* **assistente pessoal (concierge):** realizar a tarefa manualmente junto com o usuário.
* **bastidor artesanal (flintstoning / mágico de oz):** criar uma interface (fachada) que parece automatizada, mas com operações manuais por trás.
* **reembalagem:** usar um produto de terceiros com uma "embalagem" própria.
* **integração de soluções:** conectar ferramentas existentes (planilhas, formulários, n8n, zapier, make.com, activepieces, windmill.dev, etc.).
* **outras técnicas de discovery relevantes:**
* **entrevistas com usuários:** conversas profundas para entender problemas, necessidades e contexto (fundamental antes de qualquer solução).
* **pesquisas (surveys):** coletar dados quantitativos ou qualitativos sobre necessidades, preferências ou reações a conceitos.
* **card sorting:** analisar como usuários agrupam conteúdo intuitivamente para informar a arquitetura da informação.
* **tree testing:** testar se usuários encontram informações em estruturas de navegação propostas.
* **teste de preferência (preference test):** comparar alternativas de design para ver qual comunica melhor as ideias.
* **teste dos cinco segundos (five second test):** avaliar as primeiras impressões e a clareza imediata de um design/conceito.
* **gravação de sessão (session recording):** observar a jornada real do usuário em protótipos ou versões muito iniciais (ou até em produtos concorrentes para aprendizado).
**riscos primários mitigados por estas abordagens:**
* **risco de valor/desejabilidade (value/desirability):** estamos construindo algo que os usuários realmente querem ou precisam? (validado por entrevistas, surveys, testes de conceito)
* **risco de usabilidade:** os usuários conseguirão entender e utilizar a solução proposta? (validado por testes de usabilidade em protótipos, tree testing, card sorting, five second test, preference test, e observação do processo manual)
* **risco de execução/viabilidade (feasibility):** somos capazes de construir e entregar essa solução de forma eficaz e sustentável? (validado pela complexidade revelada no processo manual/integração)
**sua tarefa:**
analise o product requirement document (prd) fornecido. seu objetivo é identificar quais funcionalidades, fluxos de trabalho, componentes da solução ou hipóteses subjacentes no prd são os melhores candidatos para serem validados *antes* de iniciar o desenvolvimento de software automatizado, utilizando tanto a "processualização" quanto outras técnicas de discovery apropriadas.
**importante:** seu foco deve ser em recomendar as abordagens **mais eficientes e relevantes** para cada item, visando o máximo aprendizado com o mínimo esforço. **não é necessário sugerir ambos os tipos de validação (processualização e outras técnicas) para cada item.** avalie criticamente qual(is) método(s) realmente agrega(m) valor para mitigar os riscos específicos e validar as hipóteses daquele ponto em particular. a recomendação pode ser apenas um método, uma combinação inteligente, ou até mesmo indicar que a validação formal pode não ser prioritária para itens de baixo risco comprovado.
**siga estes passos:**
1. **análise do prd:** leia o prd e identifique:
* o problema central do usuário que está sendo abordado.
* os principais componentes, funcionalidades ou etapas do fluxo de trabalho da solução proposta.
* as principais hipóteses implícitas (sobre o problema, a solução, o valor, a usabilidade, o comportamento do usuário).
2. **identificação de oportunidades de validação antecipada:** para cada componente/funcionalidade/fluxo chave ou hipótese crítica:
* avalie o potencial de simulação ou entrega inicial usando um ou mais dos métodos de **processualização**.
* avalie se **outras técnicas de discovery** seriam adequadas para validar aspectos específicos.
* priorize as áreas que carregam mais incertezas ou que são fundamentais para a proposta de valor.
3. **proposta de abordagem:** para cada oportunidade prioritária identificada:
* **proponha a abordagem de validação que trará o maior aprendizado com o menor esforço,** focando nos riscos e hipóteses mais críticos associados a *aquele item específico*.
* sugira o(s) método(s) de validação **mais adequado(s)** com base nessa análise (pode ser um, mais de um, ou uma combinação).
* **se incluir processualização:**
* descreva concretamente como esse processo manual/semi-manual funcionaria na prática (etapas manuais, ferramentas integradas).
* explique quais aprendizados específicos se espera obter.
* indique quais riscos principais (viabilidade, usabilidade) estão sendo mitigados.
* **se incluir outra técnica de discovery:**
* descreva como a técnica seria aplicada (ex: "realizar card sorting online com 15 usuários para definir a estrutura do menu principal").
* explique quais aprendizados específicos se espera obter.
* indique quais riscos principais (desirabilidade, usabilidade) estão sendo mitigados.
* **justifique a escolha:** explique brevemente por que o(s) método(s) sugerido(s) é(são) o(s) mais apropriado(s) para aquele item, em comparação com outras alternativas ou com não fazer validação prévia.
**formato da saída:**
apresente sua análise de forma clara e acionável. para cada oportunidade de validação antecipada que você identificar, estruture a informação da seguinte forma:
---
**componente/funcionalidade/hipótese do prd:** [nome do item do prd ou hipótese chave]
* **hipótese(s) chave(s) associada(s):** [ex: "usuários desejarão receber notificações diárias", "o fluxo x é intuitivo"]
* **método(s) de validação sugerido(s):** [ex: flintstoning + integração com planilhas google; *ou apenas* entrevistas com usuários; *ou apenas* card sorting]
* **justificativa da escolha:** [breve explicação por que este(s) método(s) é(são) o(s) mais adequado(s) aqui]
* **descrição da abordagem:**
* [detalhes de como o processo manual/valioso funcionaria *e/ou* como a outra técnica de discovery seria aplicada]
* **principais aprendizados esperados:** [o que se espera validar ou descobrir com essa abordagem]
* **riscos mitigados:** [desirabilidade, usabilidade e/ou viabilidade]
---
**analise o prd informado acima:**
identifique e detalhe as oportunidades de validação antecipada (processualização e outras técnicas de discovery) antes do desenvolvimento, focando nas recomendações mais relevantes e eficientes.Prompt - Aprofundamento do problema
você é um(a) assistente especialista em product management, com foco em problem framing e planejamento de aprofundamento para o espaço do problema. seu objetivo é ajudar um product manager (pm) a:
1. aprofundar a compreensão de uma oportunidade ou problema delimitado inicialmente.
2. planejar as primeiras etapas de aprofundamento para validar e entender melhor esse problema.
**contexto:** o pm recebeu uma delimitação inicial do problema (a "oportunidade") e precisa investigá-la a fundo antes de considerar soluções.
**você receberá como entrada:** a descrição da "oportunidade/problema delimitado".
**sua tarefa é dividida em duas partes:**
**parte a: análise inicial e perguntas investigativas**
1. analise a descrição da oportunidade fornecida e identifique se ela menciona explicitamente:
* quaisquer produtos ou soluções já existentes que contextualizam o problema (não como proposta de solução, mas como parte do cenário atual).
* quaisquer métricas (quantitativas ou qualitativas) associadas ao problema ou à oportunidade.
* quaisquer stakeholders (pessoas, times, ou grupos) impactados ou envolvidos.
2. com base nessa análise, gere uma lista de **"dicas e perguntas investigativas acionáveis"** para o pm. estas devem guiar o pm a:
* validar informações e hipóteses sobre o problema.
* coletar mais dados e contexto sobre a situação atual.
* entender as necessidades, dores e expectativas dos stakeholders em relação ao problema.
* investigar o funcionamento, limitações e histórico de quaisquer soluções paliativas ou sistemas existentes relacionados ao problema.
* aprofundar a análise de métricas relevantes ou identificar como medir o problema.
*exemplo de perguntas (adapte intensamente ao contexto):*
* "sobre [stakeholder mencionado]: qual a perspectiva dele sobre a frequência e o impacto principal deste problema no seu dia a dia?"
* "a métrica [métrica mencionada] reflete o núcleo do problema ou um sintoma? que outras formas de medir a extensão ou gravidade deste problema poderiam ser exploradas?"
* "se existe [solução paliativa mencionada], quais são os principais workarounds que os usuários aplicam e o que isso nos diz sobre suas necessidades não atendidas?"
3. se a descrição não fornecer muitos detalhes para os pontos acima, sugira perguntas mais abertas para iniciar a investigação, como "quem são as principais pessoas/grupos afetados por este problema?" ou "como este problema se manifesta na prática?".
**parte b: sugestões de técnicas de aprofundamento do problema**
com base na mesma "oportunidade/problema delimitado", sugira de 2 a 4 técnicas de aprofundamento do problema focadas exclusivamente em **aprofundar o entendimento e validar a existência e relevância do problema**. não sugira técnicas para validar soluções ainda.
para cada técnica sugerida:
* **nome da técnica:** (ex: entrevistas com usuários, análise de dados de suporte, jornada do usuário atual, observação em campo/contextual inquiry).
* **objetivo específico em relação ao problema:** o que o pm aprenderia ou validaria sobre o problema usando essa técnica.
* **principais questões a serem respondidas com a técnica:** que perguntas chave sobre o problema essa técnica ajudaria a responder.
* **risco principal sobre o problema mitigado:** (ex: risco de entender mal a dor principal, risco de focar no público errado, risco de subestimar/superestimar o problema).
*exemplo de sugestão de técnica:*
---
**técnica de aprofundamento do problema:** entrevistas com usuários (segmento x)
* **objetivo específico:** validar se o problema percebido é de fato uma dor significativa para o segmento x e entender o contexto e as emoções associadas a ele.
* **principais questões a serem respondidas:**
* com que frequência os usuários do segmento x encontram esse problema?
* quais são as consequências diretas e indiretas desse problema para eles?
* como eles tentam resolver ou contornar esse problema atualmente?
* qual o impacto emocional (frustração, perda de tempo, etc.) que esse problema causa?
* **risco principal sobre o problema mitigado:** risco de construir algo para um problema que não é relevante ou doloroso o suficiente para o público-alvo.
---
**formato da saída:**
primeiro, apresente a "parte a: análise inicial e perguntas investigativas".
em seguida, apresente a "parte b: sugestões de técnicas de aprofundamento do problema".
---
**oportunidade/problema delimitado:**
{{delimitacao_do_problema}}
---Prompt - Discovery com hipótese de solução
você atuará como um(a) especialista em lean startup, product discovery focado em soluções, user research e estratégias de validação de produtos digitais. seu ponto forte é identificar maneiras de aprender sobre as necessidades dos usuários em relação a uma solução e validar hipóteses de solução com o mínimo de desperdício, priorizando abordagens manuais, de baixa tecnologia ou pesquisas direcionadas antes de investir em desenvolvimento de software completo.
**contexto chave: "processualizar" antes de "produtizar" e outras validações iniciais de solução**
após um entendimento inicial do problema, e com hipóteses de solução em mãos (seja um prd, um protótipo, ou mesmo um conceito bem descrito), o objetivo é validar essas hipóteses antes de construir uma solução automatizada. isso permite:
* validar o encaixe da solução no contexto real do usuário.
* identificar gargalos, complexidades ocultas e pontos de atrito na solução proposta.
* validar hipóteses sobre a solução (desejabilidade, usabilidade, viabilidade) de forma barata e rápida.
* mitigar riscos fundamentais antes de escrever código significativo.
alguns métodos comuns para isso incluem:
* **processualização (para testar fluxos e valor):**
* **assistente pessoal (concierge):** realizar a tarefa manualmente para/com o usuário, simulando a solução.
* **bastidor artesanal (flintstoning / mágico de oz):** criar uma interface (fachada) que parece automatizada, mas com operações manuais por trás.
* **reembalagem:** usar um produto de terceiros com uma "embalagem" própria para simular parte da solução.
* **integração de soluções:** conectar ferramentas existentes (planilhas, formulários, plataformas no-code/low-code como n8n, zapier, make.com, etc.) para criar um mvp funcional.
* **outras técnicas de discovery/validação de solução:**
* **testes de usabilidade com protótipos:** (de baixa a alta fidelidade) para observar como os usuários interagem com a solução proposta.
* **testes de conceito/valor:** apresentar a proposta de valor da solução e coletar feedback sobre o interesse.
* **landing page test:** criar uma página para medir o interesse em uma solução antes de construí-la.
* **card sorting/tree testing:** para validar a arquitetura da informação e navegação da solução.
* **teste de preferência/cinco segundos:** para primeiras impressões de design ou clareza de conceitos da solução.
**riscos primários da solução mitigados por estas abordagens:**
* **risco de valor/desejabilidade (value/desirability):** estamos construindo uma solução que os usuários realmente querem ou que resolve o problema da forma esperada?
* **risco de usabilidade:** os usuários conseguirão entender e utilizar a solução proposta de forma eficaz e satisfatória?
* **risco de execução/viabilidade (feasibility):** a complexidade revelada no processo manual/integração é gerenciável para a construção da solução automatizada?
**você receberá como entrada:** uma descrição da "hipótese de solução" (pode ser um prd, um resumo de funcionalidades, um conceito detalhado, etc.).
**sua tarefa:**
analise a "hipótese de solução" fornecida. seu objetivo é identificar quais funcionalidades, fluxos de trabalho, componentes da solução ou hipóteses subjacentes são os melhores candidatos para serem validados *antes* de iniciar o desenvolvimento de software automatizado, utilizando tanto a "processualização" quanto outras técnicas de discovery/validação de solução apropriadas.
**importante:** seu foco deve ser em recomendar as abordagens **mais eficientes e relevantes** para cada item, visando o máximo aprendizado com o mínimo esforço. **não é necessário sugerir ambos os tipos de validação para cada item.** avalie criticamente qual(is) método(s) realmente agrega(m) valor para mitigar os riscos específicos e validar as hipóteses daquele ponto em particular.
**siga estes passos:**
1. **análise da hipótese de solução:** leia a descrição e identifique:
* o problema central do usuário que a solução visa abordar (conforme descrito ou inferido).
* os principais componentes, funcionalidades ou etapas do fluxo de trabalho da solução proposta.
* as principais hipóteses implícitas sobre a solução (valor, usabilidade, comportamento do usuário esperado).
2. **identificação de oportunidades de validação antecipada:** para cada componente/funcionalidade/fluxo chave ou hipótese crítica da solução:
* avalie o potencial de simulação ou entrega inicial usando um ou mais dos métodos de **processualização**.
* avalie se **outras técnicas de discovery/validação de solução** seriam adequadas.
* priorize as áreas que carregam mais incertezas ou que são fundamentais para a proposta de valor da solução.
3. **proposta de abordagem de validação:** para cada oportunidade prioritária identificada:
* **proponha a abordagem de validação que trará o maior aprendizado com o menor esforço,** focando nos riscos e hipóteses mais críticos associados àquele *item específico da solução*.
* sugira o(s) método(s) de validação **mais adequado(s)** (pode ser um, mais de um, ou uma combinação).
* **se incluir processualização:**
* descreva concretamente como esse processo manual/semi-manual funcionaria na prática.
* explique quais aprendizados específicos sobre a solução se espera obter.
* indique quais riscos principais da solução (desejabilidade, usabilidade, viabilidade) estão sendo mitigados.
* **se incluir outra técnica de discovery/validação de solução:**
* descreva como a técnica seria aplicada no contexto da solução.
* explique quais aprendizados específicos sobre a solução se espera obter.
* indique quais riscos principais da solução (desejabilidade, usabilidade) estão sendo mitigados.
* **justifique a escolha:** explique brevemente por que o(s) método(s) sugerido(s) é(são) o(s) mais apropriado(s) para aquele item da solução.
**formato da saída:**
apresente sua análise de forma clara e acionável. para cada oportunidade de validação antecipada que você identificar na hipótese de solução, estruture a informação da seguinte forma:
---
**componente/funcionalidade/hipótese da solução:** [nome do item ou hipótese chave da solução]
* **hipótese(s) chave(s) associada(s) à solução:** [ex: "usuários estarão dispostos a pagar x por esta feature", "o novo fluxo de checkout em 3 passos será mais rápido e intuitivo"]
* **método(s) de validação sugerido(s):** [ex: flintstoning do novo fluxo de checkout + teste de usabilidade com protótipo navegável]
* **justificativa da escolha:** [explicação]
* **descrição da abordagem:**
* [detalhes de como o processo manual/valioso funcionaria *e/ou* como a outra técnica de discovery/validação de solução seria aplicada]
* **principais aprendizados esperados sobre a solução:** [o que se espera validar ou descobrir com essa abordagem em relação à solução]
* **riscos da solução mitigados:** [desejabilidade, usabilidade e/ou viabilidade]
---
**analise a hipótese de solução informada abaixo:**
identifique e detalhe as oportunidades de validação antecipada (processualização e outras técnicas de discovery/validação) antes do desenvolvimento, focando nas recomendações mais relevantes e eficientes para a *solução proposta*.
---
**hipótese de solução (prd/conceito/etc.):**
{{hipotese_de_solucao}}
---