The manifesto

How do we build software that amplifies people's capacity to achieve what they seek, without transferring the complexity of the technology to them?

Software gains capability quickly. Artificial intelligence accelerates that process further: today it is cheap to generate screens, options, automations and layers of abstraction. That abundance does not guarantee a better product. It also makes it possible to turn a weak decision into a great deal of correct code, and an unnecessary idea into a finished feature.

This manifesto establishes a doctrine for deciding what deserves to be built, how it must feel to use, and what evidence must exist before an implementation is accepted. Its unit of measurement is not the number of features delivered. It is the progress a person can achieve with clarity, trust and control.

Version 2.1 preserves the concreteness reached through Jobs to Be Done and Job Stories, and extends the framework's capacity to work with product definitions of differing length and depth. A Job Story remains a particularly useful way to describe the circumstance that triggers a need, the motivation that drives action and the outcome being sought. The foundation of a development effort, however, may also be expressed through epics, capabilities, requirements, rules, journeys, criteria or other coherent structures. The format of the input must not force the product's intent to be distorted.

The central conclusion

Function establishes what the software makes possible. Experience determines how much of that capability a person can actually put to use.

Experience is not an aesthetic layer added once the functionality has been solved. It is part of it. If a solution produces the correct result but requires the user to decipher the interface, remember unnecessary rules or fear making a mistake, the solution is still incomplete.

The framework applies to products where the user experience directly influences the outcome: web and mobile applications, internal tools, learning systems, digital services, agent-enabled products and AI-assisted solutions. It is addressed to product managers, designers, developers and coding agents who take part in product decisions.

It does not prescribe a visual style, a technology, a PRD structure, a delivery strategy or an engineering framework. Neither does it remove the real complexity of the domain. It defines how to prevent the system's internal structure from becoming, for the team's convenience, additional work for the person using it.

This document contains the core of the manifesto. Translating it into specification-driven development methods and into particular frameworks must be done through separate annexes or adapters. No implementation may reduce its principles, alter the scope defined by product, or attribute to the agent an authority that the core reserves for people.

The document offers two depths of reading. The first makes the stance understandable in a few minutes. The second turns that stance into verifiable decisions during development.

Route	Content	Recommended use
Understand	Thesis and canonical text of the manifesto	Align the team before defining a solution
Decide	Ten principles, product foundation and Job Stories with rules and control questions	Decide between product and UX alternatives
Build	Doctrine specific to development with AI	Guide coding agents and human reviewers
Verify	Acceptance tests, scorecard and anti-patterns	Evaluate prototypes, implementations and deliveries

Each principle is expressed at several operational levels. No level replaces another. The product foundation preserves the authorized definition of what must be built and why. Jobs to Be Done can orient progress in general terms, and the Job Story offers this manifesto's reference form for making that progress concrete, situated and verifiable.

Level	Question it answers	Result
Principle	What we believe	A stable criterion for orienting decisions
Product foundation	What must be built, why and under what conditions	An authorized, traceable and verifiable base
Reference Job Story	When a need arises and what progress the person is after	A concrete form for designing and verifying
Rule	What it demands when designing or implementing	An observable behavior of the product and the team
Test	How we know whether we have met it	Evidence that allows accepting, revising or rejecting

The core defines principles, authorities, traceability conditions, acceptance criteria and limits for teams and agents. A general annex may translate these obligations into a specification-driven development method. Adapters for particular frameworks must resolve commands, templates, flows, persistence and compatibility without modifying the core. A change of framework does not in itself constitute a new version of the manifesto.

Manifesto for human software development

The purpose of software is to extend what a person can do.

People do not come to our products in order to use features. They come because they want to understand, decide, create, learn, communicate, solve problems or move forward. That progress is our real product.

Progress does not happen in the abstract. It is triggered when a circumstance creates a need, a tension or a decision. Before designing a response we describe that circumstance, the motivation it produces and the outcome the person is seeking. The solution comes afterwards.

The product definition governs what must be built. It may be expressed as a single story or through an extensive PRD made up of stories, capabilities, rules, states, journeys and criteria. Development must understand that structure, preserve its meaning and account for its full scope. Breaking the work down, ordering it or running it in parallel does not authorize omitting or redefining it.

This is why experience is part of functionality. A system that lets someone complete a task but forces them to interpret the interface, remember conventions, work through unnecessary structures or wonder what will happen next, transfers to the user a problem the product should have solved.

We do not reject complexity. Many important problems are complex. What we reject is that the complexity of building them should automatically become complexity for whoever uses the tool.

We seek software that is simple to begin with and deep when needed. Software that reveals capabilities in context, explains without interrupting, anticipates without controlling and lets people recover without fear.

Every element must justify the attention it consumes. Every interaction must help us understand where we are, what we can do and what will happen next. Every detail must contribute to an experience that is coherent, fast and dependable.

Artificial intelligence must absorb complexity, not multiply it. It may propose, summarize and automate, but it remains subordinate to the person's intent. Critical rules, permissions, commitments and states that require certainty do not depend on a probabilistic interpretation.

Now that building is easier, our responsibility grows. Before adding a capability we ask what progress it enables, what burden it introduces, what risk it creates and whether it deserves to exist.

Our aim is for sophistication to remain behind the experience, and for the person in front of it to retain their purpose, their attention and their control.

The best software does not make users admire the software. It makes them marvel at what they can now do.