Plantilla de brief de producto para iniciar un proyecto

Brief de producto

Versión: ___________
Fecha: ___________
Responsable: ___________

1. El problema que se quiere resolver

¿Qué problema experimenta el usuario?

Describir el problema desde la perspectiva del usuario, no desde la perspectiva de la solución. ¿Qué está intentando hacer y qué le impide hacerlo bien?

¿Para quién es este problema?

Segmento de usuario específico. Cuanto más concreto, mejor. Incluir características relevantes: tipo de empresa, rol, contexto de uso, nivel de experiencia técnica.

¿Con qué frecuencia ocurre y con qué impacto?

Cuantificar si es posible: número de usuarios afectados, frecuencia del problema, coste estimado del problema no resuelto.

¿Qué evidencia tenemos de que este problema existe?

Datos cuantitativos, entrevistas, tickets de soporte, observación directa. Ser explícito sobre la fuente y el nivel de confianza.

2. El contexto de negocio

¿Por qué resolver esto ahora?

¿Qué ha cambiado que hace que este problema sea prioritario en este momento? ¿Hay una ventana de oportunidad, un cambio regulatorio, una señal de mercado?

¿Cómo conecta con los objetivos actuales del producto/negocio?

Enlace explícito con OKRs u objetivos del período.

¿Qué métrica mejorará si resolvemos bien este problema?

La métrica tiene que ser específica, medible y atribuible al trabajo que se va a hacer.

3. Las restricciones conocidas

Restricciones técnicas:

¿Hay limitaciones en la arquitectura actual que afecten a las soluciones posibles?

Restricciones de tiempo:

¿Hay una fecha que no se puede mover? ¿Por qué?

Restricciones de recursos:

¿Qué capacidad de equipo está disponible?

Restricciones regulatorias o de negocio:

¿Hay normativas, compromisos contractuales o políticas internas que limiten las opciones?

4. Lo que NO es el alcance de este proyecto

Ser explícito sobre qué problemas relacionados NO vamos a resolver en este proyecto. Esto previene el scope creep y alinea las expectativas desde el inicio.

5. Hipótesis de solución (opcional en esta fase)

Si ya hay una hipótesis de solución, documentarla aquí como hipótesis, no como decisión. El brief no es el lugar para definir la solución, pero sí para capturar las ideas iniciales que se van a explorar en el discovery.

6. Criterios de éxito

¿Cómo sabremos que hemos resuelto el problema?

Métricas concretas con valores objetivo y horizonte temporal.

¿Qué tendría que ser verdad para considerar este proyecto exitoso?

Articular las condiciones de éxito más allá de las métricas principales.

7. Próximos pasos de discovery

¿Qué necesitamos aprender antes de comprometer recursos en desarrollo? ¿Qué métodos de research son más adecuados dado el tiempo disponible?

8. Stakeholders y decisiones

Stakeholder	Rol en el proyecto	Qué necesita de este proyecto

¿Quién tiene la decisión final sobre el alcance?

¿Quién necesita ser informado de los avances?

Aprobado por: ___________ Fecha: ___________