El manifiesto

¿Cómo construimos software que amplifique la capacidad de las personas para conseguir lo que buscan, sin transferirles la complejidad de la tecnología?

El software gana capacidad con rapidez. La inteligencia artificial acelera todavía más ese proceso: hoy resulta barato generar pantallas, opciones, automatizaciones y capas de abstracción. Esa abundancia no garantiza un mejor producto. También permite convertir una decisión débil en mucho código correcto y una idea innecesaria en una funcionalidad terminada.

Este manifiesto establece una doctrina para decidir qué merece ser construido, cómo debe sentirse al usarlo y qué evidencia debe existir antes de aceptar una implementación. Su unidad de medida no es la cantidad de funcionalidades entregadas. Es el progreso que una persona puede lograr con claridad, confianza y control.

La versión 2.1 conserva la concreción alcanzada mediante Jobs to Be Done y Job Stories, y amplía la capacidad del marco para trabajar con definiciones de producto de distinta extensión y profundidad. Una Job Story sigue ofreciendo una forma especialmente útil de describir la circunstancia que activa una necesidad, la motivación que impulsa a actuar y el resultado buscado. Sin embargo, el fundamento de un desarrollo también puede estar expresado mediante épicas, capacidades, requisitos, reglas, recorridos, criterios u otras estructuras coherentes. La forma de la entrada no debe obligar a deformar la intención del producto.

La conclusión central

La función establece lo que el software permite hacer. La experiencia determina cuánto de esa capacidad puede aprovechar realmente una persona.

La experiencia no es una capa estética que se agrega después de resolver la funcionalidad. Forma parte de ella. Si una solución produce el resultado correcto, pero exige que el usuario descifre la interfaz, recuerde reglas innecesarias o tema equivocarse, la solución sigue incompleta.

El marco sirve para productos donde la experiencia de uso influye directamente en el resultado: aplicaciones web y móviles, herramientas internas, sistemas de aprendizaje, servicios digitales, productos con agentes y soluciones asistidas por IA. Está dirigido a product managers, diseñadores, desarrolladores y agentes de código que participan en decisiones de producto.

No prescribe un estilo visual, una tecnología, una estructura de PRD, una estrategia de entrega ni un framework de ingeniería. Tampoco elimina la complejidad real del dominio. Define cómo impedir que la estructura interna del sistema se convierta, por comodidad del equipo, en trabajo adicional para la persona que lo usa.

Este documento contiene el núcleo del manifiesto. Su traducción a métodos de desarrollo basados en especificaciones y a frameworks particulares debe realizarse mediante anexos o adaptadores separados. Ninguna implementación puede reducir sus principios, alterar el alcance definido por producto ni atribuir al agente una autoridad que el núcleo reserva a las personas.

El documento ofrece dos profundidades de lectura. La primera permite comprender la postura en pocos minutos. La segunda convierte esa postura en decisiones verificables durante el desarrollo.

Ruta	Contenido	Uso recomendado
Comprender	Tesis y texto canónico del manifiesto	Alinear al equipo antes de definir una solución
Decidir	Diez principios, fundamento de producto y Job Stories con reglas y preguntas de control	Resolver alternativas de producto y UX
Construir	Doctrina específica para desarrollo con IA	Guiar a agentes de código y revisores humanos
Verificar	Pruebas de aceptación, scorecard y anti patrones	Evaluar prototipos, implementaciones y entregas

Cada principio se traduce en niveles operativos. Ningún nivel sustituye a otro. El fundamento de producto conserva la definición autorizada de lo que debe construirse y por qué. Jobs to Be Done puede orientar el progreso general y la Job Story ofrece la forma de referencia de este manifiesto para volver ese progreso concreto, situado y verificable.

Nivel	Pregunta que responde	Resultado
Principio	Qué creemos	Un criterio estable para orientar decisiones
Fundamento de producto	Qué debe construirse, por qué y bajo qué condiciones	Una base autorizada, trazable y verificable
Job Story de referencia	Cuándo surge una necesidad y qué progreso busca la persona	Una forma concreta para diseñar y verificar
Regla	Qué exige al diseñar o implementar	Una conducta observable del producto y del equipo
Prueba	Cómo sabemos si lo cumplimos	Evidencia que permite aceptar, revisar o rechazar

El núcleo define principios, autoridades, condiciones de trazabilidad, criterios de aceptación y límites para equipos y agentes. Un anexo general puede traducir estas obligaciones a un método de desarrollo basado en especificaciones. Los adaptadores de frameworks particulares deben resolver comandos, plantillas, flujos, persistencia y compatibilidad sin modificar el núcleo. Un cambio de framework no constituye por sí mismo una nueva versión del manifiesto.

Manifiesto para el desarrollo de software humano

El propósito del software es ampliar lo que una persona puede hacer.

Las personas no llegan a nuestros productos para utilizar funcionalidades. Llegan porque quieren comprender, decidir, crear, aprender, comunicarse, resolver o avanzar. Ese progreso es nuestro verdadero producto.

El progreso no ocurre en abstracto. Se activa cuando una circunstancia crea una necesidad, una tensión o una decisión. Antes de diseñar una respuesta describimos esa circunstancia, la motivación que produce y el resultado que la persona busca. La solución viene después.

La definición de producto gobierna qué debe construirse. Puede expresarse con una sola historia o mediante un PRD extenso compuesto por historias, capacidades, reglas, estados, recorridos y criterios. El desarrollo debe comprender esa estructura, conservar su significado y dar cuenta de su alcance completo. Descomponer, ordenar o ejecutar en paralelo el trabajo no autoriza a omitirlo ni a redefinirlo.

Por eso la experiencia forma parte de la función. Un sistema que permite completar una tarea, pero obliga a interpretar la interfaz, recordar convenciones, atravesar estructuras innecesarias o preguntarse qué ocurrirá después, transfiere al usuario un problema que el producto debería resolver.

No rechazamos la complejidad. Muchos problemas importantes son complejos. Rechazamos que la complejidad de construirlos tenga que convertirse automáticamente en complejidad para quien usa la herramienta.

Buscamos software sencillo al comenzar y profundo cuando se necesita. Software que revele capacidades en contexto, explique sin interrumpir, anticipe sin controlar y permita recuperarse sin miedo.

Cada elemento debe justificar la atención que consume. Cada interacción debe ayudar a comprender dónde estamos, qué podemos hacer y qué ocurrirá después. Cada detalle debe contribuir a una experiencia coherente, rápida y confiable.

La inteligencia artificial debe absorber complejidad, no multiplicarla. Puede proponer, resumir y automatizar, pero permanece subordinada a la intención de la persona. Las reglas críticas, los permisos, los compromisos y los estados que requieren certeza no dependen de una interpretación probabilística.

Ahora que construir es más fácil, nuestra responsabilidad aumenta. Antes de agregar una capacidad preguntamos qué progreso habilita, qué carga introduce, qué riesgo crea y si merece existir.

Nuestro objetivo es que la sofisticación permanezca detrás de la experiencia y que, delante de ella, la persona conserve su propósito, su atención y su control.

El mejor software no consigue que el usuario admire el software. Consigue que se sorprenda de lo que ahora es capaz de hacer.