Discover-Invent-Produce-Generalise
The learning cycle that explains how teams actually learn — not just how they get things done.
Most teams treat learning as something that happens to individuals. Someone reads a book. Someone goes on a course. Someone “picks things up” on the job. The team gets better, or doesn’t, depending on whether enough individuals happen to learn the right things at the right time.
Chris Argyris had a different view. He argued that learning is something organisations do — or fail to do — as a structural property of how they work. And he gave it a shape: a four-stage cycle that runs continuously when the conditions are right, and breaks down when they aren’t.
The cycle is called Discover-Invent-Produce-Generalise.
Where it comes from
Argyris developed the model across a long body of work, most clearly in his 1976 and 1995 papers on organisational learning. He was trying to answer a question that should be uncomfortable for any business owner: why do smart, well-intentioned people, working hard, often produce no learning at all?
His answer was that learning isn’t automatic. It requires a specific sequence of moves — and most workplaces interrupt the sequence before it can complete.
In my PhD research with Australian small and medium business owners, this model turned out to be one of the most useful lenses for understanding why some teams kept improving year after year while others, working just as hard, kept making the same mistakes in new shapes.
Discover
This is where learning begins — by noticing that something isn’t working.
That sounds obvious. It isn’t. Most teams don’t actually discover problems. They explain them away. The product launch underperformed because the market wasn’t ready. The good hire quit because they weren’t a culture fit. The same complaint keeps coming back because customers don’t understand the product.
Discover means looking at what’s actually happening — not the story you’ve already built about what’s happening — and being willing to be surprised. In practice this requires two things: feedback you can trust, and a habit of reflecting on it instead of defending against it.
In my PhD research, the founders who were good at this stage didn’t have better information. They had cleaner reactions to information. When something didn’t work, they wanted to know why. When someone disagreed with them, they wanted to know what the disagreement was pointing at. They treated problems as information, not as accusations.
Invent
Once you’ve seen the problem clearly, the next step is to invent a response.
This is where most teams jump too quickly. Someone has an idea, the idea sounds good, and the team starts executing. The trouble is that the first idea is usually the most obvious one — and the most obvious idea is usually a version of what you were doing already.
Invent, done well, is collaborative. It pulls in different people with different perspectives, on purpose, to make sure the response isn’t just the loudest person’s instinct. The point isn’t consensus — the point is to surface ideas the team wouldn’t have arrived at alone.
This is also where assumptions get tested. If the discover stage was honest, the invent stage will often surface a deeper version of the problem than the one you started with. That’s the signal it’s working.
Transformation Zone
This is the stage Argyris didn’t name, but Dr. Rod Gapp later argued was the most important one.
Their argument was simple. The original Argyris cycle — discover, invent, produce, generalise — describes what learning teams do. But it doesn’t explain the hardest move in the cycle: the move from invent to produce. From an idea you’ve discussed in a meeting to a thing you’re actually doing in the world.
In my thesis, I called that move the Transformation Zone.
What sits inside it is the moment when an espoused-theory becomes a theory-in-use. In plain language: when what you say you’re going to do becomes what you actually do. That sounds trivial. In practice, it’s where most organisational learning quietly dies.
A team can have a brilliant invent stage — diverse perspectives, a clear redefinition of the problem, broad agreement on what to try next — and produce nothing real, because the gap between the idea and the action is too wide for any individual to cross alone. People go back to their desks. The work resumes. The new idea quietly gets reabsorbed into the old way of doing things.
What gets a team across the Transformation Zone isn’t willpower. It’s two specific conditions.
The first is collaboration that survives contact with reality. The same people who shaped the idea need to test it together, not separately. When testing happens in collaboration, the discrepancies — the small early signals that the idea is wrong, or needs adjustment — surface fast enough to be useful. When testing happens in isolation, those signals get filed under “my problem, I’ll figure it out,” and the lessons never reach the rest of the team.
The second is dissonance. The team needs to be able to notice — and name — the gap between what they thought they were doing and what they’re actually doing. Without that, the produce stage just becomes a polished version of the original idea, regardless of what reality is saying back.
This is the stage where deeper understanding of the problem actually emerges. Not in the discover stage, where the problem is first noticed, but here, where the team finds out what the problem looks like when they try to do something about it. Most teams discover the problem they thought they had. The Transformation Zone is where they discover the problem they actually have.
In my PhD research, the businesses that moved fastest weren’t the ones with the best ideas. They were the ones that had built the conditions to cross the Transformation Zone repeatedly, without losing momentum each time.
Produce
Now the idea becomes real.
Produce is where strategies and tactics get developed and deployed. Something that existed as a concept becomes a thing the team is actually doing. This is the stage that looks like work to most people — and it is — but the work is meaningless unless the previous two stages were honest.
A well-invented response, produced clumsily, can still teach you something. A poorly-invented response, produced brilliantly, will give you a polished version of the wrong answer.
What matters in this stage is keeping the connection back to the original problem. As the work gets technical, it’s easy to forget what you were trying to learn about. The teams that get the most out of produce are the ones that hold onto the question — did this actually address what we discovered? — all the way through.
Generalise
This is the stage almost every team skips.
Generalise means taking what you learned in one situation and asking where else it applies. The discovery wasn’t just about this product, this customer, this hire. The pattern you uncovered — about why your team makes certain mistakes, or why a particular kind of conversation keeps going wrong — almost certainly shows up elsewhere.
Generalise is what turns a one-off win into a capability. Without it, every problem feels new, because the lesson from the last one never travelled.
It also feeds the next cycle. The generalised understanding from one loop becomes the starting point for the next discover stage. The team isn’t starting from scratch — it’s starting from a slightly truer picture of how its work actually works.
This is what Argyris meant when he said the cycle is continuous. Generalise isn’t the finish line. It’s the on-ramp.
Why the cycle matters more than any single stage
The four stages aren’t equally hard. Most teams can do at least one of them reasonably well — the produce stage is usually the strongest, because that’s what looks like work. The weakness is almost always in the others, and almost always in the same pattern: thin discovery, rushed invention, no generalisation.
When that happens, the team gets stuck in something that looks like learning but isn’t. They produce a lot. They change a lot. But they don’t get any wiser about how their own work actually works. The same problems keep coming back in slightly different shapes.
When the full cycle runs — when the team genuinely discovers, genuinely invents, produces against the actual problem, and generalises what they learned — something different happens. The work compounds. Each loop makes the next one shorter, because the team is no longer starting from zero.
A small example
One founder I spoke with in the research had spent eight years on the same problem. From the outside it looked like a straight line. From inside, it was a series of cycles.
The first cycle ran for three years. The team tried five different projects. Most failed. The generalisation from that loop wasn’t which project worked — it was a clearer sense of what kind of problem they were actually trying to solve. That clarity was what made the second cycle possible.
By the time they reached venture capital funding, they’d been through the full cycle several times — each iteration shorter, each one informed by what the last had revealed, and each one only possible because they’d built the conditions to cross the Transformation Zone without the team fracturing.
What kept them moving wasn’t talent or luck. It was the discipline of completing the cycle rather than just running the produce stage harder.
Where this fits
Discover-Invent-Produce-Generalise is the macro learning cycle.
It runs alongside the PDSA Cycle — Deming’s micro improvement cycle — which handles the smaller, faster loops inside any given project. PDSA is what you run inside a sprint. DIPG is what you run across a year.
It’s also the engine of Single-Loop vs Double-Loop Learning. Single-loop teams stop at produce — they fix the immediate thing and move on. Double-loop teams complete the generalise stage, which is where the underlying assumption actually gets questioned.
Both cycles sit inside the Gapp-Fisher Model, which adds the Transformation Zone to Argyris’s original cycle to explain how espoused ideas actually become real practice.
Sources
The cycle was developed by Chris Argyris across multiple works, most directly in Single-Loop and Double-Loop Models in Research on Decision Making (1976) and Action Science and Organizational Learning (1995). The application to small and medium business contexts comes from my PhD research at Griffith University (2021) and from Medina, Gapp & Stewart (2021), Organization Development Journal.