Adaptive Product Development

Post-Agile

Organisations built around release cycles struggle when software can change itself after release.

Agile taught teams to build under uncertainty.

AI shifts the focus from shipping features to improving software after release.

Adaptive Product Development is an operating model for continuously evolving AI systems.

Explore the SODA Loop → Read the manifesto

The historical arc

Each model optimised for the constraint of its time.

Waterfall

Optimised for large planned releases.

Agile

Optimised for learning through short iterations.

DevOps

Optimised for continuous delivery and deployment.

Adaptive Product Development

Optimised for software that continues improving after release.

Each shift changed the core question organisations were trying to answer.

  • Waterfall asked: can we deliver the project?
  • Agile asked: are we building the right thing?
  • DevOps asked: can we deliver continuously and reliably?
  • Adaptive Product Development asks: how do we manage software that keeps learning after release?

Why Agile becomes incomplete

Agile shortened the distance between building software and learning from users.
AI changes the problem again.
Software can now adapt, generate outputs, and influence decisions after release.

Agile compressed discovery from years to weeks, put customers back in the loop, and made shipping working software the default. Where software still changes slowly, Agile still works extremely well.

What changes with AI is the nature of the product itself. Products no longer only execute predefined logic and wait for the next release cycle to improve. They can now adapt and change behaviour after release.

In many AI systems, the most important learning now happens after deployment, not before it. It happens through real-world use, evaluation, feedback, and adaptation after deployment.

Waterfall pushed learning toward upfront planning.
Agile shortened learning cycles through iteration.
DevOps made delivery continuous.
AI moves learning into the running system itself.

The most valuable organisations will not simply be the ones that ship faster. They will be the ones that improve faster in the real world.

Faster delivery alone is no longer enough.

As software becomes cheaper to build, the advantage shifts toward organisations that can learn faster, stay aligned, and maintain trust as systems evolve after release.

Leaders are increasingly accountable for systems they cannot fully observe, predict, or manually review.

AI makes it far easier to build, ship, and change software. Most organisations are not designed for that pace of change.

The result is a growing gap between what organisations deploy and what leaders can confidently understand, trust, and control.

Teams move faster.
Visibility weakens.
Ownership becomes less clear.
Decisions become harder to trace.

Many leadership teams already feel this tension.

AI tools spread across organisations faster than teams can align around them.

Software changes faster than many review and approval processes were designed for.

More decisions now happen inside systems leaders cannot fully see or manually review.

The challenge is no longer whether organisations can build with AI. It is whether they can stay aligned, trusted, and in control as AI becomes part of everyday operations.

Waterfall worked best when requirements could be defined upfront.

Agile worked best when teams needed to learn through fast feedback and iteration.

AI changes the nature of the product again. Systems can now generate outputs, adapt behaviour, and influence decisions after release.

The challenge is no longer only helping teams learn faster.

It is helping organisations maintain trust, visibility, and coordination as software continues changing after release.

The shift

From release cycles to continuous learning.

Traditional software cycle

  1. Build
  2. Ship
  3. Wait
  4. Review

Feedback arrived weeks or months later.

Adaptive systems cycle

  1. Sense
  2. Orient
  3. Decide
  4. Act

Feedback comes from real-world use.

Improvement no longer waits for the next sprint or release cycle.

Adaptive Product Development

An operating model for software that keeps learning after release.

The SODA Loop is how it runs: sense, orient, decide, act.

The operating loop

The SODA Loop A four-phase operating loop for adaptive organisations. Phase 1 Sense: collect runtime signals from users, systems, agents, workflows, and outcomes. Phase 2 Orient: interpret context, align priorities, evaluate constraints, and understand risk. Phase 3 Decide: coordinate human and AI judgment to determine the next best action. Phase 4 Act: execute through products, workflows, automations, teams, and systems. The four phases repeat continuously; outcomes feed the next cycle. The SODA Loop A coordination loop for software that keeps learning after it ships. 1 SENSE Collect runtime signals from users, systems, agents, workflows, and outcomes. 2 ORIENT Interpret context, align priorities, evaluate constraints, and understand risk. 3 DECIDE Coordinate human and AI judgment to determine the next best action. 4 ACT Execute through products, workflows, automations, teams, and systems. REPEAT CONTINUOUSLY Outcomes feed the next cycle. Organisations that adapt fastest, outperform. SODA helps you sense the right signals, orient with clarity, decide with confidence, and act with impact.

The Manifesto

We value:

  • learning from real-world behaviouroverassuming we know upfront
  • systems that keep improving in productionoverwaiting for the next release cycle to improve them
  • fast feedback from real useoverlearning mainly through release cycles
  • systems we can observe and trustoverautomation we cannot fully understand
  • shared visibility and coordinationoverteams improving in isolation
  • human judgment supported by AIoverreplacing judgment with automation
  • evidence from real-world useoverconfidence based on planning
  • changes we can safely roll backoverchanges that are difficult to recover from

While there is value in the items on the right, we value the items on the left more.

The twelve principles

Twelve principles for organisations building with AI.

  1. 01

    Outcomes over output.

    Match what you measure to what you actually want.

  2. 02

    Every AI behaviour is a product decision.

    Treat it that way.

  3. 03

    Evals before features.

    Behaviour you cannot measure, you cannot trust.

  4. 04

    Bound the blast radius.

    Decide ahead of time what an autonomous action can and cannot do.

  5. 05

    Design rollback before scale.

    Ship things you can take back.

  6. 06

    The simplest agent that works.

    Add complexity only when the simpler version fails.

  7. 07

    Governance defines what autonomous systems are allowed to do.

    Not a late legal review.

  8. 08

    Make production behaviour visible.

    If you cannot see it, you cannot govern it.

  9. 09

    Track learning, not just delivery.

    Velocity without learning is busy work.

  10. 10

    Humans own judgment.

    Exceptions, escalations, and ethics stay with people.

  11. 11

    The safe path is the fast path.

    Build platforms that make it so.

  12. 12

    “Done” is an operating condition.

    Not an endpoint.

The operating model

Eight layers for helping organisations manage AI systems safely as they change over time.

A stack that helps organisations improve systems safely in real-world use.

  1. 01 Live feedback architecture

    User signals, behavioural events, qualitative feedback, task outcomes, and economic metrics, connected back to roadmap and model choice.

  2. 02 Evaluation layer

    Offline evals before release. Online evals in production. Without these, AI features ship blind.

  3. 03 Context layer

    Shared organisational memory, retrieval governance, documentation freshness, repository-level instructions. Most AI failures are context failures.

  4. 04 Agentic workflow layer

    An autonomy matrix by risk class. Action registers, tool permission maps, fallback paths, escalation policies.

  5. 05 Governance and trust layer

    Risk tiering, least privilege, audit trails, incident playbooks, rollback rights. Governance defines what autonomous systems are allowed to do, not a late legal review.

  6. 06 Observability layer

    Traces across prompts, tools, retrieval, outputs, costs, downstream effects. The system can pass every health check while outputs quietly degrade.

  7. 07 Adaptation layer

    Where learning changes the product. Personalisation, workflow handoffs, prompt and retrieval improvements. Improving system behaviour becomes ongoing product work.

  8. 08 Organisational operating model layer

    Decision rights across product, engineering, platform, data and AI, risk and compliance. Funding for platform and governance, not only visible features.

Authored by

Marton Gaspar

martongaspar.com · LinkedIn

Lineage. The framework draws on Marty Cagan's product operating model; Martin Fowler's writing on continuous integration and software architecture; the DevOps and continuous-delivery research of Nicole Forsgren, Jez Humble, and Gene Kim; Charity Majors's observability practice; the AI-engineering writing of Simon Willison and Andrej Karpathy; the agent-engineering practice emerging at LangChain, OpenAI, and Anthropic; and DORA's research on team performance. Cited as influences, not endorsements.

Licence

Cite this. Build on it. Attribution required.

This work is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). You are free to share, adapt, and build on the manifesto, principles, and operating model, including for commercial use, on the condition that you give appropriate credit and link back to adaptiveproductdevelopment.com.

Suggested citation
Gaspar, M. (2026). Adaptive Product Development.
https://adaptiveproductdevelopment.com

Version 2.0, May 2026. No warranty. The framework is offered as a thinking tool, not a guarantee of outcome.