Why wicked problems are not an obstacle to change — they are the precondition for it.
Most organizational transformations fail before they begin.
Not because the methodology is wrong. Not because the people lack capability. Not because leadership is unsupportive.
They fail because the problem was chosen for convenience rather than consequence.
A problem that is manageable, contained, and politically safe will produce a pilot that is manageable, contained, and politically ignored. The organization will note the result, nod politely, and return to doing what it was doing before. The new approach never takes root. Not because it didn’t work — but because the conditions were never right for it to matter.
This is the selection problem at the heart of most transformation programs. And solving it requires a counterintuitive move: you need to find problems that are genuinely, visibly, embarrassingly hard.
The image in front of you is not a methodology. It is a sequence — and the sequence is everything.
Every child who learns to ride a bicycle does so in the same order: first the stabilisers and the steadying hand, then the wobbling independence, then the moment balance clicks into place without anyone being able to say exactly when it happened. Nobody has ever learned to ride by first studying gyroscopic physics. The knowledge arrives last, and when it does, it lands on lived experience rather than abstract air — which is the only surface it can actually stick to.
Most large enterprises do not lack operating models. They lack operating behavior.
Over the past decade I have participated in several transformations where the structure was redesigned with care. Value streams defined. Product trios introduced. Governance simplified. Decision forums clarified. On paper the system looked healthy. And yet — six to nine months later — the organization was still escalating decisions upward. Teams still protected pet initiatives. Roadmaps were still treated as commitments rather than hypotheses.
The diagram had changed. The reflexes had not.
That gap between structure and behavior is where most product operating models quietly fail — and it fails for a reason that is worth stating directly before we go any further.
The conventional sequence most transformation programs follow is what we call KAP: Knowledge, Application, Practice. Teach the framework. Run the workshop. Simulate the conditions. Hope the behavior follows. It produces organizations that understand the methodology but cannot execute it under pressure, because understanding and doing are built in different parts of the body.
The Five Mindset Sprint is a deliberate inversion of that sequence. The first act is not training. It is problem selection. Find a problem that is genuinely painful, genuinely stuck, and genuinely cross-functional — the kind that Rittel and Webber in 1973 would recognize as a Wicked Problem: systemic, previously attempted, owned by nobody, and felt by everybody. That profile is not a warning sign. It is the precondition for change that actually holds.
Put a small team to work on that problem in real conditions, with real stakes and real consequences. Run the Monday–Friday sprint arc — Empathy, Ideation, Recombination, Prototyping, Storytelling — not as a workshop about those things, but as a lived experience of them. This is PAK: Practice first. Application follows. Knowledge consolidates last. The language arrives after the experience, which is the only order in which it genuinely lands.
To clear what we call the 9x Threshold — the combined weight of institutional trust, familiarity, and ramp-phase friction that any new approach must overcome — the problem you select must be painful enough that even a moderately successful intervention feels like significant relief. Mild problems cannot carry that weight. Wicked problems can.
The result is not a team that has been trained. It is a team that has been changed. And because the change happened on a problem the organization already cared about solving, the new behavior arrives with a story attached — a result that can be pointed to, an experience that can be passed on, a proof that does not need to be argued because it has already been lived.
What follows in this article is a deeper look at each of these elements in turn — what makes a problem genuinely wicked, why the 9x threshold matters for how you select it, what the sprint arc actually does inside an organization, and why PAK is not just a learning model but a theory of change. Each section stands on its own. But they are all describing the same bicycle.
What Makes a Problem Worth Solving
The wicked problem you should celebrate when you find it – difficult and very visible relief when solved
Over the years I have developed a specific set of criteria for identifying what I call wicked problems — borrowing the term from design theorists Horst Rittel and Melvin Webber, who first formally described the concept in their landmark 1973 paper, Dilemmas in a General Theory of Planning (Policy Sciences, Vol. 4). Rittel and Webber were writing about social policy, but their insight travels directly into organizational life: wicked problems are not simply difficult problems. They are problems that resist resolution by their very nature — systemic, ambiguous, cross-functional, with no definitive formulation and no clean test of whether a solution has worked.
My working definition for organizational wicked problems adds a layer of practical specificity. A wicked problem, as I use the term, has five characteristics.
It is systemic. The problem does not sit in one team or one function. It has roots in multiple places simultaneously — in governance, in tooling, in incentives, in culture — and addressing any single root in isolation produces only partial relief.
It has been tried before. The organization has already attempted to solve it, perhaps several times. Those attempts have left traces: a failed initiative, a shelved framework, a reorganization that changed the structure but not the behavior.
It is cross-functional. No single leader owns it cleanly. It lives in the gaps between functions, which is precisely why it has survived. Everyone is affected. No one is fully accountable.
Both internal and external voices have acknowledged it. Consultants have named it. Benchmarking exercises have surfaced it. Internal audits or transformation reviews have recorded it. There is shared awareness that this is a real, persistent difficulty.
The pain is felt and recognized, not just documented. The people inside the system know it hurts. They do not need to be convinced the problem exists. They have been living with it.
Problems with this profile are extremely difficult.
They are also, for exactly that reason, extraordinarily valuable.
The 9x Threshold
There is a principle I encountered early in my career that has shaped how I think about introducing new approaches into existing organizations.
For a new product to displace an established one, it typically needs to be roughly ten times better — not twice as good, not three times as good. Ten times.
The logic is sobering. A new solution carries no organizational memory, no earned trust, no legacy of having worked before. That absence costs approximately three times in perceived value — the incumbent has institutional equity the newcomer does not. On top of that, any new approach will underperform during the ramp phase: the period when people are still learning it, when it has not yet been adapted to the specific context, when the rough edges have not yet been smoothed. That costs another three times. Multiply those two penalties and you understand why being marginally better is never enough.
To truly take root in the lived life of a real organization, a new method, tool, or operating model needs to be remarkably better — viscerally, undeniably better in a way that people inside the system experience directly.
This is why problem selection is a strategic act, not an administrative one.
If you choose a mild problem — one where the current approach is inconvenient but tolerable — your new approach will face the full weight of institutional inertia while offering only moderate relief. The math will not work in your favor.
If you choose a genuinely wicked problem — one where the current situation is painful, recognized, and has already defeated previous attempts — you are playing an entirely different game. You are not asking the organization to try something new for marginal gain. You are offering meaningful relief to something that is actively hurting. The 9x threshold becomes achievable because the baseline is low enough, and the pain real enough, that a well-executed intervention can clear it.
The Patient and the Doctor
I find myself returning often to a healthcare metaphor when explaining this selection logic to clients.
Imagine the organization is a patient. The transformation manager is the doctor.
The doctor is not interested in treating patients who feel fine. A patient who feels fine will not comply with the treatment, will not change their habits, will not tolerate the discomfort that recovery sometimes requires. They will nod, take the prescription home, and never fill it.
But the doctor is equally not interested in patients who are too far gone — where the illness has progressed beyond the point where intervention can produce a good outcome. A first treatment that fails is not just a setback. It is a story the organization will tell for years: a scar tissue of cynicism that makes the next attempt harder.
The patient we are looking for is ill enough that they genuinely want to be cured — the symptoms are visible, the discomfort is real, the motivation to change is present. And healthy enough that recovery is possible — the organizational immune system is still functioning, there are people with the energy and authority to support the intervention, and success within a reasonable timeframe is genuinely achievable.
That zone — between “not sick enough to care” and “too sick to save” — is where transformation actually works.
Finding it requires diagnostic skill. It requires the ability to read an organization’s honest signals rather than its official ones. It requires conversations that go past the polished problem statements in the strategy deck and into the frustrated, unfiltered accounts of the people actually living the dysfunction.
Five Hundred Epics: A Case Study in Problem Selection
A few years ago I gave a talk in Aarhus on systematic design thinking. In the audience — though I did not know it at the time — was a small scouting group from one of Denmark’s largest toy manufacturers. They had been sent specifically to assess whether what I was describing could solve a problem their organization had quietly recognized as serious.
The problem: they were running SAFe — Scaled Agile Framework for Enterprises — and their epic generation process had gone completely off the rails. Five hundred epics sat in a shared backlog with no meaningful prioritization, no shared understanding of what most of them actually represented, and no credible path to delivery.
They had production capacity. They had engineering muscle. They had an operating model with well-defined ceremonies and governance structures.
What they lacked was product discovery — and underneath that, something more fundamental: nobody had clear authority to say no. The word “epic” meant something different to product management, to engineering, and to portfolio governance. So the pile grew, and nobody touched it, because touching it meant making decisions the system had not equipped anyone to make.
This was a wicked problem by every criterion: systemic, previously attempted, cross-functional, externally recognized, and — critically — painful enough that the people inside it were genuinely motivated to find a way through. The scouting group was not there for transformation tourism. They were there because they were hurting, and they recognized it.
That recognition was the precondition for everything that followed.
The Five Mindset Sprint: Practice as the Intervention
We agreed to run a series of Five Mindset Sprints — a structured weekly cadence designed not to teach a methodology but to install it through use.
Each sprint followed the same arc, deliberately structured to build capability through doing:
Monday — Empathy. Not a workshop about empathy. Actual contact with the problem space: the people closest to the pain, the friction, the workarounds. The goal was to arrive at Tuesday with real questions rather than inherited assumptions.
Tuesday — Ideation. Systematic generation of responses to Monday’s questions. The discipline was to separate generating from evaluating — to hold the pressure toward premature convergence at bay long enough to surface ideas the system would normally filter out before they were spoken.
Wednesday — Filtering and Recombination. Ideas from Tuesday were not simply ranked. They were stress-tested and combined into solution frameworks. This day consistently surprised participants, because good solutions rarely resembled any single Tuesday idea. They were composites built from the intersection of things that did not obviously belong together.
Thursday — Rapid Prototyping. Not full builds. Enough fidelity to make the solution tangible — enough to be wrong in specific, useful ways.
Friday — Storytelling. The hardest day. The sprint team had to construct a narrative that could travel through the organization without its authors in the room — one that earned alignment through the clarity of its argument rather than the authority of whoever was presenting it.
What emerged on Fridays consistently defied the expectations participants had brought on Monday. The solutions were almost never purely digital. They were almost always a combination: an organizational adjustment, a governance change, a tooling remake. The epic problem, examined through the sprint, turned out not to be a backlog management problem at its core. It was a prioritization mandate problem wrapped around a shared language problem. You cannot fix that with a better tool. You fix it by giving someone the authority to decide, creating a shared vocabulary, and then — and only then — using tooling to operationalize the clarity you have created.
Read more on our Five Mindset Sprint services https://www.mckayconsulting.dk/five-mindsets-strategy-sprint/
PAK: Why Practice Must Come First
The logic of the Five Mindset Sprint reflects a principle I learned from Jerry Sternin — the renowned development practitioner and founder of the Positive Deviance approach, whose work with Save the Children in Vietnam in the 1990s produced one of the most important insights in applied behavioral change. Sternin observed that it is easier to act your way into a new way of thinking than to think your way into a new way of acting. That inversion — Practice, Application, Knowledge, in that order — is what I call the PAK sequence, and it runs directly counter to how most organizations approach capability building.
Most organizations deploy the reverse: KAP. Knowledge comes first — frameworks are introduced, theory is taught, case studies are studied. Application follows, in controlled settings that simulate but do not replicate real stakes. Practice, if it arrives at all, is scheduled last and cancelled first when delivery pressure reasserts itself.
KAP produces people who understand a methodology. PAK produces people who can use one.
The difference is not philosophical. It is structural. When you practice on a real problem — with real constraints, real consequences, and real people — the methodology is not introduced from outside. It is discovered from within. The sprint week becomes a lived experience that the concept of “design thinking” can later be attached to, because the person has already felt what it describes.
In the toy manufacturer engagement, nobody was being taught the Five Mindset framework. They were using it on five hundred epics that were genuinely obstructing their ability to work. By Friday of the first sprint, they had not only moved the problem — they had built a shared behavior for moving the next one.
That is what practice builds. That is what training, almost by definition, cannot. (read more on our PAK vs KAP article https://www.mckayconsulting.dk/pak-vs-kap/)
Why This Is the Right Way to Install a New Operating Model
The healthcare metaphor points toward something underappreciated in transformation practice.
We are not primarily in the business of introducing new ideas into organizations.
We are in the business of making new ideas feel more reliable than old ones — in conditions where old ideas have the full advantage of familiarity, trust, and institutional momentum.
The only way to do that is to demonstrate, visibly and credibly, that the new approach works on something that matters. Not a prototype problem. Not a sandbox exercise. A real problem, with real pain, where real people have already tried and failed to make progress.
When that demonstration succeeds, something important shifts. The new method does not need to be sold. It has a story. It has advocates inside the system who experienced it working. It has a result that can be pointed to when skeptics ask why anyone should try something different.
The 9x threshold is cleared — not through argument, but through evidence the organization itself generated.
Carefully chosen problems are the first act of any serious change effort. The sprint, the methodology, the framework — these come second. What comes first is the diagnostic work of finding the organization’s version of five hundred epics: the problem that is real enough, painful enough, cross-functional enough, and ripe enough that solving it changes the belief system, not just the backlog.
Find that problem.
Solve it visibly.
Let the organization tell the story.
That is how new operating models take root in the lived life of real organizations.
We began with a child on a bicycle, and we should end there too — because the metaphor has more to give than it first appears.
Think about what the parent is actually doing in that first scene. They are not teaching cycling. There is no lesson. There is no framework being transmitted. The parent’s hand on the back of the seat is not delivering information — it is reducing the consequence of falling just enough that the child stays willing to keep trying. The stabilisers are not a simplified version of the skill. They are permission to practice before mastery.
This is precisely the role of a well-chosen Wicked Problem in organizational change. It is the stabiliser. It reduces the consequence of the new approach being imperfect — because the existing situation is already painful enough that imperfect relief is still relief. It keeps the organization willing to keep trying.
At some point the stabilisers come off. Nobody can tell you exactly when that moment is right. It requires the diagnostic judgment we described earlier — reading the organization’s honest signals, finding the zone between too comfortable to change and too broken to recover. The patient who is ill enough to want to heal, but healthy enough to survive the treatment. Get that selection right, and the sprint does its work. Get it wrong, and no methodology in the world will compensate.
And then there is the final scene — the figure who has stopped at the side of the road, bicycle beside them, looking at it with the calm recognition of someone who now understands the physics of what their body has known for years. The gyroscopic effect. The centripetal force. The pressurized tubes. The aerodynamic drag. All of it was operating from the very first wobble. None of it needed to be understood before the riding could begin.
This is what Knowledge consolidating last actually means in the life of an organization. It is not that theory is unimportant. It is that theory received before experience is decoration — interesting, perhaps even inspiring, but not yet load-bearing. The same frameworks that produce glazed eyes in a training room produce genuine recognition in a team that has just run their first sprint on a real problem. The words land differently when they are naming something the body already knows.
Jerry Sternin spent decades working in communities where the solutions to devastating problems already existed inside those communities — invisible, unrecognised, waiting to be discovered by people willing to look for what was already working rather than importing what worked elsewhere. His formulation was simple and remains unrepeatable: it is easier to act your way into a new way of thinking than to think your way into a new way of acting. That is PAK. That is the bicycle. That is the only sequence that actually works.
You cannot teach someone to ride a bicycle.
You can give them a bicycle, a safe road, a problem worth solving, and enough steadying to find balance themselves.
Everything else — the frameworks, the models, the language, the theory — follows from that. And when it follows, it sticks.
Further reading:
- Rittel, H.W.J. & Webber, M.M. (1973). Dilemmas in a general theory of planning. Policy Sciences, 4(2), 155–169.
- Pascale, R., Sternin, J. & Sternin, M. (2010). The Power of Positive Deviance: How Unlikely Innovators Solve the World’s Toughest Problems. Harvard Business Press.
Leave a Reply