Cynefin and Complexity in a Nutshell

Most product organisations do not fail for lack of talent or effort. They fail because they bring the wrong kind of thinking to the kind of problem in front of them. Cynefin is the fastest way I know to see which kind you are holding. I will explain it with a pizza business, because I once ran product for one, and a single Friday night there contains all four kinds.

Cynefin is a Welsh word, pronounced roughly kuh-NEV-in, meaning the place of your many belongings. The framework is Dave Snowden's, and the point of it is simple: problems come in different kinds, each kind has a different way of working that suits it, and most of the damage in organisations is done by using the wrong one. Everything below stands on his work, with a pizza business laid over the top.

Four Kinds of Problem, One Friday Night

Cynefin, as a pizza business. The framework is Dave Snowden's. The pizzas are from a former life.

Clear. Making the pizza. Cause and effect are obvious to everyone, the right answer is the same each time, and best practice exists. You sense an order, you categorise it as a margherita, you follow the spec. Write it down, make a checklist, automate what you can. The danger in Clear is complacency. Treat a changing situation as routine and you fall off the cliff at the bottom of the diagram, straight into Chaotic. Assume this Friday will behave like last Friday, run the store on autopilot, and you will meet the cliff at about seven o'clock.

Complicated. Staffing a predictably busy day. Friday is always busy, the football fixtures are published, the weather forecast is public. An analyst can forecast the volume to within a reasonable margin, a manager can staff and prep for it, and the same method works again next week. It takes expertise and analysis, there may be more than one good answer, and the answer is repeatable. You sense, you analyse, you respond. This is the land of experts and good practice. Most of engineering lives here, and so does most of what we are taught to call management.

Complex. The phones on that same Friday night. The day was predictable; the orders were not. People were calling in to order, and other people were calling in to find out where their pizza was, on the same lines, to the same staff. The kitchen was being asked for information and given information in a constant stop-start, and every interruption changed what the next caller needed. Nobody controlled it, and cause and effect were only visible looking backwards. You cannot staff your way out of that, because the problem is not volume, it is interaction. The only way to work here is to probe, sense and respond: try small, safe-to-fail things in a few stores, watch what the system does, amplify what works and dampen what does not. We chose to start with the Pizza Tracker for exactly this reason: order status was a wicked, two-sided problem, a business problem and a customer problem at once, and telling people where their pizza was before they thought to ring was the probe that changed the whole system. It came out of that kind of probing, not out of a plan.

Chaotic. The queue has broken. The phones never stop, orders are being lost, and at seven o'clock the system goes down. No time for analysis, no patterns to read. You act first to stop the bleeding, then sense what is left, then respond by moving the situation somewhere calmer as fast as you can. Chaos is where decisive leadership is right, and also where it becomes a habit that follows people back into problems that needed patience instead.

Confused. The middle. The Monday meeting in which nobody has asked which of the four kinds of problem is on the table, which usually means each person is about to apply whichever one they personally prefer. This is the most common state in a leadership team and the least often named.

Complexity Theory, in the Same Business

Complexity theory is the science underneath the top-left square, and three ideas from it do most of the work for product people.

Emergence. The behaviour of the whole cannot be predicted from the parts. A Friday night is not the sum of the orders on the forecast; it is what the orders and the enquiries do to each other. A product organisation's output is not the sum of its headcount. You cannot decompose a complex system into a plan and reassemble the pieces.

Retrospective coherence. Afterwards, everything looks like it made sense. The story of why the Pizza Tracker changed the kitchen writes itself a year later and was unknowable at the time. This is why post-launch case studies are so confident and so useless as recipes, and why a roadmap that explains the past is not evidence it can predict the future.

Constraints over controls. You do not manage a complex system by telling it what to do. You manage it by shaping the conditions: the store standards, what a manager may decide without asking, and whether the customer can answer their own question before they pick up the phone. Snowden calls these enabling constraints, as opposed to the governing constraints that work in Complicated. In product terms: a team charter, a decision right and a kill criterion are enabling constraints. A Gantt chart is a governing constraint, applied to a Friday night.

Why This Matters More Than Any Framework I Teach

Here is the pattern I see in almost every product organisation I assess. The real problems, the ones involving customers, markets, teams and now AI, are complex. The organisation treats them as complicated. It hires experts, writes a detailed plan, sets a date, tracks the plan, and is baffled when the market does something else. Then it blames the people in the stores.

Almost every tool I use is an attempt to get people to work in the square where they actually stand.

Discovery is probe, sense, respond with a notebook. Customer interviews are safe-to-fail probes. If your discovery produces a plan rather than a next probe, it has quietly moved to Complicated.
Kill criteria are the sense step written down in advance, so that when the market answers, somebody is obliged to listen.
Small bets with persistent teams instead of big projects: many probes, cheap to lose, instead of one plan, expensive to be wrong.
Flow over velocity: in a complex system you manage the conditions that let work move, not the promise of when it arrives.
Retrospectives that ask what we noticed, not whose fault it was. Blame is a Complicated-domain habit that poisons a Complex-domain team.

And Then There Is AI

AI products are complex systems built on top of complex systems. The model's behaviour emerges from data nobody fully read, the customers' behaviour emerges in response, and cause and effect are visible only backwards. This is exactly why accuracy on the eval tells you so little, why the failure state matters more than the model, and why trust is something you tend rather than ship. Treating an AI feature as a Complicated engineering deliverable, with a spec and a date, is the single most expensive category error I watch leadership teams make right now.

How to Use It on Monday

Take the three biggest things on your plate. For each, ask honestly where it sits. Then ask where your plan for it belongs. Where the two disagree, that is the finding. Most leadership teams find at least one complex problem being managed as complicated, and one clear problem being over-thought because it is interesting. Fix the first before the second.

And when you cannot tell which square you are in, say so out loud. Naming Confused is the fastest route out of it.

Companion pieces: Flow in a Nutshell is the physics of the complex square. Measuring AI Outcomes is probe, sense, respond applied to a model in production. The Opportunity Brief and the Discovery Interview Kit are safe-to-fail probes you can print. Cynefin itself is Dave Snowden's work, and the best next read is his own writing at The Cynefin Co.

Free to share, with attribution.More Field Notes · Freebies · How I Can Help