Formulário de feature request — capture problema, não só solução

Para quem é este modelo

Formulários de feature request são o formulário onde a maior parte dos times de produto acidentalmente limita o próprio pensamento. A versão típica pergunta "que feature você gostaria que a gente construísse?" e recebe de volta uma wishlist de feature específica que o usuário imaginou — muitas das quais não resolvem o problema subjacente quando examinadas de perto, algumas das quais resolvem um problema que já está resolvido por uma feature existente que o usuário não notou, e umas poucas resolvem um problema real mas de um jeito mais caro que alternativas. A versão certa inverte a pergunta e pergunta "qual problema você está tentando resolver?" primeiro, com a feature proposta do usuário como input secundário. O campo de framing-de-problema é o input de maior-alavancagem num formulário de feature-request porque deixa o time de produto pensar em múltiplas soluções incluindo as que o usuário não imaginou — e filtra as solicitações que são na verdade sobre um problema diferente. Três outros campos sub-investidos pela maior parte dos times: workaround atual (um usuário que construiu workaround pesado pra uma feature faltando tem tanto maior urgência quanto demanda validada mais forte que um usuário que só acha que seria legal), quem mais se beneficiaria (sinal de aplicabilidade ampla vs. especificidade de um-cliente), e disposição-a-pagar-extra pra B2B (uma feature pela qual cliente pagaria um tier adicional é diferente de uma feature que ele apreciaria mas não pagaria). Este modelo te dá essa estrutura mais integração direta com os public-feature-request boards que a maior parte dos times de produto já roda — Canny, Featurebase, Headway, Productboard portals, Sleekplan, GitHub Discussions pra projeto open-source, ou canal de Discord e Slack pra feedback liderado-por-comunidade. Use como a fonte upstream pras pesquisas estruturadas de priorização que vêm depois no ciclo de roadmap-planning.

De solicitação de usuário a entrada de backlog triagada em menos de 60 segundos

Um usuário encontra algo que ele gostaria que existisse no produto e dispara o formulário de feature-request (via link in-app de "solicitar uma feature," widget de suporte, public request board, ou página dedicada). O formulário leva ele através de quatro perguntas-chave: qual problema você está tentando resolver (o porquê), que feature ou capability resolveria (o como proposto pelo usuário), qual é seu workaround atual (o sinal de urgência e dor), e quem mais no seu time ou no seu papel se beneficiaria (o sinal de aplicabilidade ampla). Campos opcionais capturam urgência de prazo, disposição-a-pagar-extra pra B2B, e contato pra follow-up. Ao enviar, a solicitação flui pra ferramenta de feedback do time de produto — Canny, Featurebase, Headway, Productboard, Sleekplan, Productlift, ou um backlog do Linear / Notion / Airtable pra setup mais leve. O passo de deduplicação acontece nessa camada: uma nova solicitação é casada contra solicitações existentes no sistema, e se uma solicitação similar existe, o novo envio é linkado como um voto ou um comentário na entrada existente em vez de criar uma duplicata. Ferramentas de public-board (Canny, Featurebase, Headway, Productboard portals) lidam com esse casamento com busca voltada-pro-usuário antes do envio — o usuário vê a solicitação existente e consegue votar numa em vez de criar uma nova entrada. O time de produto então triaga as solicitações numa cadência regular (semanal ou quinzenal), agrupa em tema, e os temas de maior-sinal viram candidato pra próxima rodada de pesquisa estruturada de priorização.

O que está incluído

Cada campo abaixo está aqui porque time experiente de produto aprendeu que o que usuário articula como feature request é frequentemente mal-alinhado com o que ele realmente precisa. Os campos de framing-de-problema e workaround-atual são os dois que produzem o dado de maior-alavancagem; a descrição específica da feature é a hipótese-de-solução do usuário, não a ordem-de-marcha do time.

Feito pras categorias de produto onde volume de feature-request escala com usuário engajado

• B2B SaaS (o caso de uso primário)

  A categoria onde volume de feature-request escala mais diretamente com usuário engajado — um B2B SaaS com 10K cliente ativo pode facilmente gerar 50-200 feature request por mês em escala, e o desafio de deduplicação e clustering vira o problema operacional real. Notion, Linear, Figma, Stripe, Vercel, Datadog, PostHog, Snowflake, MongoDB Atlas, Anthropic, Asana, Slack, Zapier, ClickUp todos rodam board de feature-request. Os setups mais-maduros usam Canny, Featurebase, Headway, Productboard portals como a superfície voltada-pro-público onde solicitação pode ser votada, com a camada de triagem interna do time de produto (Linear, Jira, Notion, Productboard, Aha) conectada via webhook. O campo de disposição-a-pagar-extra é especialmente valioso pra B2B porque distingue solicitação de "apreciaria" de solicitação de "faria upgrade de tier." Pra B2B SaaS brasileiro (RD Station, Pipefy, Conta Azul, Bling, Omie, Movidesk, Octadesk, ContaWise), as categorias de feature-request específicas de locale (profundidade de integração Pix, caso edge de NFSe, especificidade de geração de Boleto, feature de gestão de Reclame Aqui) frequentemente dominam o volume — essas solicitações são tipicamente de alto-valor porque estão atreladas a conformidade fiscal brasileira e fluxo de receita.

• Ferramenta de dev (dev articula solicitação com precisão)

  Feature request de ferramenta-de-dev tende a ser mais tecnicamente específico que outra audiência. Dev solicita endpoint específico de API, suporte específico de framework, padrão específico de integração, e articula a solicitação com a precisão técnica que o time de produto consegue agir diretamente. O formulário pra ferramenta de dev pode ser mais leve no campo de framing-de-problema porque dev tipicamente se auto-enquadra o problema na solicitação, mas o campo de workaround-atual ainda é alto-sinal porque workaround de dev (middleware custom, hack de build-script, fork interno) revela dor real. GitHub Discussions é o destino canônico pra feature request de open-source dev-tool; pra ferramenta dev comercial, Canny, Featurebase, ou board de issue público do Linear são padrão. Pra ferramenta moderna de dev de IA (Cursor, Windsurf, Continue, Cline, Aider, Anthropic Claude Code, GitHub Copilot), feature request frequentemente cobre ajuste específico de comportamento de modelo, integração específica de ferramenta, e capability específica multi-passo de agente. Pra audiência brasileira de dev, GitHub Discussions é o padrão alongside as ferramentas globais.

• Produto consumidor (mais ruído, mais deduplicação exigida)

  Feature request de consumidor tem volume maior e mais ruído que B2B porque a audiência é mais ampla e a solicitação é mais diversa. O desafio de deduplicação e theme-clustering é mais pesado — um app consumidor com 1M de usuário ativo mensal pode receber 1.000+ feature request por mês e eles agrupam em menos tema distinto do que o volume bruto sugere. O formulário pra consumidor deveria enfatizar framing-de-problema fortemente porque usuário consumidor frequentemente solicita mudança específica de UI ("adicione um toggle de modo escuro aqui") quando o problema subjacente é mais amplo ("o default atual é duro pros meus olhos à noite") — e o framing mais amplo deixa o time de produto pensar em solução além da mudança específica de UI. Pra app consumidor brasileiro (Nubank, iFood, MercadoLivre, Mercado Pago, Magalu, PicPay, BTG digital), o mesmo padrão com o overlay de locale de que usuário brasileiro frequentemente solicita feature atrelada a integração de plataforma local (WhatsApp Business deep link, fluxo de QR-code Pix, opção de parcelamento, visibilidade de status do Reclame Aqui) que time de produto internacional sistematicamente perde.

• SaaS vertical (gap de feature específico-de-indústria)

  Feature request em SaaS vertical centra em gap específico-de-indústria que SaaS horizontal não endereça. Um SaaS de restaurante pode receber solicitação pra integração específica de PDV, feature específica de formatação de menu, integração específica de sistema de reserva; um SaaS de clínica pra integração de prontuário, padrão específico de documentação clínica, suporte específico de código de cobrança; um SaaS de construção pra integração específica de gestão de projeto, feature específica de takeoff, template específico de documento de conformidade. O formulário pra SaaS vertical deveria incluir campo de contexto-de-indústria (qual sub-indústria, qual tamanho de organização, qual ferramenta existente eles usam) porque esses segmentam o volume de solicitação utilmente. Pra SaaS vertical brasileiro, as integrações de plataforma específicas-de-locale são tipicamente as categorias de solicitação dominantes: âncoras de PDV (Stone POS, Linx, Sischef, Saipos), âncoras de prontuário (Tasy, MV, Memed, iClinic, Doctoralia), construção (Sienge, Builders 360, Construmanager).

• Produto de IA (solicitação de capability, solicitação de integração)

  Feature request de produto de IA é dividida entre solicitação de capability ("quero que o modelo lide com X melhor") e solicitação de integração ("quero essa IA na ferramenta Y"). O lado solicitação-de-capability é incomumente difícil porque usuário frequentemente solicita capability que não é atualmente possível com modelo disponível — o time tem que traduzir "deixe o modelo mais inteligente em tarefa X" em trabalho acionável de prompt-engineering, fine-tuning, ou nova-versão-de-modelo. O lado solicitação-de-integração é território mais convencional de product-management. O formulário pra produto de IA deveria capturar exemplo de contexto de prompt explicitamente ("aqui está um prompt específico onde eu queria X mas peguei Y") porque debugar comportamento de IA sem exemplo específico é impossível. Pra audiência brasileira de produto de IA, solicitação de capability específica-de-idioma é comum — "o modelo é pior em português que em inglês na tarefa X" é uma solicitação separável de "o modelo é ruim em tarefa X" e o time precisa dos dois sinais pra priorizar trabalho específico-de-idioma.

• Marketplaces (desejo de feature de comprador vs. vendedor)

  Marketplace de dois lados precisa capturar feature request dos dois lados separadamente porque a prioridade deles difere inteiramente. Vendedor de Etsy solicita ferramenta de listing, analytics, operação em lote, integração de envio; comprador de Etsy solicita feature de descoberta, refinamento de busca, sinal de confiança. Host de Airbnb solicita gestão de calendário, ferramenta de preço, automação de comunicação; hóspede de Airbnb solicita filtro de busca, flexibilidade de booking, gestão de reembolso. A estrutura do formulário deveria segmentar por papel de usuário no primeiro envio (vendedor vs. comprador pra marketplace de dois lados; host vs. hóspede; freelancer vs. cliente; inquilino vs. proprietário) e rotear as solicitações pra filas separadas de triagem porque o time de produto do lado-comprador e o time de produto do lado-vendedor são geralmente diferentes. Pra marketplace brasileiro (MercadoLivre, Magalu Marketplace, Americanas Marketplace, Shopee Brasil), o mesmo padrão dual aplica.

Ajuste o formulário pra capacidade de triagem do seu time e sua estratégia de public-board

Comece decidindo se sua feature request é pública ou privada. Board público (Canny, Featurebase, Headway, Productboard portal, Sleekplan, Productlift, GitHub Discussions pra open-source) aumenta deduplicação porque usuário consegue buscar solicitação existente e votar em vez de enviar duplicata; permite votação de comunidade que sinaliza qual solicitação tem demanda ampla; constrói engajamento de comunidade; mostra transparência que cliente valoriza. Intake privado roteia solicitação direto pras ferramentas internas do time de produto (Linear, Notion, Airtable, camada interna do Productboard) sem visibilidade pública — útil pra cliente enterprise com solicitação sensível, solicitação relacionada-a-segurança que não deveria ser pública, e direção de produto competitivamente-sensível. A maior parte de B2B SaaS pousa num híbrido: board público pra maior parte da solicitação com intake privado disponível pra solicitação enterprise e sensível. Personalize o conjunto de campos: lidere com framing-de-problema ("o que você está tentando fazer?") não com nome-de-feature ("que feature você quer?") porque o campo de framing-de-problema é o input de maior-alavancagem. Inclua workaround-atual como campo obrigatório. Pra B2B, inclua disposição-a-pagar-extra como campo opcional. Adicione contato pra follow-up. Pra produto multi-produto ou multi-área, inclua um seletor de área pra que solicitação roteie pra fila certa de triagem. Pra audiência B2B brasileira, inclua uma opção de categoria Pix/NFSe/Boleto/Reclame-Aqui porque essas integrações específicas-de-locale dominam o volume de solicitação no mercado brasileiro. Configure o processo de back-end de deduplicação e theme-clustering — essa é a parte que a maior parte dos times sub-investe, e determina se o volume de feature-request vira input acionável de roadmap ou só uma inbox que o time de produto se sente culpado por não responder. Traduza o formulário pros idiomas dos seus usuários.

Perguntas frequentes sobre formulário de feature request

Modelos relacionados