Formulario de feature request — captura problemas, no solo soluciones

Para quién es esta plantilla

Los formularios de feature request son el formulario donde la mayoría de equipos de producto accidentalmente limitan su propio pensamiento. La versión típica pregunta "¿qué feature te gustaría que construyamos?" y recibe de vuelta una wishlist de features específicas que los usuarios han imaginado — muchas de las cuales no realmente resuelven su problema subyacente cuando se examinan de cerca, algunas de las cuales resuelven un problema que ya está resuelto por una feature existente que el usuario no notó, y unas pocas resuelven un problema real pero de una forma más cara que las alternativas. La versión correcta invierte la pregunta y pregunta "¿qué problema estás intentando resolver?" primero, con la feature propuesta del usuario como input secundario. El campo de framing-de-problema es el input de mayor-leverage en un formulario de feature-request porque deja al equipo de producto pensar en múltiples soluciones incluyendo las que el usuario no imaginó — y filtra las solicitudes que son en realidad sobre un problema diferente del todo. Tres campos adicionales sub-invertidos por la mayoría de equipos: workaround actual (un usuario que ha construido un workaround pesado para una feature faltante tiene tanto mayor urgencia como demanda validada más fuerte que un usuario que solo piensa que sería agradable), quién más se beneficiaría (señal en aplicabilidad amplia vs. especificidad de un-cliente), y disposición-a-pagar-extra para B2B (una feature por la que los clientes pagarían un tier adicional es distinta de una feature que apreciarían pero por la que no pagarían). Esta plantilla te da esa estructura más integración directa con los public-feature-request boards que la mayoría de equipos de producto ya corren — Canny, Featurebase, Headway, Productboard portals, Sleekplan, GitHub Discussions para proyectos open-source, o canales de Discord y Slack para feedback liderado-por-comunidad. Úsala como la fuente upstream para las encuestas estructuradas de priorización que vienen después en el ciclo de roadmap-planning.

De solicitud de usuario a entrada de backlog triajada en menos de 60 segundos

Un usuario encuentra algo que desearía que existiera en el producto y dispara el formulario de feature-request (vía enlace in-app de "solicitar una feature," widget de soporte, public request board, o página dedicada). El formulario los lleva a través de cuatro preguntas clave: qué problema estás intentando resolver (el por qué), qué feature o capability lo resolvería (el cómo propuesto del usuario), cuál es tu workaround actual (la señal de urgencia y dolor), y quién más en tu equipo o en tu rol se beneficiaría (la señal de aplicabilidad amplia). Campos opcionales capturan urgencia de timeline, disposición-a-pagar-extra para B2B, y contacto para follow-up. Al enviar, la solicitud fluye a la herramienta de feedback del equipo de producto — Canny, Featurebase, Headway, Productboard, Sleekplan, Productlift, o un backlog de Linear / Notion / Airtable para setups más ligeros. El paso de deduplicación ocurre en esta capa: una nueva solicitud se empareja contra solicitudes existentes en el sistema, y si una solicitud similar existe, el nuevo envío se enlaza como un voto o un comentario en la entrada existente en vez de crear un duplicado. Las herramientas de public-board (Canny, Featurebase, Headway, Productboard portals) manejan este matching con búsqueda dirigida al usuario antes del envío — el usuario ve las solicitudes existentes y puede votar por una en vez de crear una nueva entrada. El equipo de producto luego triaja las solicitudes en una cadencia regular (semanal o bi-semanal), las agrupa en temas, y los temas de mayor-señal se vuelven candidatos para la siguiente ronda de encuestas estructuradas de priorización.

Qué incluye

Cada campo abajo está aquí porque los equipos experimentados de producto han aprendido que lo que los usuarios articulan como feature requests está a menudo mal alineado con lo que realmente necesitan. Los campos de framing-de-problema y workaround-actual son los dos que producen los datos de mayor-leverage; la descripción específica de feature es la hipótesis-de-solución del usuario, no la orden-de-marcha del equipo.

Pensada para las categorías de producto donde el volumen de feature-request escala con usuarios engaged

• B2B SaaS (el caso de uso principal)

  La categoría donde el volumen de feature-request escala más directamente con usuarios engaged — un B2B SaaS con 10K clientes activos puede fácilmente generar 50-200 feature requests por mes a escala, y el desafío de deduplicación y clustering se vuelve el problema operativo real. Notion, Linear, Figma, Stripe, Vercel, Datadog, PostHog, Snowflake, MongoDB Atlas, Anthropic, Asana, Slack, Zapier, ClickUp todos corren boards de feature-request. Los setups más-maduros usan Canny, Featurebase, Headway, Productboard portals como la superficie dirigida-al-público donde las solicitudes pueden votarse, con la capa de triaje interno del equipo de producto (Linear, Jira, Notion, Productboard, Aha) conectada vía webhook. El campo de disposición-a-pagar-extra es especialmente valioso para B2B porque distingue solicitudes de "apreciaría" de solicitudes de "actualizaría tier." Para B2B SaaS español e iberoamericano (Holded, Quipu, Anfix, TravelPerk, Factorial HR, Sumup España), las categorías de feature-request específicas de locale (profundidad de integración Bizum, casos edge de Verifactu, especificidades de generación de factura electrónica española, features de gestión de OCU para B2C) a menudo dominan el volumen — estas solicitudes son típicamente de alto-valor porque están atadas al cumplimiento fiscal español y al flujo de revenue.

• Herramientas de desarrollador (devs articulan solicitudes con precisión)

  Los feature requests de herramientas-de-desarrollador tienden a ser más técnicamente específicos que otras audiencias. Los devs solicitan endpoints específicos de API, soporte específico de framework, patrones específicos de integración, y articulan las solicitudes con la precisión técnica que el equipo de producto puede actuar directamente. El formulario para herramientas de dev puede ser más ligero en el campo de framing-de-problema porque los devs típicamente se auto-enmarcan el problema en la solicitud, pero el campo de workaround-actual sigue siendo de alta-señal porque los workarounds de desarrollador (middleware custom, hacks de build-script, forks internos) revelan dolor real. GitHub Discussions es el destino canónico para feature requests de open-source dev-tool; para herramientas dev comerciales, Canny, Featurebase, o boards de issues públicos de Linear son estándar. Para herramientas modernas de desarrollador IA (Cursor, Windsurf, Continue, Cline, Aider, Anthropic Claude Code, GitHub Copilot), las feature requests a menudo cubren ajuste específico de comportamiento de modelo, integraciones específicas de herramienta, y capacidades específicas multi-paso de agente.

• Productos consumidor (más ruido, más deduplicación requerida)

  Las feature requests consumidor tienen mayor volumen y más ruido que B2B porque la audiencia es más amplia y las solicitudes son más diversas. El desafío de deduplicación y theme-clustering es más pesado — una app consumidor con 1M de usuarios activos mensuales puede recibir 1,000+ feature requests por mes y se agrupan en menos temas distintos de lo que el volumen crudo sugiere. El formulario para consumidor debería enfatizar el framing-de-problema fuertemente porque los usuarios consumidor a menudo solicitan cambios específicos de UI ("añade un toggle de modo oscuro aquí") cuando el problema subyacente es más amplio ("el default actual es duro para mis ojos de noche") — y el framing más amplio deja al equipo de producto pensar en soluciones más allá del cambio específico de UI. Para apps consumidor españolas e iberoamericanas (BBVA, CaixaBank, Bizum como capa de pago, Glovo en su lado consumidor, MyRealFood, Coverflex), el mismo patrón con el overlay de locale de que los usuarios hispanohablantes a menudo solicitan features atadas a integraciones de plataforma local (Bizum deep-links, SEPA workflows, MercadoPago para LatAm).

• SaaS vertical (gaps de feature específicos-de-industria)

  Las feature requests en SaaS vertical centran en gaps específicos-de-industria que SaaS horizontal no aborda. Un SaaS restaurante podría recibir solicitudes para integraciones específicas de POS, features específicas de formateo de menú, integraciones específicas de sistema de reservas; un SaaS clínica para integraciones EHR, patrones específicos de documentación clínica, soporte específico de código de facturación; un SaaS construcción para integraciones específicas de gestión de proyecto, features específicas de takeoff, plantillas específicas de documento de cumplimiento. El formulario para SaaS vertical debería incluir campos de contexto-de-industria (qué sub-industria, qué tamaño de organización, qué herramientas existentes usan) porque estos segmentan el volumen de solicitud útilmente. Para SaaS vertical español, las integraciones de plataforma específicas-de-locale son típicamente las categorías de solicitud dominantes: anclajes TPV (Lightspeed, Hiopos, ICG), anclajes HCE (Doctoralia, Clinic Cloud, Spa+), construcción (PlanRadar, Sinco Soft, Presto).

• Productos IA (solicitudes de capacidad, solicitudes de integración)

  Las feature requests de producto IA están divididas entre solicitudes de capacidad ("quiero que el modelo maneje X mejor") y solicitudes de integración ("quiero esta IA en herramienta Y"). El lado solicitud-de-capacidad es inusualmente difícil porque los usuarios a menudo solicitan capacidades que no son actualmente posibles con los modelos disponibles — el equipo tiene que traducir "haz al modelo más inteligente en tarea X" en trabajo accionable de prompt-engineering, fine-tuning, o nueva-versión-de-modelo. El lado solicitud-de-integración es territorio más convencional de gestión de producto. El formulario para productos IA debería capturar explícitamente ejemplos de contexto de prompt porque debuggear comportamiento de IA sin ejemplos específicos es imposible. Para audiencias hispanohablantes de productos IA, las solicitudes de capability específicas-de-idioma son comunes — "el modelo es peor en español que en inglés en tarea X" es una solicitud separable de "el modelo es malo en tarea X" y el equipo necesita ambas señales para priorizar trabajo específico-de-idioma.

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

  Los marketplaces de dos lados necesitan capturar feature requests de ambos lados separadamente porque las prioridades difieren enteramente. Los vendedores de Etsy solicitan herramientas de listing, analytics, operaciones por lote, integraciones de envío; los compradores de Etsy solicitan features de descubrimiento, refinamiento de búsqueda, señales de confianza. Los hosts de Airbnb solicitan gestión de calendario, herramientas de pricing, automatización de comunicación; los huéspedes de Airbnb solicitan filtros de búsqueda, flexibilidad de booking, manejo de reembolso. La estructura del formulario debería segmentar por rol de usuario en el primer envío (vendedor vs. comprador para marketplaces de dos lados; host vs. huésped; freelancer vs. cliente; inquilino vs. propietario) y enrutar las solicitudes a colas separadas de triaje porque el equipo de producto del lado-comprador y el equipo de producto del lado-vendedor son usualmente diferentes. Para marketplaces españoles (Wallapop, Vinted, Joom, marketplaces ibéricos regionales), el mismo patrón aplica.

Ajusta el formulario a la capacidad de triaje de tu equipo y tu estrategia de public-board

Empieza decidiendo si tus feature requests son públicas o privadas. Los boards públicos (Canny, Featurebase, Headway, Productboard portals, Sleekplan, Productlift, GitHub Discussions para open-source) aumentan deduplicación porque los usuarios pueden buscar solicitudes existentes y votar en vez de enviar duplicados; permiten votación de comunidad que señala qué solicitudes tienen demanda amplia; construyen engagement de comunidad; muestran transparencia que los clientes valoran. El intake privado enruta solicitudes directamente a herramientas internas del equipo de producto (Linear, Notion, Airtable, capa interna de Productboard) sin visibilidad pública — útil para clientes enterprise con solicitudes sensibles, solicitudes relacionadas-a-seguridad que no deberían ser públicas, y direcciones de producto competitivamente-sensibles. La mayoría de B2B SaaS aterriza en un híbrido: board público para la mayoría de solicitudes con intake privado disponible para enterprise y solicitudes sensibles. Personaliza el set de campos: lidera con framing-de-problema ("¿qué intentas hacer?") no con nombre-de-feature ("¿qué feature quieres?") porque el campo de framing-de-problema es el input de mayor-leverage. Incluye workaround-actual como campo requerido. Para B2B, incluye disposición-a-pagar-extra como campo opcional. Añade contacto para follow-up. Para productos multi-producto o multi-área, incluye un selector de área para que las solicitudes enruten a la cola correcta de triaje. Para audiencias B2B españolas e iberoamericanas, incluye una opción de categoría Bizum/Verifactu/Confianza-Online porque estas integraciones específicas-de-locale dominan el volumen de solicitud en el mercado español. Configura el proceso de back-end de deduplicación y theme-clustering. Traduce el formulario a los idiomas de tus usuarios.

Preguntas frecuentes sobre el formulario de feature request

Plantillas relacionadas