La anatomía de un Problem Statement completo
El Problem Statement no supera la media página. Esa restricción es deliberada. La brevedad obliga a la precisión. Un Problem Statement largo es un Problem Statement que no ha terminado de ser pensado.
Pero brevedad no es simplicidad. Un buen Problem Statement es un documento denso que integra múltiples dimensiones del problema en un espacio reducido. Para lograrlo, hemos identificado siete elementos que, cuando están presentes, producen una definición del problema que es completa, accionable y resistente a la ambigüedad.
Los siete elementos de un Problem Statement
| # | Elemento | Qué describe | Pregunta clave | Ejemplo |
|---|---|---|---|---|
| 1 | La brecha | La distancia entre lo que ocurre y lo que debería ocurrir. No el síntoma, sino la brecha real. | ¿Qué está mal? ¿Qué diferencia hay entre la situación actual y la deseada? | "Los gerentes descubren las roturas de stock cuando el cliente pregunta, no antes." |
| 2 | El dueño | Quién vive el problema y quién tiene la capacidad de decidir que se resuelva. A veces son la misma persona; a menudo no lo son. | ¿Quién sufre las consecuencias? ¿Quién puede autorizar la solución? | "Lo viven los gerentes de tienda. Lo decide el director de operaciones." |
| 3 | El criterio de éxito | Cómo se verá el mundo cuando el problema esté resuelto. No en términos de solución, sino de resultado observable y medible. | ¿Cómo sabremos que el problema se resolvió? | "Los gerentes anticipan roturas al menos 24h antes de que ocurran." |
| 4 | Las restricciones | Las barreras reales que limitan el espacio de soluciones: presupuesto, tiempo, regulaciones, tecnología heredada, política organizacional. | ¿Qué no podemos cambiar? ¿Qué limita lo que es posible? | "ERP se actualiza en batch diario; su sustitución no es viable en 12 meses." |
| 5 | Los actores | Todos los stakeholders que pueden influir en la solución o verse afectados por ella, más allá de quien vive el problema directamente. | ¿Quiénes pueden bloquear, potenciar o verse impactados? | "Compras, almacén, IT, atención al cliente, proveedores." |
| 6 | El contexto temporal | Cuándo ocurre, con qué frecuencia y qué patrones temporales tiene el problema. | ¿Cuándo aparece? ¿Es constante o tiene triggers? | "Diariamente en temporada alta; semanalmente en temporada baja." |
| 7 | El coste de la inacción | El impacto cuantificado de no resolver el problema, expresado en términos que el dueño de la decisión entienda. | ¿Qué se pierde cada día/semana/mes que esto no se resuelve? | "12% de ventas perdidas + 45 min/día × 120 tiendas." |
Los tres primeros elementos (la brecha, el dueño y el criterio de éxito) son el corazón del Problem Statement. Sin ellos, no tienes una definición del problema; tienes una descripción vaga de un malestar. Los cuatro restantes (restricciones, actores, contexto temporal y coste de la inacción) son los que convierten esa definición en algo accionable, completo y resistente a la interpretación.
¿Por qué el criterio de éxito se define aquí y no en la fase de solución? Porque el criterio de éxito pertenece al problema, no a la solución. Si no defines cómo se ve "resuelto" antes de pensar en soluciones, cada stakeholder tendrá una definición distinta y no lo descubrirás hasta que sea demasiado tarde. Definir el éxito aquí es un acto de alineación preventiva que ahorra conflictos enormes más adelante.
Ejemplo completo de un Problem Statement
La brecha: Los gerentes de tienda de la cadena (120 puntos de venta) descubren las roturas de stock cuando el cliente pregunta por un producto que no está disponible, no antes. El sistema de inventario central se actualiza cada 24 horas, lo que significa que todas las decisiones de reposición se basan en datos del día anterior.
Quién lo vive / Quién decide: Lo viven diariamente los gerentes de tienda, responsables de 40-80 SKUs por punto de venta. La decisión de inversión en una solución corresponde al director de operaciones retail.
Criterio de éxito: Los gerentes pueden anticipar una rotura de stock al menos 24 horas antes de que se produzca y actuar preventivamente. La tasa de "descubrimiento por cliente" se reduce del 100% actual a menos del 15%.
Contexto: Ocurre diariamente en temporada alta, cuando la velocidad de rotación de algunos SKUs supera la frecuencia de actualización del sistema. En temporada baja, la frecuencia se reduce a semanal. Los gerentes han desarrollado workarounds manuales (hojas de cálculo propias, llamadas a almacén, recuentos físicos) que consumen un promedio de 45 minutos diarios y no son fiables.
Restricciones: El ERP central (SAP) se actualiza en batch diario y su sustitución no está prevista en los próximos 18 meses. Presupuesto de integración limitado a 150K€. Regulación de stock mínimo en productos sanitarios y alimentarios.
Actores clave: Equipo de compras (decisiones de reposición basadas en datos desactualizados), responsables de almacén (reciben pedidos que no reflejan la demanda real), equipo de IT (mantiene las integraciones), atención al cliente (gestiona quejas de clientes por falta de stock), proveedores de reposición frecuente.
Coste de la inacción: 12% de ventas perdidas por falta de stock en el momento de la demanda. 45 minutos diarios de trabajo manual por gerente × 120 tiendas = 90 horas/día de productividad perdida. Erosión de confianza del cliente por experiencias recurrentes de "no disponible".
La validación: dos niveles que casi nadie completa
Un Problem Statement no está completo hasta que ha sido validado. Pero la validación tiene dos niveles que la mayoría de los equipos no distinguen.
Nivel 1: Validación con quien vive el problema. Se presenta el Problem Statement a al menos dos de los clientes o usuarios entrevistados. La pregunta es directa: "Hemos escrito esto como resumen de lo que entendemos que es el problema. ¿Lo reconoces? ¿Falta algo? ¿Hay algo que no es correcto?" Si la persona lo lee y dice "sí, esto es exactamente lo que pasa", la brecha y el contexto están validados. Si dice "bueno, más o menos, pero falta..." hay que iterar. Sin excepciones.
Nivel 2: Validación con el dueño de la decisión. El usuario que vive el problema valida la brecha y el contexto. El dueño de la decisión valida el criterio de éxito, las restricciones y el coste de la inacción. Ambas validaciones son necesarias. Si el usuario reconoce el problema pero el decisor no reconoce su coste, no habrá solución. Si el decisor reconoce el coste pero el usuario no reconoce la brecha, la solución no resolverá lo correcto.
Un Problem Statement que usa lenguaje interno de la organización, jerga técnica o conceptos abstractos que el usuario no reconoce. Si le lees tu Problem Statement a la persona que vive el problema y necesitas explicarle lo que significa, está mal escrito.
Cómo detectarlo: Lee el Problem Statement en voz alta a alguien que no participó en el discovery. Si necesitas añadir explicaciones para que lo entienda, el documento usa jerga interna en lugar de lenguaje universal.
Cómo prevenirlo: Aplica el test de la persona externa: ¿alguien ajeno a la organización, sin contexto previo, entendería el problema al leer este documento? Si la respuesta es no, simplifica. Cada término técnico o acrónimo es una barrera que reduce la utilidad del Problem Statement como herramienta de alineación.