How to be great at systems thinking

This Dive Club episode turns “systems thinking” from a hiring-interview buzzword into something practical for product designers, drawing on designers from Notion, Anthropic, Asana, and Maven. The throughline: don’t solve each problem in isolation — build with a small set of primitives that compound, keep the whole system in view, and learn to sell those ideas to the business.

Key lessons

#

• Connection over polish. What separates great designers isn’t beautiful animations but understanding how things connect — even a note-taking app hides serious depth.
• Build with blocks, not features. Solving each problem in isolation spawns a new single-purpose block every time; the goal is the fewest unique blocks doing the most.
• Local solution vs. primitive. A quick fix solves today’s problem; a primitive is a compounding abstraction others can build on — and abstracting the right one is the designer’s real job.
• Zoom out to stay simple. Considering the full system, anticipating future use cases, and collaborating across teams is what preserves simplicity as surface area grows.
• Sell in the language of business. Buy-in comes from leading with ROI; the more surface area an idea touches, the more people get excited about it.

Annotations

#

00:00:00 — Systems thinking over beautiful animations

Balint, co-founder of CraftDocs, names systems thinking as the single most important quality he looks for when hiring a designer — above the ability to make “beautiful animations” and screens “you want to lick.” His point is that even something as modest as a note-taking app hides serious depth, and once you start to untangle how everything connects, the problem reveals itself. The host admits his knee-jerk reaction is “yeah, I checked that box,” which sets up the episode’s goal: making the much-invoked idea of systems thinking concrete and practical.

00:01:09 — Notion’s blocks: fewest parts, most uses

Ryo Liu — now head of design at Cursor, and one of the earliest designers at Notion — frames systems thinking as building with blocks. When a product serves many groups and use cases, you can’t optimize for one path; you need systems that tie together different mental models and workflows out of the same shared primitives. Solving each problem in isolation spawns a new single-purpose block for every solution, which only makes the system more complex. The best designers instead dig to root-level issues and anticipate future needs, so success becomes solving the broader product puzzle with the fewest unique blocks — the fewest parts doing the most, a way of multiplying value rather than just adding it. This leads into Joel Lewenstein, head of product design at Anthropic, who argues the best features are simple abstractions that grow to solve future problems.

00:03:32 — Local solution versus reusable primitive

Using Claude’s artifacts as a running example, Joel Lewenstein contrasts a “local solution” with a “primitive.” A collapse button that merely hides long documents in the chat solves the immediate problem but is not a compounding, abstract concept you can build on — whereas the right abstraction becomes a primitive in the product. The host loves this distinction because design projects almost always begin as a local problem, and the real job is to abstract the right primitive, which often demands cross-team collaboration. He connects it to Kat Small’s framing at Asana of two archetypes: the architect who designs the complex system, and the platformer who makes that system usable and dependable for other people.

00:04:59 — Zoom out to preserve simplicity

Continuing the Asana example of mapping how a project contributes to a goal, the discussion turns to representing those relationships as components within a system rather than one-off screens. The host generalizes the lesson: zooming out to consider the whole system is what preserves simplicity as your feature surface area grows. He illustrates it with his own work on settings at Maven — he could have designed those screens in isolation, but anticipating that the same actions would later surface in onboarding checklists and in modals on other pages, he built an interoperable component system flexible enough for uses he hadn’t yet imagined.

00:05:50 — Designers surface the future a solution opens

Returning to Joel Lewenstein, the host stresses that systems thinking is much more than components: part of the designer’s job is to point at the future a given solution unlocks. With artifacts, that future might mean helping people write code better, visualizing code, supporting multiple files, or dynamic editing where you engage both the chat and the document at once. The goal isn’t only to find the right solution, but the solution that becomes a Lego piece — a building block others can compound on. As the host puts it, choosing those building blocks is how strategy itself gets shaped.

00:08:11 — Sell ideas in the language of business

The final thread shifts from building systems to selling them: getting buy-in by translating design ideas into the language of the business and leading with a feature’s ROI. The host recounts trying to redesign the syllabus editor at Maven for two whole years and failing repeatedly — until his breakthrough came from showing how the redesign could unlock new marketing opportunities for instructors, such as letting students preview lessons on the landing page. The broader principle: the more surface area an idea touches, the more people can see how it affects their slice of the product and the more of them get excited about it. He closes with Kathy Zhang’s backstory of GitHub Sponsors, which began as a plain question — how do people set up funding? — whose vehicle turned out to be a YAML file in your repo, clearly a building block for something bigger.