Flow Principles for Innowaring
Making the Value Flow through Continuous Discovery and Delivery
This post is part of a series outlining my principles-first approach to AI-Native Product and Systems Innovation.
The first post describes the origin of the Innowaring idea after I published my book, Becoming a Software Company.
The second post describes the Innowaring Concepts, the operating model dimensions for AI-Native innovation — Teaming, Strategy, Flow, and Culture.
The third post describes the principles for the Teaming dimension, and the fourth post describes the principles for the Strategy dimension of Innowaring.
This post describes the principles for the Flow dimension.
Once you've built the right team structures and identified the right problems to solve, the next challenge is turning promising ideas into customer and business outcomes. That motion—how teams explore, validate, and ship solutions that create real value—is the solution development flow.
Flow is not about efficiency for its own sake, as many project management practices end up over-indexing. As Donald Reinertsen described in The Principles of Product Development Flow, product teams create economic value not by producing finished work but by generating new information—insight that gets built into the product or system.
Replicating someone else’s product, implementing the same solutions as everyone else, or chasing long-cycle roadmaps won’t create differentiation. Innovation comes from navigating uncertainty, mitigating risk on new product ideas, and reducing cycle time to incorporate feedback quickly and effectively.
The Innowaring Flow is designed for this reality. It isn’t a rigid process or a single method. It’s a system of principles that helps teams move with intention—discovering and delivering solutions in one continuous loop, driven by learning and feedback. The following principles describe how to design for an optimal development flow.
Principle: Minimum Spec Over Detailed Requirements
In many organizations, work is defined through detailed requirements—spreadsheets, PRDs, and ticket backlogs. The intention is clarity. The result is often the opposite: over-specified work leaves no room for autonomy, and teams follow instructions instead of solving problems.
In Innowaring, the operating principle is Minimum Spec: just enough specification to get started, but no more than necessary. The concept draws from holographic design—an approach to creating self-organizing systems.
Minimum Spec means defining only what truly must be known upfront: regulatory guardrails, known risks that must be mitigated, architecture considerations, or specific workflow incongruities that need to be eliminated. Everything else—e.g., features and user flows—can and should emerge through iteration.
This creates space for emergent ideas. Innovation happens when teams can respond to new information as they build.
For modern software, building is often the best way to understand what should be built. This is especially true in the AI era, when we can prototype in minutes and learn by interacting with working software—not just by documenting every requirement in a premeditated way.
Principle: Working in Small Batches
Most product innovation dysfunction starts when development work is planned in large batches. When batches are too big, feedback gets delayed, risks stay hidden, and course correction becomes slow or impossible.
Instead, teams should prioritize working in small batches. Small batches reduce cycle time, surface issues earlier, and enable faster feedback from real users. Nearly every other aspect of smooth engineering flow—limiting work in progress, delivering on cadence, enabling iteration, creating visibility—depends on keeping batch size small.
A helpful analogy: a tourist town can handle a steady stream of visitors, but everything breaks when a cruise ship offloads hundreds at once. The restaurants, shops, and sidewalks get overwhelmed. The flow collapses under the weight of a large batch.
The same happens in software. Start with a giant list of requirements, and flow disappears. Responsiveness fades. A team delivering a large batch is like a tanker in open water—slow to turn, hard to redirect. What you need is a speedboat: fast, nimble, and adapting as it moves.
This is especially critical in AI-native products, where the landscape shifts week to week. Working in small batches isn’t just a process choice—it’s the only way to stay responsive in a fast-changing environment.
Principle: Optimizing for Fast Feedback
Ideas improve through feedback. The same applies to software products and systems. When implementing ideas with code, early and frequent feedback is essential. Whether in solution discovery or delivery, you want to get input from users and customers as early and often as possible.
The most fundamental aspect of product innovation is rapidly testing what the solution could be—not assuming. Customer requirements may help form a direction, but they often don’t reflect what’s possible with the available technology. At best, any solution idea you begin with is a well-informed guess. Fast feedback helps validate those assumptions and surface critical risks.
To get meaningful feedback early, you must optimize the cycle time in your development process. The shorter the cycle, the tighter the feedback loop between your teams and your users can be. When the loop is tight, each cycle can reliably reduce uncertainty and mitigate risk.
Fast feedback is especially critical in AI engineering, where you build applications on top of foundational LLMs. The core idea is to leverage the model’s completion ability to create completion capability for workflows and tasks. Much of the innovation there lies in crafting a new kind of user experience that can’t be fully imagined upfront. It only emerges by building in small batches and incorporating fast, real-world feedback.
Principle: Continuous Discovery and Delivery
There are two essential aspects to building the best possible solution to a problem. The first is figuring out what to build, a process known as solution discovery. The second is actually building and delivering it, a process known as solution delivery. These two processes must work together—not as separate phases but as one continuous flow.
In the traditional, industrial software development model, one team handles discovery—often finalizing the so-called “scope”—while another, separate technical team builds and delivers the solution. In Innowaring, this is a clear anti-pattern. It’s a process model that no longer works. The same team must do discovery and delivery.
This discovery and delivery process is continuous. You’re constantly uncovering new ideas for improving and implementing the solution because user needs, market context, and the technology landscape continually evolve. This starkly contrasts traditional enterprise approaches, where innovation happens in long cycles and through big transformations. Innowaring demands a different mindset—one of continuous improvement.
Continuous discovery and delivery is about collapsing the gap between ideas and outcomes. This is especially critical for AI-native products, where the right UX around foundational models is still being invented. What’s feasible, viable, usable, or valuable can only be uncovered by building in small batches and engaging users frequently.
Principle: Enabling Infrastructure
Continuous delivery can't happen without enabling infrastructure. The fundamentals of development flow—working in small batches, getting fast feedback, and delivering continuously—must be paired with an infrastructure built to support and sustain them.
Infrastructure represents the technical capabilities to deploy system changes of all kinds—full releases, feature flags, configuration updates, defect fixes, and experiments—quickly, safely, and sustainably. Sometimes referred to as DevSecOps, enabling infrastructure forms the foundation for optimal flow.
Today, AIOps has become a critical extension of this foundation. Traditional DevSecOps focused on code, while AIOps expands the scope to include models, prompts, data pipelines, and output evaluations. In AI-native systems, behavior can shift without a single line of code—just from a prompt tweak or model update. The infrastructure must support rapid iteration, robust testing, and smooth deployment of these changes.
A robust infrastructure for AI-native products ensures that innovation doesn’t come at the cost of quality, compliance, or customer trust. If you want to ship differentiated AI features quickly and responsibly, you need infrastructure designed not just for code but for intelligence.
You must design for an optimal flow. It requires deliberate choices: to start simple and small, to work in small batches, to reduce cycle time for customer feedback, and to support teams with the right infrastructure and autonomy. In a fast-moving, high-stakes environment—as is now the case with AI-native product innovation—your ability to learn and deliver continuously becomes a competitive advantage. The Innowaring Flow principles offer a system for making that advantage real.
References:
Sidhu, A. (2023). Becoming a Software Company: Accelerating Business Success through Software. Apress.
Reinertsen, D. (2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Pub.
Silicon Valley Product Group (SVPG). (2024). Transformed: Moving to the Product Operating Model. Wiley.
This post is part of a series outlining my principles-first approach to AI-Native Product Innovation. Links to the previous posts (Part 1, Part 2, Part 3, Part 4)
The next post describes the Culture dimension of Innowaring.