What Just Eat taught me about products at scale

Liquidity is local, always

The single most portable lesson from a large marketplace is that aggregate numbers lie. A platform can report healthy national supply and demand while a specific postcode has four restaurants, two of which close at eight. The customer in that postcode does not experience the national average, they experience an empty screen.

Founders building two-sided products consistently look at the wrong denominator. They report total supply and total demand and celebrate growth, when the number that predicts retention is density inside the smallest unit where a transaction can actually happen: a postcode, a campus, a commute corridor.

This is exactly the discipline I carried into Co-Ride. Carpooling has the same failure mode as food delivery. Nobody cares how many drivers are on the platform nationally if there is no driver going their way at 07:40 on a Tuesday. Growth strategy for a marketplace is therefore a sequencing question about which small areas you saturate first, not a national one.

At scale, engineering is rarely the expensive part

In a small company, the cost of a product decision is roughly the cost of building it. In a large one, that is a rounding error. The real cost is operational: the support contacts it generates, the training it requires, the exceptions it introduces into finance, the edge cases it hands to account management.

Watching that dynamic up close changes how you scope. A feature that takes two weeks to build and adds thirty seconds to every support call is a bad trade at any volume worth having. Founders who have only worked pre-scale rarely price this in, because at ten customers you absorb it personally and never see it as a cost.

The practical version for an early-stage team is a simple question at scoping time: what happens when a thousand people do this and one percent of them get it wrong? If the answer requires a human, that human cost belongs in the estimate.

How enterprise buying actually works

Enterprise-scale commercial work taught me that the feature comparison spreadsheet is theatre. It exists so the decision can be justified later. The decision itself turns on whether the buyer believes you will still be answering the phone in eighteen months and whether they can name the person who owns their problem.

That is why founder-led sales works so well early and then stops working. The founder is the credible named owner. When you scale past their calendar, you have to manufacture that credibility with process, service levels and documentation, and most companies underinvest in it for about a year longer than they should.

For a seed-stage company selling upmarket, the implication is uncomfortable but useful: your product roadmap is not your main obstacle. Your ability to sound like a company that will exist in two years is.

Read the metric, not the roadmap

If you want to understand any large product organisation, ignore what it announces and find out what it measures. The metric a business optimises explains its apparently strange decisions far better than its stated strategy does, because incentives beat intentions in every organisation I have worked in.

For founders this cuts two ways. It is how you predict what a large competitor will and will not do: they will not attack a segment that damages their headline metric, which is where the gaps are. And it is a warning about your own company, because whatever number you put on the wall will quietly become your strategy whether you meant it to or not.

What I took into my own companies

• Define the smallest unit of liquidity before writing a growth plan, then saturate one unit at a time.
• Price the operational tail of a feature at scoping, not after launch.
• Sell predictability and ownership, not capability, to anyone with a procurement process.
• Pick the headline metric carefully, because it will become the strategy.
• Ship the boring reliability work early. At scale it is the product.

Where this fits in the framework

Most of these lessons apply at the Launch, First Revenue and Scale stages of The Crossley Method. They are the reason the framework does not stop at MVP: a shipped product with no view of operational cost or liquidity density is a demo with users attached.