Fundamento de producto

Del fundamento de producto a una solución verificable

El fundamento de producto es el contenido autorizado que establece qué debe construirse, por qué debe existir, qué resultados debe producir, qué condiciones debe respetar y cómo podrá determinarse su cumplimiento. No es un nuevo tipo de documento ni una plantilla obligatoria. Puede encontrarse en una Job Story, un Jobs to Be Done, una épica, una capacidad, un requisito, una regla de negocio, un recorrido, un criterio de aceptación o una combinación coherente de estos elementos.

Cuándo el fundamento es identificable

Un fundamento de producto es identificable cuando el desarrollo puede establecer, sin inventar decisiones de producto, los siguientes elementos. Pueden estar distribuidos en una o varias partes de la definición recibida y no necesitan utilizar estos nombres ni este orden.

Elemento	Pregunta de control	Condición mínima
Fuente y autoridad	¿De dónde proviene y quién puede modificarlo?	Origen trazable y autoridad reconocida
Razón	¿Qué situación, necesidad, problema u oportunidad aborda?	Justificación comprensible sin depender de la solución
Resultado	¿Qué cambio o progreso debe producir?	Resultado reconocible para las personas o para el producto
Condiciones y límites	¿Qué reglas, restricciones y exclusiones deben respetarse?	Límites suficientes para evitar decisiones silenciosas
Evidencia	¿Cómo sabremos que se cumplió?	Criterios, observaciones o pruebas proporcionales al riesgo

La ausencia de una sección o campo específico en el PRD no constituye por sí misma un defecto. El método debe comprender la estructura que el producto utiliza. Si falta una definición capaz de cambiar materialmente la solución, el agente debe exponer el vacío y acudir a la autoridad correspondiente; no debe completarlo mediante una inferencia silenciosa.

Alcance completo y autoridad de producto

Cuando una definición de producto aprobada contiene múltiples historias, capacidades, reglas o especificaciones, todas forman parte del alcance salvo que la propia definición o una decisión autorizada establezca lo contrario. El plan de desarrollo debe comprender el conjunto, resolver sus relaciones y dependencias y asegurar su cobertura. Puede descomponer, ordenar, agrupar o ejecutar en paralelo el trabajo; esa descomposición no modifica el alcance.

El plan organiza cómo se implementa el alcance. No decide silenciosamente qué parte del alcance merece existir.

• Toda omisión, modificación o postergación debe ser explícita, trazable y aprobada por la autoridad de producto.

• Si las restricciones de tiempo, recursos o tecnología impiden cubrir el alcance, el plan debe hacer visible la incompatibilidad y solicitar una decisión.

• Una estrategia incremental, por fases o por releases puede utilizarse cuando el proyecto la adopta; no es una obligación del núcleo.

• La completitud se determina reconciliando la implementación y la evidencia contra la definición de producto completa y sus excepciones aprobadas.

Este manifiesto utiliza Job Stories como forma de referencia para mostrar cómo un fundamento de producto puede trasladarse al diseño, la implementación y la verificación. Las Job Stories hacen explícitas la circunstancia, la motivación y el resultado esperado, por lo que ofrecen una representación especialmente útil para razonar sobre el progreso humano.

Su utilización en las explicaciones, reglas, ejemplos y pruebas no obliga a que toda definición de producto venga expresada mediante Job Stories ni autoriza a transformar automáticamente un PRD a esa estructura. Cuando la definición utilice otra forma, el método debe preservar su significado, sus relaciones y su autoridad. Una Job Story derivada puede proponerse como vista de trabajo cuando agrega claridad, pero no reemplaza la fuente ni adquiere autoridad por haber sido generada.

De Jobs to Be Done a Job Stories

Jobs to Be Done y Job Stories cumplen funciones distintas. Jobs to Be Done mantiene la dirección del producto: el progreso general por el cual una persona incorpora una solución a su vida o a su trabajo. La Job Story desciende a una situación concreta que puede orientar una decisión de diseño, una implementación y una prueba.

Cuando se utiliza esta forma, cada Job Story debe conservar una relación explícita con el trabajo, propósito o resultado de nivel superior que corresponda. Esa relación impide que una historia aislada pierda la dirección del producto.

Relación entre los niveles

Nivel	Define	Evita
Jobs to Be Done	El progreso amplio que la persona busca conseguir	Organizar el producto alrededor de funcionalidades
Job Story	La circunstancia, la motivación y el resultado que activan una necesidad concreta	Diseñar desde roles genéricos o pedidos literales
Respuesta del producto	El comportamiento del sistema elegido para resolver la historia	Confundir el problema con la primera solución imaginada
Evidencia de aceptación	La observación que demuestra progreso en esa circunstancia	Aceptar una entrega porque funciona técnicamente

Forma canónica de una Job Story

Cuando ocurre una circunstancia observable, necesito conseguir un avance sin prescribir la solución, para poder alcanzar un resultado reconocible.

Cuando. Describe el hecho, cambio o tensión que activa la necesidad. Debe poder observarse o reconocerse sin depender de una persona ficticia.

Necesito. Expresa la motivación, comprensión o decisión requerida. No nombra una pantalla, un botón, un agente ni una funcionalidad.

Para poder. Define la situación mejor que la persona busca alcanzar y que luego deberá verificarse.

Evidencia mínima que acompaña la historia

La frase orienta la conversación, pero no reemplaza la investigación. Una historia lista para guiar desarrollo debe registrar solo la evidencia necesaria para sostener sus decisiones.

Elemento	Pregunta	Contenido mínimo
Conducta actual	¿Qué hace hoy la persona?	Pasos, alternativa o abandono observados
Obstáculo o ansiedad	¿Qué frena o vuelve riesgoso el avance?	Duda, costo, temor, esfuerzo o dependencia relevante
Evidencia causal	¿Qué respalda la relación entre circunstancia y motivación?	Observación, entrevista, dato de uso o supuesto declarado
Evidencia de éxito	¿Qué demostraría que hubo progreso?	Conducta o resultado observable dentro de la circunstancia

Cuándo el rol sigue importando

Job Stories evita usar el rol como explicación automática. No elimina diferencias reales entre personas. El rol, la experiencia, la edad, los permisos o una restricción física deben incorporarse cuando cambian causalmente la circunstancia, el riesgo o la solución válida. Si no cambian la decisión, no deben gobernar la historia.

Pruebas de calidad antes de diseñar

• La circunstancia describe un desencadenante concreto y no una categoría de usuario.

• La motivación expresa progreso o comprensión y no una funcionalidad solicitada.

• El resultado puede reconocerse sin confundirlo con completar el flujo del producto.

• La historia está respaldada por evidencia o identifica con claridad el supuesto pendiente.

• La formulación permite comparar varias respuestas, incluida la opción de no construir.

• El alcance es suficiente para cambiar una decisión, pero no intenta contener el trabajo completo del usuario.

Cadena de trazabilidad

El desarrollo debe poder recorrerse en ambas direcciones: desde cada decisión implementada hasta el fundamento de producto que la justifica, y desde la definición completa del producto hasta la evidencia que demuestra su cobertura. Cuando el fundamento se expresa mediante Job Stories, la trazabilidad debe conservar la circunstancia, la motivación y el resultado de cada historia aplicable.

Origen	Decisión	Verificación
Definición de producto	Qué debe construirse y bajo qué condiciones	Todo elemento obligatorio tiene cobertura o una excepción aprobada
Jobs to Be Done	Qué progreso general merece atención cuando esta forma resulta aplicable	El resultado sigue siendo relevante para la persona
Job Story	Qué circunstancia concreta debe atenderse cuando la fuente utiliza esta forma	La historia está validada y no prescribe una solución no autorizada
Diseño e implementación	Qué comportamiento responde al fundamento	Cada elemento tiene una razón trazable
Aceptación	Qué evidencia autoriza declarar completo el desarrollo	Resultados, reglas y criterios se cumplen bajo las condiciones definidas