Events, Patterns & Structure
What is a "system"? A system is just a set of parts that affect each other — users, teams, features, metrics, incentives. Change one part and the others react. Your product is a system, not a to-do list.
When something goes wrong, our instinct is to react to the single event we can see and move on. Systems thinking asks you to look below the waterline — because the same events keep coming back for reasons hidden underneath.
Everyday example
Think of a doctor. A patient keeps getting headaches. A weak doctor hands out a painkiller each visit (the event). A good doctor asks why they keep coming back — bad posture? Skipping meals? — and fixes that (the structure). One treats the symptom forever; the other ends it. PMs face the same choice every week.
The iceberg model — four levels to look at
1. Events — what just happened. "Checkout crashed this morning." This is the tip of the iceberg, the only part you see easily.
2. Patterns — the same event over time. "Checkout crashes every Monday at peak hours." Spotting the pattern is the first sign there's something deeper.
3. Structure — the setup that produces the pattern. "We never sized our servers for the Monday traffic spike." This is where lasting fixes live.
4. Mental models — the beliefs that built the structure. "We assumed traffic is roughly flat all week." Change the belief and you stop building broken structures.
React at the event level and you firefight forever. Change the structure and the events simply stop happening.
Quick check
Users keep filing the same complaint: they can't find the export button. The team keeps replying to each ticket individually. What's the systems-thinking move?