Take the moves that built any successful company — the beachhead, the fundraise, the first sales team, the pricing change, the geographic expansion, the platform play — and run them in a different order. Most orderings fail. Not because any single move was wrong, but because business is path-dependent: each move changes the set of moves available next, and a move made before its preconditions exist doesn't half-work, it fails outright and hands you the wrong lesson about itself. So a large share of what we dignify as "strategy" is actually sequencing — deciding what to do first because it makes the second thing possible, and refusing to do the right thing at the wrong time.
This reframes a whole category of failure. "Good idea, bad execution" is usually a misdiagnosis. Often the idea was sound and the execution was competent, and the move still died — because it was played out of order. The move was a correct node reached before the nodes it depended on. Once you see business as a graph of dependencies rather than a menu of tactics, a startling amount of "we tried that and it didn't work" resolves into "we tried that too early."
Preconditions are edges
Economists have a name for the mechanism: path dependence — the property that the sequence of past states constrains which future states are reachable at all. Brian Arthur and Paul David built the formal version around increasing returns and lock-in, with QWERTY as the worn example. The operating version for a founder is narrower and more useful: every move has preconditions, and a precondition is not advice you can override with grit, it's a gate. You cannot deploy a $20M round productively until you have a machine that turns money into more money at a known rate. You cannot hire a sales team into a sale that isn't yet repeatable. You cannot go horizontal until you own a vertical dense enough to fund the next one. Each is a dependency: move B requires the state that only move A produces.
Draw it and it's a directed graph. Nodes are moves; an arrow from A to B means A produces a precondition B needs. Computer science has a name for the only orders that are valid on a graph like this — a topological sort, an ordering in which you never reach a node before the nodes it depends on. There is usually more than one valid order, and vastly more invalid ones. Strategy, stripped to its frame, is choosing a topological order through your own dependency graph. The reason it's hard is that the graph is partly hidden. Nobody hands you the edges. You infer them — often by violating one and paying the bill.
A premature move frames itself as the villain
Here is the cruel part. When you run a node before its parents, the failure does not announce itself as "wrong order." It announces itself as "wrong move." You raise too early, deploy capital you can't yet convert, post an ugly quarter, and conclude the raise was a mistake. You hire sales before the sale is repeatable, watch the reps miss, and conclude outbound doesn't work for your product. You go horizontal before owning a beachhead, get beaten in every segment at once, and conclude the market is too competitive. In each case the founder indicts the move and quietly removes it from the playbook — deleting a tool that was never broken, only early.
The tell that you're looking at a sequencing error and not a bad bet: the move demonstrably works for companies that look like yours, and it failed for you through a specific missing precondition rather than through its own logic. If the thing that closed your first deals was you, the founder, in the room, then a rep's failure isn't evidence about outbound — it's evidence that the "repeatable sale" node hadn't fired yet. Diagnose the missing edge and you keep the move for later. Blame the move and you lose it for good.
Two sequencing lessons I paid for in cash
Building Kommerce — a commerce operating system for cash-on-delivery markets, where trust is the scarce input and cash reaches the seller only after goods change hands — taught me the graph the expensive way.
Credit before data. The obvious high-margin move in a COD commerce OS is merchant financing: float working capital to sellers who otherwise wait days for cash to trickle back through delivery. Lucrative, sticky, defensible. Also un-runnable at t=0. You cannot price credit risk for a merchant whose transaction history you don't yet hold. The product that generates that history — the payments-and-logistics reconciliation layer — has to run first, and run long enough to underwrite on. Ship the financing product first and you're not early to a good idea, you're lending blind. One dependency later, the exact same move becomes the best business in the stack. The credit product is a child node of the data product, full stop; the order is the strategy.
Prepayment before trust. The textbook cash-flow fix in a low-trust market is to make customers prepay — collect before you ship and the working-capital problem evaporates. Correct move. Make it early and it kills you, because the entire reason cash-on-delivery dominates these markets is that buyers don't trust sellers they can't yet hold accountable. Prepayment is a privilege you earn with a delivery track record and a brand the customer has reason to believe. Ask for it before you've banked that trust and you don't improve cash flow — you lose the order. The move only unlocks after the trust node fires, and no amount of wanting it sooner moves the edge.
The arithmetic of a premature sales team
Sequencing errors stay invisible until you price them, so price one. Say you've personally closed a handful of deals and you hire five reps, fully loaded at roughly $150k a year each, to scale it — $750k of annual commitment. The bet pays only if the sale is repeatable: a rep who isn't you converts leads at a rate that makes payback work. Suppose your model assumes a 20% close rate and a CAC that pays back in nine months. Now suppose the sale wasn't actually repeatable — what closed those first deals was founder credibility, and the real close rate in a rep's hands is 5%. That's one-quarter the conversion, so your effective CAC is 4x the model and payback slides from nine months to three years — and you've locked $750k against a motion that doesn't return inside any horizon that matters.
You will conclude that outbound doesn't work for you and tear it out. The move was fine. The precondition — a sale that closes with the founder out of the room — didn't exist yet. Close twenty deals yourself first, extract the script that converts at 20% in someone else's hands, and those same five hires become an engine instead of a hole. The difference between the disaster and the engine is not the move and not the reps. It's whether one upstream node had fired.
Three orders worth naming
Beachhead, then expansion. Own a segment narrow enough to dominate before you go broad — Geoffrey Moore's bowling-pin logic. The premature version, going horizontal to chase a bigger TAM, fails because breadth has a precondition: a defended base that funds and credentials the next segment. Skip it and you compete everywhere and win nowhere.
Product, then distribution. These are two different games played in sequence, and distribution is the second game and the one that kills you precisely because founders try to run it before they've won the first. Pour traffic into a product that leaks and you've sequenced backwards — spending to reach people a broken product will only churn. The distribution node depends on the retention node; fire them in the wrong order and the money just accelerates the failure.
Manual, then automated. Paul Graham's "do things that don't scale" gets read as a motivational license to grind. The sharper reading is a sequencing claim: you do the thing by hand not because effort is virtuous but because manual execution is the only process that produces the spec — automation has a precondition, knowing exactly what to automate, and only the manual phase generates it. Build the machine first and you've automated a process you hadn't yet learned, at fixed cost, and you'll pay a second time to rip it out.
Doing everything at once is refusing to sequence
There's a failure that looks like the opposite of a sequencing error and is actually its purest form: running every move in parallel. When you can't decide the order, the tempting escape is to not decide — fund all the bets and let the market sort them. That isn't a way around sequencing. It's a sequencing decision made by default, and a bad one, because a fixed budget split across parallel moves starves each below the threshold where it would produce the unlock the next move needs. This is why most startups die of indigestion, not starvation — too many things started, none finished, the value of each still sitting at zero because value is a step function that only fires at completion. A topological sort is a serialization, and its whole content is that some correct things wait.
Build the graph
Do this literally. Take your next six-to-twelve-month plan and write every major move as a node. For each one, ask a single question with a hard answer: what must be true for this to work? Not "what would help" — what must be true. Those are the in-edges. A move whose preconditions aren't yet satisfiable comes off this quarter's list no matter how right it is; it becomes a deferred node tagged with the specific upstream move that will activate it. Then order the graph by unlocks: do first the move that makes the most downstream moves reachable, not the move with the highest standalone expected value. The highest-EV move is usually a leaf hanging off three dependencies you haven't cleared.
Keep the second list, the one that takes more discipline: the right-but-premature moves you are explicitly deferring, each labeled with the precondition that will fire it. That list is where sequencing stops being a slogan and becomes a practice. A founder who can name the five correct moves they are deliberately not making yet, and the exact unlock each is waiting on, has a strategy. A founder holding a flat to-do list of everything worth doing has a wish.
Your competitors can read your move list. The order is the part they can't copy by reading it.