Why Do We Even Innovate?

I was co-teaching a Product Owner certification class recently with a group of fellow agilists when one of the POs asked a question that stopped the room for a second:

Why would we set aside time to innovate at the end of a PI when we innovate all the time during our sprints? We solve problems, we improve things, we find better ways to build constantly. Isn’t that already innovation?

It is a fair question, and the honest answer is that the PO was completely right about the premise and still missing the point. Teams really do innovate every single sprint. But the kind of innovation that happens inside a sprint and the kind that happens in a protected innovation period are not the same activity wearing two hats. They are two different things that we happen to file under the same word.

Sorting that out is the whole conversation. Think of it as the difference between tuning your race car during a pit stop and redesigning the engine in the R&D lab. Both are engineering. Only one of them can happen while the car is on the track.

The reframe: exploitation vs. exploration

The cleanest way I have found to answer the PO is to borrow a distinction from organizational theory: the difference between exploitation and exploration.

Exploitation is getting better at what you already do. Refining, optimizing, and squeezing more value out of the known. Exploration is searching for what you do not yet do. Trying things that might fail, that have no committed payoff, that move you somewhere new.

Both are valuable. The trap is that exploitation always feels more responsible in the moment, because it pays off now and it pays off predictably. Exploration pays off later, sometimes, maybe. So if you do not protect exploration deliberately, the daily gravity of delivery will quietly consume all of it. That is the mechanism the PO’s question was bumping into without naming it.

In-the-flow innovation is exploitation. Innovation periods are where exploration gets a home.

1. Value or Work-Based innovation

The in-the-flow kind

This is the innovation the PO was describing, and it is real. It happens organically during regular sprint execution, driven by the immediate need to deliver value or solve a problem sitting right in front of the team.

• When it happens: Continuously, woven into daily development.
• The focus: Incremental improvements to the product, architecture, or process that serve the current backlog.
• How it looks: A developer finds a cleaner way to code a feature, a tester automates a painful manual check while verifying a story, or the team refactors a messy module so a new feature runs faster.
• The driver: Efficiency and immediate value. The question being asked is, “How can we build this specific thing better, faster, or cheaper right now?”

Here is the part that matters for the PO’s question. Every bit of this innovation is in service of a commitment the team already made. It is bounded by the sprint goal. The moment an interesting idea would pull the team off the sprint goal, the sprint goal wins, and it should win, because that is what a sprint is for.

That boundary is a feature, not a flaw. But it has a consequence: sprint innovation can only ever explore the territory immediately adjacent to the work already on the board. You can make the horse and buggy lighter, faster, and cheaper to produce. You cannot stop building the buggy long enough to wonder whether the future is a car. There is no room in a committed sprint for an idea that has no committed payoff yet.

2. Innovation Period innovation

The dedicated sandbox

This is protected time, set at the boundary of a set of sprints, where the team is explicitly released from backlog commitments. In SAFe this is the Innovation and Planning (IP) iteration; elsewhere it shows up as hackathons, ShipIt days, or simply institutionalized slack.

• When it happens: A formally scheduled block, typically at the close of a PI or release cadence.
• The focus: Blue-sky exploration, new technology, or deep technical debt that needs uninterrupted attention.
• How it looks: The team spends two days prototyping a feature that is not on the roadmap, learning a new language, or restructuring a legacy database that no normal sprint would ever make room for.
• The driver: Exploration and psychological safety. The question being asked is, “What could we build if we were not worried about our current commitments?”

The reason this cannot just be folded into sprints comes down to two things, and both are worth saying out loud in a PO class.

First, committed work always crowds out uncommitted work. This is not a discipline problem you can coach away. As long as every hour of capacity has a story attached to it, exploration has nowhere to live except by either breaking the sprint goal or padding estimates to hide the time. One destroys predictability and the other destroys trust. A protected period is the only honest way to fund exploration without lying about velocity.

Second, a system run at full utilization has no capacity for the unplanned, and exploration is unplanned by definition. A team booked to one hundred percent on committed stories has zero slack, and slack is precisely what flow and discovery require. The IP iteration is institutionalized slack. In SAFe it also does double duty as the cadence point for PI planning, the system demo, and the Inspect and Adapt, which is why it reads as responsible rather than indulgent. It is the buffer that makes the rest of the PI predictable and the one place big-swing innovation is allowed to fail safely.

The discussed answer

The short version: during a sprint you innovate in order to meet your commitments. During an innovation period you innovate freed from them. The first can never replace the second, because the entire value of the second is the absence of the constraint that defines the first.

And here is the part that should land for a product owner specifically, whose whole job is to maximize value. The innovation period is not time stolen from value delivery. It is the mechanism that protects value delivery over the long run. It is what keeps a team from optimizing its way into a local maximum, refining the buggy to perfection right up until the market switches to cars. It pays down the technical debt that quietly strangles velocity. And it addresses burnout, which is itself a delivery risk. Skipping it does not buy you more value. It just borrows that value from a future PI at a bad interest rate.

Mapping the Innovation Landscape

There is a famous quote attributed to Henry Ford that perfectly captures the trap of pure efficiency:

If I had asked people what they wanted, they would have said faster horses.

Whether Ford actually said it or not, the underlying truth is solid. When you are buried in the day-to-day mechanics of running an iteration, or executing a sprint backlog, your field of vision naturally narrows. You focus entirely on optimizing the system you already have. You look at the horse and buggy and find clever ways to make it lighter, stronger, and faster.

In organizational theory, this is called exploitation, and it is exactly what “in-the-flow” sprint innovation does. It climbs the nearest hill of value. The catch? Once you reach the top of that local hill, no amount of incremental optimization will ever show you how to build a car. To find the car, you have to stop looking at the buggy, leave the safety of your current peak, and risk wandering through the valleys of the uncommitted to find a taller hill. That is exploration, and it requires a protected sandbox.

The interactive simulation below visualizes this exact landscape.

Use the controls below to toggle between Sprints Only (pure exploitation) and Sprints + Innovation Periods (exploitation mixed with regular intervals of exploration).

• The Terrain: Represents your product’s potential value. The lower hill on the left is the finely tuned “Horse & Buggy” (a local maximum). The higher hill on the right is “The Car” (the global maximum).
• The Blue Marker (Work/Delivery): Represents your core delivery team. They move along the actual contours of the curve, banking predictable, hard-earned value.
• The Orange Marker (Innovation Scout): Represents the risk-free exploration of an innovation period. They can leap across the map to prototype unproven ideas without forcing the delivery team to abandon their current commitments.

Side-by-Side Comparison

The Golden Rule: Work-based innovation keeps your product healthy and efficient, while innovation periods keep your team creative and forward-thinking. If you only do the former, you will build a beautifully optimized horse and buggy instead of inventing the car. If you only do the latter, you will have brilliant ideas and never ship them. The answer is not to cut innovation, it is to understand that you are funding two different futures, and you need both.