LLenny's Podcast
← All frameworks
StrategyJeremy Henrickson (Rippling, Coinbase)

International Market Entry Stack Rank

Assume you'll need everywhere, order by demand, then re-rank by build cost, strategic value, and long poles.

Difficulty
Moderate
Time to result
~months to results
Steps
7
Confidence
90%

Rippling's method for sequencing global expansion. Start from the assumption that you will eventually need presence everywhere, use your existing customer data to derive raw demand ordering, then adjust that raw order by build difficulty, strategic value, and regulatory long poles — producing a stack rank you revisit as you learn. Paired with Henrickson's timing rule: go international earlier than you think you need to.

Origin

Jeremy Henrickson at Rippling, informed by his earlier international expansion experience at Guidewire. Rippling's advantage was structural: as an employee system of record, it already knew where its thousands of US-based customers had non-US employees, converting expansion prioritization from guesswork into a data query.

Core principles

  • 01Start from 'we will have to be everywhere ultimately' — that reframes the question from whether to which order.
  • 02'Everywhere' is not uniform: full native payroll in every country is irrational, but paying contractors and holding HR data anywhere is table stakes.
  • 03Your existing customers' latent demand is the best available signal even when the data is incomplete.
  • 04Raw demand order is the input, not the answer — modulate it by build cost, strategic value, and long-pole approval timelines.
  • 05Expand earlier than you think you need to; it is harder and more specialized than anyone who hasn't done it believes.
  • 06Every country believes its local context is special, rightly or wrongly, and you must respect that.
  • 07The stack rank is revisited and re-jiggered as you go deep — but a well-built initial list mostly survives contact.

How to run it

  1. 1

    Adopt the everywhere assumption

    Start from the premise that you will ultimately need to serve everywhere. Then separate the tiers: where you need deep native support (e.g. full local payroll) versus where you need basic reach (pay anyone, contract anyone, hold their HR data anywhere).

    Pro tip Naming the tiers early prevents the debate from collapsing into an all-or-nothing 'should we go global' argument.

  2. 2

    Mine your own customer data for latent demand

    Query your existing customer base for where they already have people, entities, or transactions. Rippling, as the employee system of record, already knew where its US customers' non-US employees were and could list countries in raw numerical order.

    Pro tip Even skewed data (US-based customers only) is far better than opinion. Name the bias, then use the data anyway.

    Watch out Do not mistake this list for the market. It is your customers' demand, which is incomplete data by construction.

  3. 3

    Overlay build difficulty

    For each candidate country, ask how hard it actually is to build there — regulatory complexity, local requirements, entity setup, filing systems.

  4. 4

    Overlay strategic value

    Ask what the strategic value of presence is, independent of raw volume. The UK, Canada, Germany, and India may each carry weight that their employee counts alone don't capture.

  5. 5

    Identify the long poles and risk

    Explicitly discuss where the risk lives and where the long poles are — which countries have approval or licensing timelines that take a long time regardless of engineering effort.

    Pro tip Long poles argue for starting a country early even if its demand ranking is mid-pack — the clock runs whether or not you're working.

    Watch out A country with modest demand and an 18-month approval process is a sequencing decision, not a prioritization decision.

  6. 6

    Stack rank, launch a deliberately diverse first cohort, and revisit

    Produce the ranked list and commit. Launch with a cohort of countries that are genuinely different from each other so the platform is forced to generalize. Then revisit and re-jigger the order as you go deep and learn.

    Pro tip Henrickson reports the original list mostly held up — a well-constructed initial rank survives contact with reality better than expected.

    Watch out Launching with one similar country and 'copy-paste' localization produces a system that cannot generalize. See the complex-case-first framework.

  7. 7

    Respect local context obsessively

    Treat local adaptation as first-class, not polish. A missing 'u' in 'colour' or a US Social Security Number field visible on a person detail screen destroys credibility instantly, no matter how good everything else is.

    Pro tip Invert the empathy: imagine a German system demoed in the US with poorly translated strings — you would think it sucked too.

    Watch out Dropping your home-market approach into another country reads as insulting, and no amount of prior success buys you a pass.

In the wild

Rippling's six-country global payroll launch

Rippling listed the countries where its thousands of existing US-based customers already had employees in raw numerical order, then modulated the list by build difficulty, strategic value, and where regulatory approvals formed long poles. It chose to launch with six deliberately very different countries rather than one similar one.

A global payroll platform that generalizes — ~80% shared, ~20% country-specific and largely configurable by compliance staff. Countries were re-ordered somewhat as the team learned, but the original stack rank remained mostly right.

The 'u' in colour

Henrickson's recurring lesson across two decades of international expansion (from Guidewire onward) is that every country is unique and everyone believes their local context is special. UK users genuinely care whether 'colour' has a 'u'. A demo that shows a Social Security Number field to a non-US audience loses all credibility on the spot.

Rippling treats localization as a credibility gate rather than a finishing task, and Henrickson names this as the single most consistently surprising thing to teams expanding internationally for the first time.

Common mistakes

Waiting until you obviously need to expand

Henrickson's rule is always earlier than you think you need to. It is harder and more specialized than first-timers expect, and the cultural lessons take a long time to absorb — that learning curve has to start before the demand is acute.

Ranking on raw demand alone

Demand order is only the first pass. Ignoring build cost, strategic value, and regulatory long poles produces a sequence that stalls on approvals you could have started a year earlier.

Copy-paste localization

Replicating your home-market product and swapping the strings is the fastest path and the worst one. It produces a system that never generalizes and a product that other markets find insulting.

Is it for you?

Best for

Operators at a company with an existing domestic customer base and enough data to observe latent international demand, deciding which markets to enter and in what order.

Not ideal for

Pre-PMF companies with no customer base to mine, or products where the domestic market alone is far from saturated and expansion is a distraction.

From the transcript

we just like listed those out in raw numerical order and then we kind of looked at okay how hard is it to build in…

41:30

I think the right answer to that question is always before you think you do before you think you need to

42:30

like you can't just take your us-based approach and like Drop it into another country other countries find it insulting it doesn't matter how much…

44:30

From the episode

Moving fast and navigating uncertainty

Jeremy Henrickson (Rippling, Coinbase)