When OpenTable started signing up restaurants in 1998, most of them did not have internet at the host stand. Some did not have electricity there either. So the company sent people to run cables through walls and basements to install an Electronic Reservation Book, and it charged the restaurant $500 for the privilege while spending roughly $5,000 to do it. On paper this looks insane. A reservations network that cannot fill tables until it has both diners and restaurants was pouring money into a single boring tool that only helped the restaurant, not the diner.
That was the strategy. Not an accident of the strategy, the strategy itself. OpenTable understood that it could not sell the network first, so it sold the tool first and let the network arrive later. The order was the whole plan.
Most product strategy conversations argue about what to build. The harder and more consequential question is what to build first, and what you deliberately hold back until the ground underneath it can support it. Sequence is not scheduling. Scheduling is when work fits on a calendar. Sequencing is a bet about which capability creates the conditions for the next one to work at all. Get the order wrong and every individual thing on your roadmap can be excellent and the product still fails.
Two good products, shipped in the wrong order, both die
Chris Dixon named the pattern more than a decade ago: come for the tool, stay for the network. You attract the first users with a single-player tool that is useful the moment one person opens it, with nobody else present. Then, once enough people are inside, a network layer forms on top and becomes the reason nobody leaves. As Dixon put it, “The tool helps get to initial critical mass. The network creates the long term value for users, and defensibility for the company.”
Delicious did it: private bookmarking first, shared tagging second. Instagram did it: filters first. When Instagram launched in October 2010 it hit 25,000 users on day one largely because a single person could make an ugly iPhone photo look good with one tap, alone, with zero followers. The feed and the follows, the actual network, became the sticky part later. Fewer than three months after launch it passed a million users. The filter was kindling. The network was the fire.
Now run that in reverse. Imagine Instagram had shipped the social graph first and the filters second. A photo-sharing network where the photos look bad and there is nobody to share with yet. Same two features, same quality, opposite order, and it never leaves the ground. The building blocks did not change. The sequence did.
I have watched the reverse version happen in rooms I was in. A team wants to build a marketplace or a collaboration product, and they treat the network effect as the reason to build, so they build for the network from day one. Every early feature assumes a crowd that does not exist yet. The product is worthless to the first hundred users because it is designed for the ten-thousandth. Those first hundred never show up, so the ten-thousandth never does either. The idea was fine. The order killed it.
The defensible parts of a strategy only become available in a certain order
The reason sequencing is strategy and not project management is that your competitive advantages are not all reachable at the same time. Hamilton Helmer’s 7 Powers makes this point better than anything else I have read on strategy. Helmer argues that each source of durable advantage can only be established during a specific phase of a company’s life.
In his framing there are three phases. In origination, before you have compelling value, the powers available to you are counter-positioning and a cornered resource. In takeoff, the fast-growth window once the value lands, you can build scale economies, network economies, and switching costs. In stability, after growth slows, what is left to win is brand and process power. Miss the window and the door closes. You cannot go back and manufacture a network effect after your growth has flattened, because the growth was the mechanism that would have built it.
This is why “we’ll add the moat later” is usually a fantasy. The moat is not a feature you bolt on when convenient. It is a thing that can only be poured during a specific window, and the window is defined by where the product is in its own arc. Sequencing well means recognizing which window you are in and spending it on the advantage that is only available now, instead of the advantage you can still get two years from now. That is a strategy decision wearing the costume of a roadmap decision.
It also cuts against the instinct to always build the most impressive thing first. The most impressive thing is frequently the network, the platform, the ecosystem. But those are takeoff-phase and stability-phase powers. In origination, the boring single-player tool is often the only move that actually works, precisely because it needs no one else to be there.
Where I learned the order matters more than the parts
Years ago, running IT operations for a telecom in Saskatchewan, we replaced a field-service system that every technician used daily. The plan on paper was sound: new dispatch, new mobile app, new customer-facing status page, new analytics. We sequenced it the way most teams do, biggest visible win first. The customer status page was the flashy piece leadership wanted, so we led with it.
It was the wrong order and it cost us most of a quarter. The status page depended on clean, real-time job data, and the clean real-time job data depended on technicians actually using the new mobile app in the field, and the technicians would only adopt the app once dispatch stopped double-entering jobs in the old system. We had built the roof before the walls. The status page showed customers stale, wrong information for weeks, which was worse than showing nothing, and it burned trust we then had to earn back.
When I do fractional operations work now, this is one of the first things I look for in a roadmap. Not “are these the right initiatives,” but “does each one create the conditions the next one needs, or are we assuming conditions that only exist after later work?” A roadmap that reads top to bottom as a list of good ideas can still be a plan to fail, if the good ideas are stacked in an order where the early ones quietly depend on the late ones. The dependency was invisible on the slide. It was very visible in the field.
The questions that expose a sequencing bet
You can usually surface whether a roadmap is really a sequence, or just a pile, with a few plain questions. I use these in strategy reviews.
What has to be true for item three to work, and does item one or two make it true? If the enabling condition for a later bet is not produced by an earlier bet, you have a gap, and the later bet is floating on an assumption.
Which of these is useful to a single user with no one else present? That is almost always your correct first move when a network or marketplace is involved. If nothing on the list is useful alone, you have a cold-start problem you have not solved yet, no matter how good the eventual network is.
Which advantage can we only build right now? Borrow Helmer’s phases. If you are in a growth window that will not last, spending it on brand polish instead of switching costs or network density is spending a one-time resource on a power you can still get later.
If we shipped these in the opposite order, would anything break? If the answer is no, the order is not load-bearing and you have flexibility. If the answer is “everything,” then the order is your actual strategy and it deserves as much scrutiny as the feature list itself.
There is a well-known counter to Dixon’s line, sometimes phrased as “come for the network, stay for the tool”, and it is a useful reminder that no sequencing rule is universal. Some products genuinely need to lead with the network. The point is not that tool-first always wins. The point is that the direction is a decision, an explicit and defensible one, not a default you back into because the flashiest feature happened to be scheduled first.
A product strategy is not a feature list, and one of the clearest tells of the difference is whether the team can explain the order. A feature list can be shuffled without anyone noticing. A strategy cannot, because in a strategy the order is carrying the weight.