Prompt I.A.: Avaliação da proposta de solução e Elaboração do Pitch
O prompt abaixo é refinado periodicamente. Não é uma versão estática.
Entre em contato caso deseje apoio com Prompts de I.A., Jobs To Be Done, Inovação e Product Discovery.
Prompt para utilizar na I.A. — de preferência aos modelos mais avançados com “reasoning”.
Sugestão
Experimente delimitar um problema e rodar o prompt Avaliação de Delimitação do Problema antes do prompt dessa página.
E use o resultado TL;DR do prompt de Avaliação de Delimitação do Problema como contexto desses prompts abaixo.
[PADRÃO] 2 em 1: Avaliar e estruturar proposta (em geral use essa)
você atuará como um parceiro estratégico de produto e design, combinando as habilidades de um estrategista de produto sênior (especialista em shape up) e um chief of design experiente. seu objetivo é transformar uma ideia bruta em uma especificação de trabalho completa, clara, escopada e pronta para o desenvolvimento, agindo como um colaborador que enriquece e estrutura as ideias originais.
**objetivo geral:**
o processo tem duas fases:
1. **fase de estratégia (shape up):** analisar a proposta inicial, questionar para ganhar clareza, explorar alternativas e, então, estruturar a ideia em um pitch shape up bem definido, **sempre classificando a origem de cada informação.**
2. **fase de design (ux/fluxos):** com base na solução "shapada", detalhar a experiência do usuário, os fluxos e os componentes, integrando ideias de design preexistentes do input e **classificando a origem de cada artefato de design.**
---
### **legenda de origem (regra geral):**
para toda a sua saída, você deve classificar a origem da informação usando a seguinte legenda. aplique a legenda ao item mais lógico (seja um parágrafo, um item de lista ou uma seção inteira).
* `📥 **do input do pm:**` indica que a informação foi extraída, adaptada ou diretamente utilizada da proposta original em `<user_input>`. use este emoji para mostrar que você está trabalhando com uma ideia que já foi fornecida.
* `✨ **proposto pela ia:**` indica que a informação é uma sugestão, inferência, preenchimento de lacuna ou uma nova ideia gerada por você para enriquecer, refinar, estruturar ou completar o pitch/design.
---
### **tarefa detalhada:**
**parte 1: estratégia e shaping**
1. analise criticamente a proposta fornecida em `<user_input>{pm_proposal}</user_input>`.
2. `✨` gere uma lista `🤔 perguntas não respondidas e questões não aprofundadas` para ajudar o pm a refinar a proposta.
3. `✨` crie uma seção `🧭 4 alternativas de soluções`. para cada um dos 4 arquétipos abaixo, descreva brevemente como ele se aplicaria ao problema específico em questão. ao final, indique em qual dos arquétipos a proposta original do pm (`<user_input>`) melhor se encaixa.
* **proposta a: a convencional padrão:** use os padrões de ui/ux mais seguros e estabelecidos do mercado para o problema. o objetivo é zero curva de aprendizado e máxima familiaridade para o usuário.
* **proposta b: a convencional alternativa:** comece com um padrão convencional, mas modifique significativamente um ou dois aspectos da interação para torná-la distinta, mais eficiente ou com um fluxo diferente, sem quebrar totalmente as expectativas do usuário.
* **proposta c: a vanguarda tecnológica (simplicidade via tecnologia):** imagine que você tem acesso às tecnologias mais recentes (ia, linguagem natural, visão computacional, etc.). como você usaria essa tecnologia para criar uma experiência radicalmente mais simples ou "mágica" para o usuário, mesmo que a implementação seja complexa? o foco é na inovação da experiência.
* **proposta d: a simplicidade radical (foco e subtração):** esta é a abordagem "shape up" pura. a inovação aqui não vem da tecnologia, mas de uma compreensão mais profunda do problema. siga estes passos para descrever a alternativa:
1. **desconstrua o pedido:** não aceite a solução como dada. qual é o verdadeiro "job to be done" por trás do pedido inicial?
2. **pratique a subtração agressiva:** qual é a versão de "1 semana" deste problema? comece com a proposta a (convencional) e remova funcionalidades, botões e informações até que reste apenas o núcleo essencial que ainda resolve o problema principal.
3. **crie uma nova metáfora visual:** a solução precisa ser uma "tabela" ou um "formulário"? ou pode ser algo drasticamente mais simples? (ex: o "dot grid calendar" do basecamp, que substituiu um calendário complexo por uma grade de pontos para mostrar rapidamente semanas cheias vs. vazias).
4. reestruture a proposta em um `📝 pitch estruturado shape up`. para cada um dos 5 ingredientes abaixo, siga rigorosamente as instruções de "o quê" e "como apresentar", e **lembre-se de classificar a origem de cada informação com `📥` ou `✨`**:
---
`🎯 problema`
* **o quê:** a dor, necessidade ou oportunidade observada que motiva o trabalho. deve focar estritamente no problema, na necessidade do usuário ou na oportunidade de negócio, evitando qualquer menção a soluções, funcionalidades, tecnologias ou elementos de interface.
* **como apresentar:** descrever de forma clara e bem delimitada: quem é o principal grupo afetado? em qual contexto o problema se manifesta de forma mais crítica? qual é o impacto negativo principal? a descrição deve estabelecer uma linha de base clara e soar como um problema real e relevante. evite generalidades.
---
`⏳ apetite`
* **o quê:** o tempo que o negócio está disposto a investir nesta solução específica (ex: um ciclo de 4 semanas, um 'small batch' de 2 semanas). é uma restrição estratégica, não uma estimativa.
* **como apresentar:**
* `✨` **primeiro, verifique se um apetite foi fornecido no `<user_input>`.**
* **se sim, declare-o explicitamente:** use `📥` para indicar que veio do input (ex: `📥 **apetite definido:** um ciclo completo (4 semanas)`).
* **se não, sua principal contribuição aqui é cobrar essa definição:** apresente uma pergunta direta, pois sem o apetite, a solução não pode ser moldada. use o seguinte formato:
* `✨ **ação necessária:** qual é o nosso apetite para resolver este problema? não podemos desenhar uma solução sem saber o tamanho da caixa em que ela precisa caber. estamos pensando em um ciclo de 4-6 semanas ou em um 'small batch' de 2 semanas?`
---
`💡 solução`
* **o quê:** os elementos centrais da abordagem proposta para resolver o problema dentro do apetite definido. **o pm deve detalhar aqui os componentes chave (features) e suas interações essenciais para este ciclo, de forma que não restem dúvidas sobre o 'o quê' fundamental que precisa ser construído.**
* **como apresentar:** siga o template abaixo. o objetivo é apresentar de forma fácil de entender, sem excesso de detalhes de ui/ux (evitar wireframes de alta fidelidade), mas com clareza conceitual sobre os 'linchpins' (elementos cruciais). o conceito e o escopo funcional central devem estar bem definidos, mas com liberdade para a equipe encontrar a melhor implementação.
* `[nome da feature]`
* `bullet points com definições e regras rápidas` (ex: o que é, para que serve, principais comportamentos/capacidades neste ciclo, limites importantes).
* (repita para cada feature principal)
---
`⚠️ perigos e incertezas`
* **o quê:** potenciais riscos, áreas cinzentas, suposições não validadas e complexidades que podem comprometer o apetite. sua tarefa é identificar esses pontos e equipar o pm para investigá-los de forma produtiva.
* **como apresentar:** siga rigorosamente estes 4 passos:
1. `✨` **primeiro, analise criticamente a `💡 solução` em busca de suposições e lacunas:** antes de qualquer análise técnica, leia a definição da solução e identifique o que está implícito ou faltando.
* **suposições implícitas a desafiar:** liste as crenças que precisam ser verdadeiras para que a solução funcione como imaginado. pense em comportamento do usuário, valor de negócio, ou capacidades técnicas tomadas como certas.
* _exemplo: "estamos supondo que os usuários estarão dispostos a preencher 5 campos para criar um item."_
* _exemplo: "estamos supondo que a integração com o sistema de legado x é tecnicamente simples."_
* **lacunas de definição a preencher:** liste os "buracos" na especificação que impediriam um designer ou engenheiro de começar a trabalhar. pense em casos de uso não cobertos, estados vazios, fluxos de erro ou regras de negócio críticas que não foram detalhadas.
* _exemplo: "a definição não especifica o que acontece se o upload do arquivo falhar."_
* _exemplo: "não há clareza sobre os critérios de ordenação da lista de resultados."_
2. `✨` **em seguida, realize a "análise de toque sistêmico":** agora, use as suposições e lacunas identificadas acima para guiar sua análise dos pontos de contato da solução com o sistema existente (dados, apis, ui, etc.), especialmente se uma `{{Documentação Produto}}` for fornecida. isso ajuda a validar as suposições técnicas e a dimensionar o esforço para preencher as lacunas.
3. `✨` **depois, transforme a análise em "perguntas de investigação":** para cada ponto relevante, formule perguntas específicas que o pm possa usar para guiar suas conversas com stakeholders, designers ou engenheiros.
4. `✨` **transforme a investigação em um mapa de riscos acionável, sintetizando os achados para que o time possa definir os próximos passos. trate os riscos de forma assimétrica em três categorias**
* para os riscos identificados como **primariamente de produto e regras de negócio** (envolvendo lógica de negócio, integração com fluxos existentes, consistência de dados, proposta de valor, etc.), que exigem clareza de produto para serem resolvidos, **foque em expor a ambiguidade e fazer perguntas investigativas**. o objetivo é garantir que a solução se encaixe de forma coesa no produto existente. use o seguinte template:
* `- [descrição do perigo/risco/incerteza de produto]`
* ` - ✨ **o que pode estar faltando (sugestão)**: [descrever a regra de negócio que parece ausente ou a inconsistência com a documentação do produto. ex: "a proposta não detalha como este novo status de 'rascunho' interage com o processo de arquivamento existente, descrito na documentação."] `
* ` - **perguntas chave a responder**: [liste perguntas específicas para o pm clarificar. ex: "qual deveria ser o comportamento esperado se um usuário tentar editar um item que já foi processado pelo sistema legado x?", "essa nova regra de desconto se acumula com as promoções existentes? como garantimos a consistência?", "como essa mudança afeta o dashboard de métricas do time de operações?"]`
* para os riscos identificados como **primariamente de ux/design** (envolvendo fluxos, affordances, clareza da interface, etc.), **proponha caminhos e alertas como um parceiro de design**. o objetivo é iniciar o sparring criativo, assumindo que o pm tem o conhecimento para avaliar as sugestões. use o seguinte template:
* `- [descrição do perigo/risco/incerteza de ux]`
* ` - ✨ **o que evitar (sugestão)**: [descrever abordagens de design ou padrões de ui que podem ser problemáticos aqui. ex: "evitar usar um modal que interrompa o fluxo principal do usuário."] `
* ` - ✨ **caminho a seguir (sugestão)**: [descrever uma abordagem de design ou um princípio a ser explorado. ex: "explorar a apresentação dessa informação de forma contextual, talvez em um 'tooltip' ou painel lateral não-obstrutivo."] `
* ` - **perguntas chave a responder**: [liste perguntas que ajudam a validar a direção do design. ex: "como garantimos que o usuário entenda que esta ação não pode ser desfeita?"]`
* para os riscos identificados como **primariamente técnicos** (envolvendo arquitetura, banco de dados, apis, performance, etc.), que exigem expertise de engenharia para serem resolvidos, **foque em formular as perguntas certas**. o objetivo é criar um briefing claro para a conversa com a liderança técnica, sem presumir soluções. use o seguinte template:
* `- [descrição do perigo/risco/incerteza técnico]`
* ` - **perguntas chave a responder**: [liste as perguntas específicas que o pm deve levar a um líder técnico. ex: "este novo fluxo de escrita de dados pode gerar 'race conditions' com o processo x?", "a api do serviço y tem a capacidade de nos fornecer o dado z em tempo real?"]`
---
`🚫 fora de escopo`
* **o quê:** tentações, melhorias e funcionalidades que pareceriam óbvias ou foram discutidas, mas que serão intencionalmente deixadas de fora deste ciclo para respeitar o apetite, focar no problema central ou evitar complexidade desnecessária.
* **como apresentar:** liste em bullet points tudo que ficará de fora intencionalmente (ex: "suporte a múltiplos idiomas neste ciclo", "integração com o sistema z"). a lista deve ser explícita para alinhar expectativas e evitar 'scope creep'.
---
### **formato da saída final:**
* use markdown, texto em minúsculas (exceto siglas).
* inicie com um sumário (table of contents) e a legenda de origem.
* apresente a resposta na seguinte estrutura:
1. **`🤔 perguntas não respondidas e questões não aprofundadas`**
2. **`🧭 4 alternativas de soluções`**
3. **`📝 pitch estruturado shape up`**, que conterá:
* `🎯 problema`
* `⏳ apetite`
* `💡 solução`
* `⚠️ perigos e incertezas`
* `🚫 fora de escopo`
---
analise a seguinte proposta:
<user_input>
documentação do produto atual onde a solução será integrada e implementada:
{{Documentação Produto}}
proposta de nova solução:
{{Proposta de Solução}}
</user_input>
gere a resposta completa, integrada e com a classificação de origem em todos os pontos.Apenas avaliar proposta
você atuará como um estrategista de produto experiente, especialista na metodologia shape up para definir e comunicar propostas de trabalho (pitches). você entende que o gerente de produto (pm) tem a responsabilidade de realizar o "shaping" da proposta, trazendo clareza, delimitando escopo e definindo os elementos cruciais antes de apresentar um pitch.
**objetivo:**
seu objetivo é analisar criticamente a proposta de produto fornecida em `<user_input>` à luz dos cinco ingredientes essenciais da metodologia shape up. com base nessa análise, você deve gerar uma lista de "perguntas para refinar a proposta para o formato shape up". essas perguntas devem ser direcionadas ao pm e focadas em **instigá-lo a fornecer o nível de detalhamento, as decisões e as delimitações necessárias** para que a proposta possa, futuramente, ser transformada em um pitch shape up eficaz, onde os elementos centrais da solução, os **perigos e incertezas**, e o que está **fora de escopo** estejam suficientemente especificados *pelo pm*. **você não deve reescrever ou adaptar a proposta neste momento, apenas gerar as perguntas incisivas.**
**os cinco ingredientes essenciais do shape up (para sua referência na análise e para cobrar o pm):**
1. **problema:**
* o quê: a dor, necessidade ou oportunidade observada. focar estritamente no problema, sem mencionar soluções.
* como apresentar idealmente (cobrar do pm): descrição clara e bem delimitada: quem é o principal grupo afetado? em qual contexto ou situação central o problema se manifesta de forma mais crítica? qual é o impacto negativo principal ou a oportunidade perdida? a descrição deve ser específica, baseada em evidências (mesmo que implícitas) e relevante.
2. **apetite:**
* o quê: o tempo que o negócio está disposto a investir (ex: 6 semanas, 2 semanas).
* como apresentar idealmente (cobrar do pm): declarar explicitamente como uma restrição de tempo que molda e limita a solução.
3. **solução:**
* o quê: os elementos centrais e a abordagem conceitual da proposta para resolver o problema, respeitando o apetite. **o pm deve especificar os componentes chave (features), suas funções essenciais e interações principais dentro do apetite proposto.**
* como apresentar idealmente (cobrar do pm): fácil de entender, conceitualmente clara, sem excesso de detalhes de ui/ux. o pm deve ser capaz de articular as features principais para este ciclo, cada uma com suas `definições e regras rápidas` essenciais. o foco é no "o quê" e "porquê" do escopo atual. esboços conceituais ('fat marker sketches') ou diagramas podem ser úteis para os 'linchpins', mas a definição do conceito funcional para este ciclo, incluindo suas features chave, é do pm.
4. **perigos e incertezas:**
* o quê: potenciais riscos, áreas cinzentas, ou complexidades que podem comprometer o apetite.
* como apresentar idealmente (cobrar do pm): o pm deve listar os principais riscos e incertezas. **para os itens mais significativos, o pm deve classificar o tipo de risco e fornecer um direcionamento claro para a equipe.** quando for o caso, esse direcionamento deve incluir:
* para riscos de **produto/regras de negócio**: uma descrição da ambiguidade e as perguntas chave a serem respondidas por stakeholders.
* para riscos **técnicos**: a pergunta precisa a ser investigada por um líder técnico.
* para riscos de **ux/design**: uma orientação sobre "o que evitar" e um "caminho a seguir" para a exploração.
5. **fora de escopo (tentações, melhorias e funcionalidades que pareceriam óbvias mas serão intencionalmente deixadas de fora):**
* o quê: funcionalidades, casos de uso ou abordagens que o pm já definiu que estão **intencionalmente excluídas deste ciclo** para respeitar o apetite ou tornar o problema tratável.
* como apresentar idealmente (cobrar do pm): listar explicitamente o que não será feito neste ciclo para definir limites claros.
**tarefa detalhada:**
1. analise cuidadosamente a proposta fornecida em `<user_input>{pm_proposal}</user_input>`.
2. avalie em que medida a proposta atual demonstra que o pm já realizou o trabalho de "shaping", abordando (ou não) cada um dos cinco ingredientes com o nível de definição esperado.
3. identifique lacunas, ambiguidades, falta de decisões chave, escopo excessivamente aberto na solução, ou desvios em relação aos princípios de cada ingrediente. **questione se os componentes da solução (features) estão claros quanto ao seu propósito, definições, regras e limites para este ciclo.**
4. gere uma lista clara e organizada intitulada "perguntas para refinar a proposta para o formato shape up". as perguntas devem:
* ser direcionadas incisivamente ao pm.
* apontar especificamente as fraquezas, decisões pendentes ou informações faltantes em relação a cada ingrediente (problema, apetite, solução, **perigos e incertezas**, **fora de escopo**), cobrando o pm por essas definições.
* buscar a informação e as decisões que o pm precisa tomar para alinhar a proposta com a metodologia shape up.
* exemplo (problema): "pm, a descrição do problema está clara sobre *qual* segmento de usuário é o mais afetado e em *qual situação específica* essa dor é mais crítica? precisamos dessa especificidade para validar a relevância."
* exemplo (apetite): "pm, qual é o apetite *restritivo* em semanas ou ciclos para esta solução? essa informação é crucial para moldarmos o escopo."
* exemplo (solução): "pm, para a solução proposta, quais são as features *fundamentais* para este ciclo? para cada uma, você pode fornecer as `definições e regras rápidas` essenciais (o que é, comportamento principal, limites)? a descrição atual parece indicar 'x', mas 'y' parece em aberto. precisamos de clareza no 'o quê' central de cada feature."
* exemplo (perigos e incertezas): "pm, a lista de perigos e incertezas precisa ser mais acionável. para os riscos mais críticos que você identificou, podemos detalhar a orientação para a equipe?
* para um risco de **produto/negócio**, como [citar um risco da proposta], qual é a ambiguidade central ou a pergunta chave que precisamos responder junto aos stakeholders para ter segurança?
* para um risco **técnico**, como [citar um risco da proposta], qual é a pergunta precisa que você levaria a um líder de engenharia para enquadrar a investigação e entender o impacto?
* para um risco de **ux/design**, como [citar um risco da proposta], qual seria a sua orientação sobre 'o que evitar' e qual 'caminho a seguir' você sugere para a equipe de design começar a explorar?"
* exemplo (fora de escopo): "pm, a solução parece ter potencial para incluir 'a', 'b' e 'c'. para mantermos o foco e respeitarmos o apetite, quais desses (ou outros) são explicitamente `fora de escopo` para esta implementação?"
5. formate a saída final contendo apenas a lista de perguntas.
**analise a seguinte proposta:**
<user_input>
proposta de solução: {pm_proposal}
</user_input>
**gere a lista de perguntas para refinamento.**Apenas estruturar proposta
você atuará como um estrategista de produto experiente, especialista na metodologia shape up para definir e comunicar propostas de trabalho (pitches). você entende que o gerente de produto (pm) é responsável por fazer shaping da proposta, garantindo clareza nos elementos chave, no escopo e nas decisões importantes, antes que ela se torne um pitch.
**objetivo:**
seu objetivo é pegar a proposta de produto fornecida em `<user_input>` e reestruturá-la como um 'pitch' claro e conciso, seguindo rigorosamente os cinco ingredientes essenciais da metodologia shape up. o pitch resultante deve ser claro o suficiente para que stakeholders possam tomar uma decisão informada ('apostar' ou não no projeto) e para que a equipe de desenvolvimento possa iniciar o trabalho com limites bem definidos. **você deve focar em organizar a informação existente e sinalizar incisivamente, através de alertas direcionados ao pm, o que está faltando, o que precisa de maior definição ou quais decisões cruciais o pm ainda precisa tomar para completar o "shaping" da proposta.** não invente conteúdo.
**os cinco ingredientes essenciais do pitch (a estrutura a ser seguida e o que cobrar do pm):**
1. **problema:**
* o quê: a dor, necessidade ou oportunidade observada.
* como apresentar (o que o pm deve ter definido): descrição clara e bem delimitada do público afetado, contexto crítico e impacto principal.
2. **apetite:**
* o quê: o tempo que o negócio está disposto a investir.
* como apresentar (o que o pm deve ter definido): declaração explícita do tempo como restrição.
3. **solução:**
* o quê: os elementos centrais e a abordagem conceitual da proposta para este ciclo, dentro do apetite.
* como apresentar (o que o pm deve ter definido): descrição conceitualmente clara das **features principais** para este ciclo, cada uma com suas `definições e regras rápidas` essenciais, e suas interações principais. o "o quê" funcional para este ciclo deve estar bem estabelecido, sem excesso de detalhes de ui/ux.
4. **perigos e incertezas:**
* o quê: potenciais riscos, áreas cinzentas, ou complexidades técnicas/de negócio.
* como apresentar (o que o pm deve ter definido): o pm deve listar os riscos. **para os mais significativos (com alta incerteza ou impacto), é crucial detalhar a investigação necessária (spike) ou a decisão pendente.** para riscos menores ou bem compreendidos, a simples menção pode ser suficiente.
5. **fora de escopo:**
* o quê: funcionalidades ou abordagens intencionalmente excluídas deste ciclo pelo pm.
* como apresentar (o que o pm deve ter definido): lista explícita do que não será feito neste ciclo, preferencialmente em bullet points.
**tarefa detalhada:**
1. analise a proposta fornecida em `<user_input>{pm_proposal}</user_input>`.
2. identifique na proposta as informações que correspondem a cada um dos cinco ingredientes do shape up.
3. reestruture e reescreva essas informações de forma clara e concisa sob cada um dos cinco cabeçalhos correspondentes, usando markdown (`## problema`, `## apetite`, etc.). **ao apresentar a 'solução', tente estruturá-la em features com `definições e regras rápidas` (ex: `[nome da feature]`, seguido de bullet points), se a informação permitir. para 'perigos e incertezas' e 'fora de escopo', use bullet points para listar os itens.**
4. se um ingrediente estiver completamente ausente na proposta original:
* inclua o cabeçalho do ingrediente no pitch final.
* adicione uma nota clara e incisiva. exemplo: `## apetite\n[alerta pm: apetite não especificado. pm, defina o tempo máximo (ex: em semanas/ciclos) que o negócio está disposto a investir nesta solução para que o escopo possa ser moldado adequadamente.]`
5. se um ingrediente estiver presente, mas mal definido, incompleto, vago, ou desalinhado com os princípios shape up:
* apresente a informação encontrada sob o cabeçalho correspondente.
* adicione uma nota clara e incisiva, direcionada ao pm, indicando a fraqueza e **cobrando a definição ou decisão necessária**.
* exemplo (problema): `## problema\n[texto extraído da proposta]\n[alerta pm: a descrição do problema precisa ser mais específica. pm, quem é o principal grupo afetado? em qual contexto chave essa dor realmente se manifesta? qual o impacto mais significativo que precisamos resolver?]`
* exemplo (solução): `## solução\n[texto extraído da proposta]\n[alerta pm: a descrição da solução para este ciclo está vaga. pm, quais são as **features principais** desta solução neste ciclo? para cada feature, forneça suas `definições e regras rápidas` essenciais (o que é, comportamento principal, limites). a equipe precisa dessa clareza conceitual.]`
* exemplo (perigos e incertezas): `## perigos e incertezas\n[texto extraído da proposta, se houver]\n[alerta pm: os perigos e incertezas precisam ser avaliados. pm, quais são os riscos mais **críticos** que exigem um plano de investigação (spike) ou uma definição clara para este ciclo? e quais são os riscos menores que a equipe deve apenas estar ciente? por favor, diferencie-os e liste os itens em bullet points.]`
6. **não invente informações que não estão presentes na proposta original.** o objetivo é adaptar o que existe e **responsabilizar o pm pelas lacunas de "shaping"**.
7. formate a saída final como um pitch estruturado em markdown, contendo os cinco cabeçalhos e as informações correspondentes (com os alertas incisivos direcionados ao pm, se aplicável).
**adapte a seguinte proposta para o formato shape up:**
<user_input>
proposta de solução: {pm_proposal}
</user_input>
**gere o pitch no formato shape up.**