Lessons from building for multiple markets
I lead the strategy and delivery of products and systems that solve real problems, support commercial goals and scale across teams and markets. My work spans platform foundations, user-facing experiences, commercial tools and developer products, and I adapt my approach to the needs of each domain. I focus on maturing complex systems, improving the experience for both users and developers and strengthening the foundations that make products reliable, scalable and easy to build on. I care about clarity, good judgement and creating the processes and environments that help teams deliver consistent, long-term impact. My experience covers early-stage, scale-up and enterprise product environments, combining hands-on delivery with team leadership and award-winning work recognised across several innovation competitions.
Building for multiple markets looks like a scaling problem.
In practice, it's a decision quality problem.
The first lesson I learned is that markets diverge faster than products do.
Regulation, payment methods, user expectations, and operating models all vary. Often in ways that aren't obvious early on. What works in your home market becomes an assumption baked into everything.
Treating these differences as edge cases usually leads to brittle solutions later. By the time you notice, the architecture is already fighting you.
I worked on a product that expanded from the UK to Germany and France. We assumed checkout would be straightforward. Stripe handled payments globally.
But payments aren't just processing. Germany required specific invoice formats. France had different VAT display rules. Local payment preferences (SEPA, Bancontact) weren't about the provider. They were about user expectations our flow didn't accommodate.
What looked like "just localisation" turned into six months of rework because we'd treated these as edge cases instead of first-class requirements.
Another lesson is that localisation is not the same as customisation.
Localisation adapts a product within a shared frame. Translated strings, local currencies, date formats.
Customisation changes the frame itself. Different user flows, different data models, different business logic.
Conflating the two creates complexity that's hard to unwind. You end up with conditional logic everywhere, branches nobody fully understands, and releases that break markets you forgot to test.
The third lesson is about defaults.
Every product has implicit defaults. Assumptions baked into flows, data models, and language.
When you build for multiple markets, those defaults become visible. Is the address format global or local? Is pricing always in decimals? Does every user have an email?
Deciding which defaults are global and which are local is one of the most important product decisions you'll make. Get it wrong early, and you'll be refactoring for years.
I've also learned that global consistency is most valuable where users don't notice it.
Shared foundations (identity, permissions, core data models, analytics events) benefit from uniformity. They're invisible to users but critical for teams.
Differentiation belongs closer to the user. Checkout flows, onboarding, pricing presentation. That's where local expectations actually matter.
Finally, building for multiple markets taught me to be explicit about trade-offs.
Not every market can be perfectly served. Trying to do so creates endless scope and inconsistent quality.
Clear principles about where you standardise (core platform, data, identity) and where you adapt (user-facing flows, pricing, content) prevent slow, reactive decision-making. Teams know the rules before they start building.
The hardest part isn't building the product.
It's choosing what stays the same, and defending that decision when every market wants exceptions.