← Todos los artículos
Construir lo correcto
Cómo escribir un brief de producto de una página que se use de verdad
Por el equipo de FabricLoop · Mayo 2026 · 4 minutos de lectura
La mayoría de los briefs de producto comparten el mismo destino: se escriben con cuidado antes de empezar un proyecto, se revisan una vez en la reunión de arranque y no se vuelven a abrir. Cuando el equipo está a mitad del desarrollo, el brief es un artefacto histórico: se cita de vez en cuando en las discusiones sobre el alcance, pero rara vez se trata como una guía viva para la toma de decisiones.
Es un fallo de proceso, no de formato. El brief no se usa porque no se escribió para usarse. Se escribió para cumplir un trámite —marcar la casilla de «hemos definido los requisitos»—, no para ayudar de verdad al equipo a tomar mejores decisiones en la incertidumbre.
Un brief que se usa es corto, tiene opinión propia y se estructura en torno a las preguntas que el equipo se hará de verdad a mitad del desarrollo: ¿qué estamos resolviendo, para quién y cómo sabremos si ha funcionado?
"Un brief no es un documento de requisitos. Es una referencia para tomar decisiones: una sola página a la que el equipo puede volver siempre que no esté seguro de si una decisión de diseño o de alcance es la correcta."
Las cinco secciones que importan
Todo lo que aparece en un brief de producto debería responder a una de cinco preguntas. Si una sección no responde a ninguna de ellas, probablemente no pertenece a un brief de una página: pertenece a una especificación aparte y más detallada.
Problema
Los usuarios se están perdiendo actualizaciones importantes porque no distinguen entre notificaciones de alta señal (alguien les ha asignado una tarea) y de baja señal (un comentario en un hilo que siguen). El resultado: ignoran todas las notificaciones o las desactivan por completo. Los tickets de soporte del tipo «no me enteré» suponen el 18 % de todas las quejas sobre el producto este trimestre.
Usuarios
Principal: responsables de equipo y de proyecto a quienes mencionan con frecuencia y que no pueden con el volumen. Secundario: colaboradores individuales que quieren silencio por defecto, pero necesitan no perderse las asignaciones críticas. No nos dirigimos a los administradores: sus necesidades de notificación se cubren desde el panel de administración.
Métrica de éxito
Principal Los tickets de soporte relacionados con notificaciones disminuyen un 40% dentro de 60 días del lanzamiento.
Secundaria Los usuarios activos semanales que han personalizado preferencias aumentan del 12% al 35%.
Indicador principal La tasa de exclusión (usuarios que desactivan todas las notificaciones) disminuye del 23% a menos del 15%.
Fuera de alcance
- Preferencias de notificación por correo (tarea aparte: infraestructura distinta)
- Ajustes de notificación por espacio de trabajo (a futuro; esta versión es solo por usuario)
- Programación de notificaciones / horas de «no molestar» (necesidad validada, hoja de ruta del T3)
- Granularidad de las notificaciones push en móvil (primero web; el móvil vendrá después si se valida)
Preguntas abiertas
Bloqueante ¿Agrupamos notificaciones en 2 niveles (crítico / todo lo demás) o permitimos control granular por tipo? Las entrevistas de usuario sugieren 2 niveles, pero ingeniería prefiere granular por flexibilidad. Se necesita decisión antes de que el diseño comience.
No bloqueante ¿Deberían aplicarse cambios de preferencia retroactivamente a notificaciones existentes? Puedo decidir durante la construcción basado en costo técnico.
Por qué «fuera de alcance» es la sección más importante
Los equipos dedican mucho tiempo a escribir lo que van a construir y muy poco a escribir lo que no van a construir, y esta asimetría provoca la mayor parte de las desviaciones de alcance (scope creep). Cuando el diseñador añade un interruptor de «horas de silencio» porque parece obvio, o el ingeniero añade ajustes por espacio de trabajo porque ya está en esa zona, normalmente es porque nadie decidió de forma explícita que quedaba fuera del alcance.
Escribir los elementos fuera de alcance obliga a tener una conversación sobre los límites que, de lo contrario, ocurriría a mitad del desarrollo, cuando cambiar de rumbo cuesta mucho más. También da al PM una base clara y documentada para decir que no a las ampliaciones: «Decidimos que eso quedaba fuera del alcance en el brief; este es el motivo».
Cómo escribir buenos elementos fuera de alcance
No te limites a enumerar lo que no vas a construir: indica brevemente por qué. «Preferencias de correo (infraestructura distinta)» le dice al lector que la decisión fue deliberada y razonada, no un descuido. Así evitas que la misma duda de alcance reaparezca tres veces durante el sprint.
Preguntas abiertas: la sección que omiten la mayoría de los briefs
Todo proyecto empieza con preguntas sin resolver. La mayoría de los briefs finge lo contrario: se escriben como si ya se hubieran tomado todas las decisiones, aunque quien los redacta sepa que no es así. El resultado es que los equipos descubren las preguntas abiertas a mitad del desarrollo, cuando más perjudican.
Enumerar de forma explícita las preguntas abiertas sirve para dos cosas. Primero, distingue las que hay que resolver antes de empezar a trabajar (bloqueantes) de las que pueden decidirse durante el desarrollo (no bloqueantes). Segundo, indica al equipo que el brief es un documento de trabajo, no una especificación cerrada, lo que aumenta la probabilidad de que vuelvan a él y lo actualicen a medida que se toman decisiones.
La trampa de la extensión
Un brief que crece más allá de una página deja de ser un brief: es una especificación. Las especificaciones tienen su lugar, pero sirven para otra cosa. Si necesitas más de una página, pasa el detalle a un anexo enlazado y deja el brief en las cinco secciones básicas.
Cómo mantiene FabricLoop vivo el brief
Un brief solo sigue siendo útil si el equipo puede encontrarlo y actualizarlo. FabricLoop fija el brief en el hilo del proyecto para que esté siempre a un clic, y la conversación que lo rodea (decisiones tomadas, preguntas abiertas resueltas, cambios de alcance) está ahí mismo, en contexto, en lugar de dispersa entre el correo y Slack.
10 ideas para llevarse de este artículo
- La mayoría de los briefs de producto se escriben para cumplir un trámite, no para ayudar a los equipos a tomar mejores decisiones. Por eso no se vuelven a usar.
- Un brief es una referencia para tomar decisiones, no un documento de requisitos. Debe responder a las preguntas que surgen a mitad del desarrollo.
- Las cinco secciones que importan: problema, usuarios, métrica de éxito, fuera de alcance y preguntas abiertas. Todo lo demás es especificación.
- La sección de problema debe describir con concreción el dolor del usuario, con datos siempre que sea posible, y no limitarse a nombrar el área que se aborda.
- Nombrar a quién no te diriges es tan importante como nombrar a quién sí. La ambigüedad sobre los usuarios provoca desviaciones de alcance en el diseño.
- Las métricas de éxito deben ser medibles, tener un plazo definido y acordarse antes de empezar el desarrollo, no deducirse a posteriori de los datos de uso.
- La sección de fuera de alcance es la más importante. Los límites de alcance que no se escriben se expanden, invariablemente, durante el desarrollo.
- Acompaña los elementos fuera de alcance de un breve motivo para evitar que las mismas preguntas reaparezcan durante el sprint.
- Las preguntas abiertas deben etiquetarse de forma explícita como bloqueantes (decidir antes del desarrollo) o no bloqueantes (decidir durante el desarrollo).
- Un brief que supera una página se ha convertido en una especificación. Pasa el detalle a un anexo y mantén el brief conciso.
