Every company can be described as a dependency graph.

One useful projection is a tree that alternates between what and how. A node states a goal, constraint, or problem. Its children state the approaches that could satisfy it. Each of those approaches becomes the next layer's objective, which can again be decomposed into implementation choices. Repeating this process produces a structure that runs from high-level intent down to product surfaces, workflows, policies, codepaths, contracts, user interfaces, and operating routines.

This framing is useful because it makes dependencies explicit. It lets you ask the same question at every level: what must be true for this lower-level choice to solve the higher-level problem above it? Once that structure is written down, a company becomes easier to reason about. Strategy, organization, and execution stop looking like separate topics and start looking like different layers of the same system.

Alternating What and How

The tree begins with a top-level what. In a company, that is usually the vision: the state of the world the firm wants to bring about.

The next layer is the how for achieving that vision. In business terms, this is strategy. It defines the path the company believes will work, along with the tradeoffs it is willing to make.

That strategic how then becomes the next what. If the strategy is real, the company must organize itself to execute it. Organization is therefore the next layer down: team structure, decision rights, incentives, operating cadence, and resource allocation.

The leaves are the concrete artifacts produced by that organization. They include products, features, workflows, pricing, customer support processes, legal agreements, software systems, risk controls, and internal routines. These are the visible outputs of decisions made higher in the tree.

Product Management as Graph Editing

This model is also a useful way to describe product and company building. Much of management can be understood as editing the graph.

• Add nodes and edges when assumptions need to be surfaced or when a solution is missing a clear link to the problem it claims to solve.
• Remove edges when a dependency turns out to be false, unnecessary, or too costly.
• Rewire subtrees when the decomposition changes, as in a re-org, a re-architecture, or a new go-to-market motion.
• Prune subtrees that create more complexity than value.
• Reweight edges as evidence arrives from customers, experiments, incidents, regulation, or competition.

Prioritization is the choice of which part of the tree to expand under limited time, capital, and organizational attention. A roadmap is a sequence of edits meant to improve outcomes at the leaves without breaking coherence higher up.

Beliefs Sit Above Execution

Dependencies point upward. Leaves depend on branches. Branches depend on organizational choices. Those choices depend on strategy. Strategy depends on beliefs about how the world works.

Some of those beliefs are close to constraints of reality. In a brokerage business, examples include the fact that settlement takes time, margin increases both upside and downside, and order flow must move through regulated market infrastructure. Other beliefs are hypotheses about users and markets. A company might believe that a simpler interface increases participation, or that reducing friction expands usage more than it increases risk.

The difference is confidence. Some assumptions are stable enough to treat as hard constraints. Others must be tested and updated as evidence accumulates. A tree is useful partly because it shows which visible product choices depend on which deeper beliefs.

Example: Robinhood

Robinhood is a useful example because the company can be described clearly in this framework.

• Vision: democratize access to financial markets.
• Strategy: reduce friction, remove fees, and make participation emotionally and operationally easy.
• Organization: consumer product, growth, payments and clearing infrastructure, regulatory and legal, and risk management.
• Artifacts: a mobile-first interface, fast onboarding, fractional shares, instant deposits, options and margin, notifications, and the infrastructure required to route and settle trades within the constraints of market structure.

The diagram below is not meant to be the literal truth of the company. It is a structured attempt to write down dependencies that are usually left implicit. It is grounded in Robinhood's Form 10-Q for Q1 2025.

Written out in text, one branch of the tree looks like this:

1. Robinhood starts with the vision of democratizing finance.
2. It observes that people feel excluded from investing, that fees discourage small trades, and that market makers will pay for retail order flow.
3. From that, it forms a belief that a large retail user base can be monetized without charging commissions directly.
4. That belief supports the strategic choice to offer $0 commissions, funded in part by payment for order flow, and to own more of the clearing infrastructure.
5. Those choices support products like equities and options trading.
6. Those products show up in concrete screens such as the home screen, stock detail screen, order entry screen, and options chain.
7. Those screens decompose into features like the price chart, watchlist, order form, and options chain grid.
8. Those features finally bottom out in specific interface elements and systems: the buy and sell buttons, the shares input field, the order confirmation modal, the order management system, the routing engine, market data feeds, and clearing integration.

Another branch runs through friction rather than fees: people feel excluded, account opening is slow, and finance feels intimidating; Robinhood therefore bets that lowering friction and making the product feel welcoming will increase participation. That belief leads to mobile-first design, instant deposits, and fractional shares, which then show up downstream in onboarding flows, recurring investment, KYC forms, ACH linking, fraud checks, and the cash and margin systems that make a "simple" consumer experience operationally possible.

Where Failures Actually Live

Companies often fail in ways that look confusing from the outside because observers focus on the leaves. They point to the interface, the risk controls, the pricing model, or the operations stack. Those are visible. They are rarely the whole explanation.

The more important disagreement usually lives higher in the tree. It sits in the company's assumptions about user behavior, incentives, regulation, or second-order effects. A feature fails because the branch supporting it was weak. The branch was weak because an upstream belief was incorrect, untested, or no longer true.

Tracing failures upward makes them more interpretable. It shows whether the problem was tactical execution, structural misalignment, or an incorrect model of the world.

Alignment as Shared Structure

Most companies do not explicitly publish their dependency tree. They have strategy documents, slogans, dashboards, and org charts, but not a shared map of how high-level goals connect to operational choices.

That absence creates drift. Two capable employees can both claim alignment with the same vision while building incompatible subtrees. The issue is not effort. It is that they are operating with different implicit assumptions about what matters, what must be true, and which tradeoffs the company is actually making.

One way to measure alignment is to ask whether different people can reconstruct roughly the same tree. In a coherent company, the answers will differ in detail but not in structure. In a drifting company, the structures themselves will diverge.

How to Read a Company

Once a company is viewed this way, many decisions become easier to interpret.

A product decision can be read as an expression of an upstream belief. An org design choice can be read as a claim about which strategy is worth optimizing for. A sudden pivot usually means an important assumption was disproven or a new constraint became binding.

The broader point is that companies are easier to understand when their dependencies are explicit. A tree does not remove uncertainty, but it does make reasoning cleaner. It reveals where execution depends on structure, where structure depends on strategy, and where strategy depends on beliefs that may or may not survive contact with reality.