# Adaptive Product Development A post-Agile operating model for teams building with AI. Published as a public good under CC BY 4.0. Authored by Marton Gaspar. https://adaptiveproductdevelopment.com Version 1.0, May 2026. --- ## The premise Organisations built for slower feedback loops cannot operate at AI speed. AI increases output. Most organisations still cannot sense, decide, and adapt fast enough to govern it. Agile taught us to build under uncertainty. DevOps closed the gap to production. Product-led practice put the customer in the loop. AI demands a fourth thing. Adaptive Product Development is the post-Agile operating model for teams building with AI. The SODA Loop runs inside it: sense, orient, decide, act. --- ## The Manifesto We are uncovering better ways of building products, organisations, and intelligent systems by operating them live, learning from them continuously, and helping others do the same. Through this work we have come to value: - continuous feedback loops over fixed delivery cycles - trusted learning systems over static releases - runtime evidence over upfront certainty - governed autonomy over unchecked automation - shared context over disconnected tooling - human judgment amplified by AI over labour substitution - evidence over output optimism - evolution in operation over optimisation before launch That is, while there is value in the items on the right, we value the items on the left more. --- ## The shift, in one line AI does not just speed up the sprint. It changes the unit of development from shipped features to governed learning loops. --- ## The SODA Loop The operating loop for adaptive organisations. The umbrella philosophy is Adaptive Product Development; the SODA Loop is the operational mechanism inside it. Four phases, repeated continuously, in production. 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. Outcomes feed the next cycle. --- ## Why now Products no longer only execute predefined logic and wait for the next release cycle to improve. They can recommend, generate, personalise, decide, and trigger actions while live. They can fail in non-deterministic ways. They can drift. They can absorb bad context. They can create value quickly and create risk just as quickly. The unit of work moves from shipped features to governed learning loops. The most valuable organisations will not simply be the ones that ship faster. They will be the ones that build trusted loops between users, products, data, models, agents, and human decision-makers. They will treat context as infrastructure and evals as product work. Raw coding throughput is not productivity. Governance and observability stop being late-stage controls; they become how the product is designed. Adaptive Product Development is the operating model for organisations that learn while operating. The SODA Loop runs continuously in production: sense, orient, decide, act, with governed autonomy and human judgment in the loop. Agile is not wrong. It is incomplete for adaptive AI systems. --- ## The historical arc - **Waterfall** optimised for predictability. - **Agile** optimised for discovery. - **DevOps** optimised for deployability and outcomes. - **Adaptive Development** optimises for runtime learning loops. The right model at the right stage. Adaptive Development for what's next. --- ## The twelve principles 1. Put real-world outcomes above model novelty. 2. Every adaptive behaviour is a product decision. 3. Make evals part of development, not an afterthought. 4. Keep the blast radius of autonomy explicit and limited. 5. Design for rollback before scale. 6. Prefer the simplest agent pattern that works. 7. Give models governed access to the context they need. 8. Make runtime behaviour visible to humans in detail. 9. Track learning velocity, not just delivery velocity. 10. Keep humans responsible for exceptions and judgment. 11. Build internal platforms that make the safe path the fast path. 12. "Done" is a temporary operating condition, not an endpoint. --- ## The eight-layer operating model Adaptive Product Development is not a single practice. It is a stack of eight layers that together keep a live system safe, observable, and able to learn. 1. **Live feedback architecture.** Instrumented user signals, behavioural events, qualitative feedback, task outcomes, error categories, and economic metrics, connected back to roadmap, model choice, and workflow design. 2. **AI evaluation layer.** Offline evals before release. Online evals in production. Behaviour specified, not just functionality. Without this, AI features ship blind. 3. **Context layer.** Shared organisational memory, retrieval governance, documentation freshness, repository-level instructions. AI quality is now a context problem as much as a model problem. 4. **Agentic workflow layer.** An autonomy matrix by risk class. Action registers, tool permission maps, fallback paths, and escalation policies. Define where agents act, where humans decide, where escalation is mandatory. 5. **Governance and trust layer.** Risk tiering, least privilege, audit trails, incident playbooks, rollback rights, model and agent registers. Governance is the runtime permission model of the system, not a late legal review. 6. **Observability layer.** Traces across prompts, tools, retrieval, outputs, costs, downstream effects. The system can be technically healthy while outputs quietly degrade. 7. **Product adaptation layer.** Where learning changes the product. Personalisation, recommendation shifts, workflow handoffs, prompt and retrieval improvements, feature evolution. The adaptation backlog is its own object: not a feature backlog, not a bug list, a record of what the product is learning to do differently. Outcome reviews close the loop. 8. **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. Rituals that connect roadmap, operations, incidents, and learning. --- ## Authored by Marton Gaspar. https://martongaspar.com ยท https://www.linkedin.com/in/martongaspar/ ### 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 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 https://adaptiveproductdevelopment.com. ### Suggested citation Gaspar, M. (2026). Adaptive Product Development. https://adaptiveproductdevelopment.com Version 1.0, May 2026. No warranty. The framework is offered as a thinking tool, not a guarantee of outcome. --- ## Closing Organisations that adapt fastest will outperform organisations that merely ship fastest.