Decision-Driven Product Development
Manifesto · October 2026
Your agents don’t wait for sprints. Your decisions do.
Scrum batches decisions into ceremonies. An agent needs one every few minutes. DDPD replaces the calendar with events: push, check, decide, codify.
Manifesto
for Decision-Driven Product Development
We are uncovering better ways of building products in which agents write the code and people make the decisions. Through this work we have come to value:
- Decisions at the agent’s paceoverdecisions at ceremonies
- Interrogating the running systemoverreading the code
- Ownership of decisionsoverjob titles and tasks
- Codifying human judgment into feedback loopsoverrepeating it
That is, while there is value in the items on the right, we value the items on the left more.
Twelve principles
- Our highest priority is delivering value to the customer through fast, sound decisions.
- The person who best understands a decision’s consequences makes it, right away, not at the next meeting.
- The person who understands the business and the person who understands the system work together daily throughout the build.
- Every decision ends in an artifact in the repo: a spec, a plan, or an issue.
- The spec is a living document: it changes as our understanding of the product changes.
- If the agent can’t verify its own work, the plan isn’t ready.
- What people check repeatedly, the platform checks automatically.
- Tools enforce architectural principles, not people’s memory.
- Technical and domain knowledge is what lets you challenge the agent’s proposals.
- A person is accountable for every change they let into production.
- A role is a decision domain, not a person.
- We regularly look at where people and agents lose time, and improve how we work.
The problem
for leaders who rolled out agents
Sound familiar?
Output went up. Delivery didn’t.
Teams using AI merged 98% more PRs, and review time rose 91%.
Developers are making business calls.
A week spent on a decision the business flags as wrong two weeks later.
Decisions wait for the ceremony.
A question found on day two waits for the next planning session. The agent finished days ago.
Vibe coding crept in.
Nobody can say who owns quality anymore.
Nobody is sure what their job is now.
When the agent writes the code, developers struggle to find their place.
The shift
two loops
The bottleneck moved.
Code loop
Minutes.
Write code → check code. Agents cut it to minutes.
Decision loop
Weeks.
Make a decision → learn whether it was right. Still weeks. DDPD shortens this one.
Team throughput = decision speed × decision quality.
Code is now cheap and plentiful. Deciding is expensive, and it takes people, because there is no single right answer. It depends on the company’s context, history and many other variables.
A person sits wherever the job is to choose between valid answers in the company’s context. Wherever correctness can be checked automatically, the agent does the work.The rule
The flow
where the human is
Where the human is.
Work is driven by events, not the calendar. Every step ends in an artifact in the repo that the next step picks up.
Steps 1–2
Once, at the start. Rarely changes.
- 01Brief.
- Person decides
- Direction Owner: vision, goals, scope, priorities.
- Agent does
- Research, insight analysis, document structure.
- Artifact
- docs/product/brief.md
- 02Constitution.
- Person decides
- Constitution Owner: stack, principles, prohibitions.
- Agent does
- Drafts it; later enforces it through skills.
- Artifact
- constitution.md
Steps 3–8
Every backlog item, iteration by iteration. This part loops.
- 03Backlog.
- Person decides
- Direction Owner: what comes next, and what we won’t do.
- Agent does
- Data and feedback analysis.
- Artifact
- Prioritized backlog item
- 04Spec.
- Person decides
- Intent Owner: what it should mean for the business.
- Agent does
- Draft spec, map of existing code, mockup.
- Artifact
- Living spec in the repo
- 05Plan.
- Person decides
- System Owner: technical approach, feedback loops, skills for this iteration.
- Agent does
- Task plan, simulators, tests.
- Artifact
- Agent plan + feedback loops
- 06Build.
- Person decides
- No one decides except for escalations.
- Agent does
- Implementation, tests, fixes driven by feedback loops.
- Artifact
- Pushed iteration
- 07Check.
- Person decides
- Intent Owner tests the running system; a second System Owner reviews by interrogation.
- Agent does
- Answers questions, maps processes, reports test results.
- Artifact
- Check result
- 08Discrepancy.
- Person decides
- Intent Owner: bug, spec gap, or escalation.
- Agent does
- Draft issue or spec change.
- Artifact
- GitHub issue or spec change
The discrepancy becomes the next spec change or issue, and the loop runs again.
Underneath everything
Platform.
- Person decides
- Harness Owner: what to turn into a skill or a rule.
- Agent does
- Trace analysis, issues filed from logs.
- Artifact
- Skills, rules, CI
Roles
as decision domains
A role is a decision domain.
A role is a decision domain someone owns, not a set of tasks. The agent does the tasks. People decide. One person can hold one role or several.
- Direction OwnerProduct Manager · Product
What do we do next, and what do we not do at all?
- Intent OwnerIntent Engineer · Product
Does the system do what the business means?
- Constitution OwnerArchitect · Engineering
What technical principles do we build the whole product on?
- System OwnerAgentic Systems Engineer · Engineering
Is the technical solution sound? Scale, cost, speed, interfaces, migrations, observability.
- Harness OwnerHarness Engineer · Engineering
Does the agent have everything it needs to work fast and well?
Both streams stay. Product owns direction and meaning; Engineering owns the principles, the system and the agent platform. Titles are a suggestion; the accountabilities are the framework.
Validation
testing and interrogation
Nobody reads diffs. Everything gets checked.
Three loops replace the separate tester.
Correctness
The agent and the test pyramid. Tests maintained by the Harness Owner.
Meaning
The Intent Owner runs the system and asks:
“Map this process.”
“What happens if a customer does X?”
Technical quality
A second System Owner reviews by interrogation:
“Were performance tests run? What were the results?”
People discover. The platform codifies.
Whatever comes up twice, the Harness Owner turns into a skill or an automated check.
Rhythm
flow, with a stop to unload
A train that stops every two weeks.
Work flows continuously. Increments are built, checked and sent for acceptance as soon as they’re ready. Every two weeks the train stops to unload: a demo of every iteration finished. Then it moves on.
What the business sees at any time
Every backlog item has a state, and every state is an artifact in the repo.
- Spec
- Plan
- Build
- Check
- Awaiting acceptance
- Accepted
Proof
what the data says
What the data says.
60% vs 0–20%
Developers use AI in about 60% of their work but can fully delegate only 0–20% of tasks.
Anthropic, 2026 Agentic Coding Trends Report
+98% PRs +91% review
More PRs merged, and much longer review, across 8.1 million PRs.
LinearB
1:15 → feels like 1:40
Atlassian PM-to-engineer ratios with AI.
Sherif Mansour
~10x
What we saw: one developer alone vs. the same developer paired with a business person who interrogated the codebase and wrote specs.
In practice
The industry sees the bottleneck in code review. Review is one part of it. The bottleneck is business decisions.
Where DDPD sits
three levels
Keep your tools. They work one level down.
- Individual + agentHow do I get from idea to code?BMAD, Spec Kit, Superpowers, Kiro
- TeamHow does a team validate an agent’s work?AWS AI-DLC
- OrganizationWho decides what, how do decisions move, how do we hire?DDPD
FAQ
Questions leaders ask.
- Is this waterfall?
- No. Everything is written down, but specs change fast. Waterfall failed because implementation was expensive. Now a bad spec costs hours, not months. Watch for “SpecFall”: a spec written far ahead and treated as fixed.
- Where is the tester?
- Not a separate role. The agent and the test pyramid check correctness, the Intent Owner checks meaning, and the System Owner checks technical quality.
- Why doesn’t the Intent Owner implement alone?
- They don’t own the system decisions: patterns, stack, costs, what badly written tests look like. That’s the System Owner’s domain.
- How do decisions not get lost in conversation?
- Every conversation that surfaces a problem ends in a spec and a plan, or a GitHub issue. Specs and issues are the history of decisions.
- What if the PM and the team disagree?
- Checking is cheaper than arguing. A prototype takes an hour, so you settle it with working evidence.
Contact
an open discussion
Want to brainstorm the framework?
DDPD gets sharper every time someone pushes back on it. Tell Greg where decisions get stuck in your team, what you’d change in the framework, or what you’re trying with agents. No pitch, just a conversation.