Every company is a dependency graph. One useful projection is a tree that alternates what and how.
Each node states a what (the problem or goal). Its children are the hows (approaches that could achieve it). Each how becomes the next layer's what, repeating until the leaves: product surfaces, workflows, policies, codepaths, contracts, UI decisions, and operating routines.
Mapped onto a typical company:
- Vision: the highest-level what—what you want the world to look like.
- Strategy: the how for that vision, and therefore the next layer's what: what you will and won't do.
- Organization: the how for strategy—how work and decisions are structured.
- Artifacts: the how made concrete—the things users and employees can point to.
The value of this view: at every layer, you can ask, "What must be true for this how to solve the what above it?" If you can draw the dependencies, you can reason about a business the way you reason about a system.
This is also a useful way to describe product management: making explicit edits to the graph.
- Add nodes and edges to surface assumptions and connect solutions to the problems they claim to solve.
- Remove edges when a dependency turns out to be unnecessary or false.
- Rewire subgraphs when you change decomposition (re-org, re-architecture, new go-to-market) without changing the root goal.
- Prune subtrees that don't justify their complexity.
- Reweight edges as evidence arrives (experiments, incidents, customer behavior, regulation).
Prioritization is choosing which part of the graph to expand under constraints. A roadmap is a sequence of edits you believe will increase value at the leaves while keeping the trunk stable.
Dependencies point upward. Leaves depend on branches. Teams depend on strategies. Strategies depend on beliefs about how the world works.
Some beliefs are close to facts: "Settlement takes time." "Retail order flow can be routed." "Margin amplifies both gains and losses." Others are hypotheses: "People want investing to feel as easy as checking a bank balance." "A simple interface will expand participation more than it increases blow-ups." The difference is confidence—and confidence should change with evidence.
Example: Robinhood
- Vision: democratize access to financial markets.
- Strategy: reduce friction, remove fees, make participation emotionally and operationally easy.
- Organization: consumer product, growth, payments and clearing infrastructure, regulatory and legal, risk management.
- Artifacts: mobile-first interface, fast onboarding, fractional shares, instant deposits, options and margin, notifications, and a system that routes and settles trades within the constraints of market plumbing.
Below is an example diagram generated by AI—not "the truth," but a faithful attempt to write down what is usually left implicit. (Grounded in Robinhood's Form 10-Q for Q1 2025.)
Companies fail in ways that feel confusing from the outside.
People point at a leaf: "The UI is too gamified." "Risk controls weren't enough." "Growth overwhelmed ops." But the real disagreement lives higher in the tree—in what the company believed about human behavior, incentives, and second-order effects.
Trace the dependency chain upward and the failure becomes interpretable. A leaf broke because a branch was too thin. A branch snapped because a belief was untrue. A belief went untested because the organization optimized a local subtree at the expense of the trunk.
Most companies don't explicitly state their dependencies. They have slide decks, slogans, and org charts—but not a shared dependency graph.
Two smart employees can both be "aligned with the vision" and still build incompatible subtrees. They're operating with different implicit beliefs. The artifacts ship, but the company drifts.
You can measure alignment by how well individuals reconstruct the same tree. In a tight company, ask five people: "Why do we exist? What must be true? What are we optimizing for? What are we building next?" You get the same structure with small variations. In a loose company, you get five different trees that share only a title.
Once you see companies as trees, you read them differently.
A product decision—ask which belief it depends on. An org design choice—ask what strategy it executes. A sudden pivot—ask which belief got disproven. A company that looks "confusing"—locate the missing edges, the unstated dependencies everyone assumes but no one has written down.