problem-statement

Resumen del problema del skill problem-statement

El skill problem-statement te ayuda a convertir una petición de producto difusa en una declaración de problema centrada en el usuario, que explica quién está bloqueado, qué intenta hacer, por qué importa y cómo se siente. Es especialmente útil cuando necesitas alineación antes de proponer soluciones: discovery, priorización, PRDs y revisiones con stakeholders.

Para qué sirve problem-statement

Este skill problem-statement está pensado para el encuadre del problema, no para diseñar funcionalidades. Te ayuda a describir el problema desde la perspectiva del usuario para que los equipos puedan decidir si el trabajo merece la pena antes de debatir la implementación.

Para quién encaja mejor

Usa este skill si redactas briefs de producto, especificaciones técnicas, resúmenes de investigación o notas de roadmap y necesitas una narrativa del problema más clara. Encaja muy bien en flujos de Technical Writing cuando tienes que transformar una entrada desordenada en una declaración breve, empática y precisa.

Qué lo hace distinto

El skill pone el foco en el marco de formulación del problema: I am, Trying to, But, Because, y Which makes me feel, además del contexto y las restricciones. Esa estructura es más útil para tomar decisiones que un prompt genérico, porque obliga a capturar tanto el bloqueo funcional como el impacto humano.

Cómo usar el skill problem-statement

Instala e inspecciona el skill

Instálalo con:

npx skills add deanpeters/Product-Manager-Skills --skill problem-statement

Después, lee primero skills/problem-statement/SKILL.md, seguido de template.md y examples/sample.md. Es la forma más rápida de entender la estructura esperada, el resultado final y cómo se ve una buena declaración de problema completada.

Qué aportar en tu prompt

Para usar bien problem-statement, dale al skill una entrada aproximada pero específica: el tipo de usuario, la tarea que quiere completar, el bloqueo y cualquier restricción. Si solo aportas una petición de funcionalidad, la salida tenderá a lenguaje de solución en lugar de a un problema real.

Una entrada más sólida se vería así:

• Persona: “nuevos agentes de soporte en móvil”
• Objetivo: “resolver tickets sin cambiar de herramienta”
• Bloqueo: “pierden el contexto entre el CRM y el chat”
• Restricciones: “alto volumen, poco tiempo de formación, equipo remoto”

Flujo de trabajo recomendado

Empieza con un borrador corto y luego afínalo hasta convertirlo en la narrativa de cinco partes. Usa la plantilla como lista de comprobación: si Because suena a solución, vuelve atrás y pregúntate qué está causando realmente el dolor. Si Which makes me feel resulta genérico, sustitúyelo por una emoción real del usuario vinculada al flujo de trabajo.

Archivos que debes leer primero

Prioriza SKILL.md, template.md y examples/sample.md. El archivo de ejemplos es especialmente útil porque muestra tanto un patrón de buen encuadre como un antipatrón, lo que te ayuda a evitar escribir una solución disfrazada en lugar de una declaración de problema.

Preguntas frecuentes sobre el skill problem-statement

¿problem-statement es solo una plantilla de prompt?

No. El skill problem-statement es un método reutilizable de encuadre, no solo un prompt con huecos para rellenar. Su valor está en forzarte a aclarar el usuario, el bloqueo y la causa raíz antes de escribir un PRD o proponer una solución.

¿Cuándo no debería usarlo?

No uses problem-statement si ya tienes un documento de requisitos bien definido o si estás documentando un detalle de implementación. Tampoco encaja bien cuando el objetivo es idear soluciones; este skill sirve para definir primero el problema.

¿Es problem-statement apto para principiantes?

Sí, si puedes describir a un usuario y un punto de dolor con lenguaje claro. La plantilla es sencilla, pero la calidad depende de que sepas separar el problema del usuario de la solución que prefieres.

¿Cómo encaja en el trabajo de Technical Writing?

En Technical Writing, el skill es útil cuando necesitas aclarar el dolor de la audiencia, respaldar una solicitud de documentación o encuadrar una carencia de contenido antes de escribir. Te ayuda a mantener el documento orientado al resultado en lugar de derivar hacia una narración de funcionalidades.

Cómo mejorar el skill problem-statement

Aporta evidencia, no eslóganes

Los mejores resultados de problem-statement salen de observaciones concretas: qué intentó el usuario, dónde se atascó, qué usó en su lugar y qué falló. “Los usuarios están confundidos” es débil; “los administradores novatos no pueden terminar la configuración porque la interfaz oculta el campo obligatorio de la API key” es mucho mejor.

Separa el problema de la solución

Un fallo habitual es colar una solución dentro del texto. Si tu borrador dice “los usuarios necesitan un dashboard”, reescríbelo como “los usuarios no pueden comparar el estado de las cuentas entre servicios porque las señales de estado están dispersas”. Así problem-statement se mantiene enfocado en la barrera real.

Añade restricciones que cambien la respuesta

Incluye cualquier dato que afecte a la forma del problema: dispositivo, tamaño del equipo, presión de tiempo, cumplimiento normativo, nivel de experiencia o limitaciones de la plataforma. Estos detalles hacen que la declaración de problema sea más creíble y ayudan a que el resultado final sirva para priorizar mejor.

Itera del borrador a una decisión lista

Después del primer resultado, comprueba si la declaración es lo bastante específica como para resistir una revisión con stakeholders. Si no lo es, ajusta la persona, haz que el Because sea más causal y asegúrate de que la frase final se pueda leer sin explicación adicional.