O manifesto

Como construímos software que amplifique a capacidade das pessoas de alcançar o que buscam, sem transferir a elas a complexidade da tecnologia?

O software ganha capacidade rapidamente. A inteligência artificial acelera ainda mais esse processo: hoje é barato gerar telas, opções, automações e camadas de abstração. Essa abundância não garante um produto melhor. Ela também permite transformar uma decisão fraca em muito código correto, e uma ideia desnecessária em uma funcionalidade pronta.

Este manifesto estabelece uma doutrina para decidir o que merece ser construído, como deve ser a experiência de usá-lo e que evidência deve existir antes de aceitar uma implementação. Sua unidade de medida não é a quantidade de funcionalidades entregues. É o progresso que uma pessoa consegue alcançar com clareza, confiança e controle.

A versão 2.1 preserva a concretude alcançada por meio de Jobs to Be Done e Job Stories, e amplia a capacidade da estrutura de trabalhar com definições de produto de extensão e profundidade distintas. Uma Job Story continua oferecendo uma forma especialmente útil de descrever a circunstância que ativa uma necessidade, a motivação que impulsiona a agir e o resultado buscado. No entanto, o fundamento de um desenvolvimento também pode estar expresso por épicos, capacidades, requisitos, regras, jornadas, critérios ou outras estruturas coerentes. O formato da entrada não deve obrigar a distorcer a intenção do produto.

A conclusão central

A função estabelece o que o software permite fazer. A experiência determina quanto dessa capacidade uma pessoa consegue de fato aproveitar.

A experiência não é uma camada estética acrescentada depois de resolver a funcionalidade. Faz parte dela. Se uma solução produz o resultado correto, mas exige que a pessoa decifre a interface, memorize regras desnecessárias ou tema errar, a solução ainda está incompleta.

A estrutura se aplica a produtos em que a experiência de uso influencia diretamente o resultado: aplicações web e móveis, ferramentas internas, sistemas de aprendizagem, serviços digitais, produtos com agentes e soluções assistidas por IA. Destina-se a gestores de produto, designers, profissionais de desenvolvimento e agentes de código que participam de decisões de produto.

Não prescreve um estilo visual, uma tecnologia, uma estrutura de PRD, uma estratégia de entrega nem um framework de engenharia. Tampouco elimina a complexidade real do domínio. Define como impedir que a estrutura interna do sistema se transforme, por comodidade do time, em trabalho adicional para quem o utiliza.

Este documento contém o núcleo do manifesto. Sua tradução para métodos de desenvolvimento baseados em especificações e para frameworks específicos deve ser feita por meio de anexos ou adaptadores separados. Nenhuma implementação pode reduzir seus princípios, alterar o escopo definido por produto nem atribuir ao agente uma autoridade que o núcleo reserva às pessoas.

O documento oferece duas profundidades de leitura. A primeira permite compreender a postura em poucos minutos. A segunda converte essa postura em decisões verificáveis durante o desenvolvimento.

Rota	Conteúdo	Uso recomendado
Compreender	Tese e texto canônico do manifesto	Alinhar o time antes de definir uma solução
Decidir	Dez princípios, fundamento de produto e Job Stories com regras e perguntas de controle	Resolver alternativas de produto e de UX
Construir	Doutrina específica para desenvolvimento com IA	Orientar agentes de código e revisores humanos
Verificar	Testes de aceitação, scorecard e antipadrões	Avaliar protótipos, implementações e entregas

Cada princípio se traduz em níveis operacionais. Nenhum nível substitui outro. O fundamento de produto mantém a definição autorizada do que deve ser construído e por quê. Jobs to Be Done pode orientar o progresso geral, e a Job Story oferece a forma de referência deste manifesto para tornar esse progresso concreto, situado e verificável.

Nível	Pergunta que responde	Resultado
Princípio	O que acreditamos	Um critério estável para orientar decisões
Fundamento de produto	O que deve ser construído, por quê e sob que condições	Uma base autorizada, rastreável e verificável
Job Story de referência	Quando surge uma necessidade e que progresso a pessoa busca	Uma forma concreta para projetar e verificar
Regra	O que exige ao projetar ou implementar	Um comportamento observável do produto e do time
Teste	Como sabemos se cumprimos	Evidência que permite aceitar, revisar ou rejeitar

O núcleo define princípios, autoridades, condições de rastreabilidade, critérios de aceitação e limites para times e agentes. Um anexo geral pode traduzir essas obrigações para um método de desenvolvimento baseado em especificações. Os adaptadores de frameworks específicos devem resolver comandos, modelos, fluxos, persistência e compatibilidade sem modificar o núcleo. Uma mudança de framework não constitui, por si só, uma nova versão do manifesto.

Manifesto para o desenvolvimento de software humano

O propósito do software é ampliar o que uma pessoa pode fazer.

As pessoas não chegam aos nossos produtos para utilizar funcionalidades. Chegam porque querem compreender, decidir, criar, aprender, comunicar-se, resolver problemas ou avançar. Esse progresso é o nosso verdadeiro produto.

O progresso não acontece em abstrato. Ele é ativado quando uma circunstância cria uma necessidade, uma tensão ou uma decisão. Antes de projetar uma resposta, descrevemos essa circunstância, a motivação que ela produz e o resultado que a pessoa busca. A solução vem depois.

A definição de produto governa o que deve ser construído. Pode ser expressa por uma única história ou por um PRD extenso, composto de histórias, capacidades, regras, estados, jornadas e critérios. O desenvolvimento deve compreender essa estrutura, preservar seu significado e contemplar todo o seu escopo. Decompor, ordenar ou executar o trabalho em paralelo não autoriza omiti-lo nem redefini-lo.

Por isso a experiência faz parte da funcionalidade. Um sistema que permite concluir uma tarefa, mas obriga a interpretar a interface, memorizar convenções, atravessar estruturas desnecessárias ou perguntar-se o que acontecerá em seguida, transfere à pessoa um problema que o produto deveria resolver.

Não rejeitamos a complexidade. Muitos problemas importantes são complexos. Rejeitamos que a complexidade de construí-los tenha de se converter automaticamente em complexidade para quem usa a ferramenta.

Buscamos software simples no começo e profundo quando necessário. Software que revele capacidades em contexto, explique sem interromper, antecipe sem controlar e permita que a pessoa se recupere sem medo.

Cada elemento deve justificar a atenção que consome. Cada interação deve ajudar a compreender onde estamos, o que podemos fazer e o que acontecerá em seguida. Cada detalhe deve contribuir para uma experiência coerente, rápida e confiável.

A inteligência artificial deve absorver complexidade, não multiplicá-la. Pode propor, resumir e automatizar, mas permanece subordinada à intenção da pessoa. As regras críticas, as permissões, os compromissos e os estados que exigem certeza não dependem de uma interpretação probabilística.

Agora que construir ficou mais fácil, nossa responsabilidade aumenta. Antes de acrescentar uma capacidade, perguntamos que progresso ela habilita, que carga introduz, que risco cria e se merece existir.

Nosso objetivo é que a sofisticação permaneça por trás da experiência e que, diante dela, a pessoa conserve seu propósito, sua atenção e seu controle.

O melhor software não faz a pessoa admirar o software. Faz com que ela se surpreenda com o que agora é capaz de fazer.