Taking a German product
global — provisioning,
politics, and trust.
How I led the global go-to-market for MyLINK Engage — navigating eight workstreams, three Nordic markets, and a cross-border collaboration that had to be earned, not assumed.

A product built for one market carries all the assumptions of that market invisibly inside it.
MyLINK Engage — originally WebSMS — was a messaging platform built and owned by LINK's German team. It worked well in the DACH market: established customer base, local provisioning and billing processes, its own engineering team, its own roadmap. A product that had grown organically in one context and had never needed to think beyond it.
The group decided it was the right product to standardise across all markets as the company's primary messaging solution. My assignment was to lead the global go-to-market: take a product built for Germany and make it launchable in Norway, Sweden, Denmark — and eventually beyond. This sounds like a product launch. It was much more than that.
- ProvisioningThe German process was manual and market-specific. Nordic markets needed a process aligned with group standards — the same unified provisioning every other portal product used.
- BillingEngage ran on a separate invoicing system from the rest of the group. Integrating it meant building a new process with legal, finance and tech all having a view on how it should work.
- SupportNordic support teams had no knowledge of the product — they needed training, documentation, escalation paths, and a clear split between what they could resolve vs. what required Germany.
- FeaturesSome capabilities that existed in the German product were not available or relevant for Nordic customers. Understanding which was which required deep collaboration with the German PM.
I was accountable for the group GTM — sell, provisioning, billing, support, monitoring, security, legal, marketing — but I wasn't the product owner. The product belonged to the German PM. She had her own roadmap, her own engineering team, her own priorities, and her own customers to serve. I needed her collaboration without her feeling that the group was taking over her product. That dynamic — being responsible for an outcome without authority over the product — is one of the harder positions to operate from.
The best collaboration I had on this project happened when I stopped being “the group PM” and started being a colleague with the same problems. Vulnerability opened a door that professionalism had kept politely closed.
Four phases. Prove the product works in the market first. Then connect it to the platform.
Before planning the launch, I ran a structured discovery across three dimensions: commercial (customer lists, pricing, migration paths from legacy platforms), technical (provisioning process, integration architecture with the MyLINK Portal, API dependencies, monitoring setup), and operational (support requirements, security assessment, legal compliance across markets).
This discovery revealed that several legacy platforms — Turnpike, Fenix, Intouch, Silver Bullet among others — had customers that would need to migrate to Engage. Each had its own pricing history, feature usage, and contract status. Building that picture took weeks. But it surfaced the problems before they could become launch failures.
One of my most important contributions was defining the criteria a product had to meet before it could enter the group portal. For Engage, this meant: unified provisioning through Salesforce following group standards, invoice structure aligned with group billing, support documentation and training completed for all target markets, and a feature parity assessment completed for each launch market.
This wasn't just operational hygiene. It was the same gate I had established for every product entering MyLINK Portal — the principle that complexity stops at the portal door. Engage had to meet the same bar as everything else.
We launched in phases: Norway, Sweden and Denmark first, with each market requiring its own readiness check — sales training, support onboarding, provisioning setup, and a validation with the local account managers who knew the customer base. I joined Nordic sales meetings to present the product directly for the first five minutes, then handed to the local team. A month later I ran full sales training.
The phased approach meant we could learn from the first market before scaling. Issues that appeared in Norway could be fixed before Sweden and Denmark launched — a coordination problem that would have been unmanageable if attempted simultaneously.
The 2024 roadmap focused on the core migration and operational readiness: mapping the customer base, migrating from Turnpike and other legacy platforms, handling specific enterprise requirements like DNB's security audit, SSO and reporting needs.
The MyLINK Portal integration — making Engage statistics visible in the portal dashboard, surfacing Engage in the navigation, and enabling upsell prompts for unprovisioned customers — was defined as a separate phase, not part of the initial GTM. This was a deliberate decision: trying to do the portal integration and the market launch simultaneously would have created too many dependencies and too much risk. Prove the product works in the market first. Then connect it to the platform.
Three markets live. A foundation that kept building. A GTM that leaves no foundation isn't a launch — it's a one-off.
Markets launched
Norway, Sweden, Denmark — phased approach, one at a time
Workstreams owned
Sell · Provisioning · Billing · Support · Monitoring · Security · Legal · Marketing
Legacy platforms
Assessed for migration — Turnpike, Fenix, Intouch, Silver Bullet and others
Roadmap phases
GTM as-is · migrations · portal integration · self-service expansion
Years active
Q1 2024 through 2027 and beyond
The GTM I led in 2024 was the foundation, not the finish line. The roadmap that followed — NEXT migration, portal integration in 2026, SSU and self-service in 2027, expansion to Volvofinans and other enterprise clients — was only possible because the initial launch established the operational standards and the cross-team relationships needed to keep building.
Authority is the wrong lever. Trust is the only one that actually works across org boundaries.
The technical complexity of this GTM was real but manageable. The organisational complexity was harder. Being accountable for an outcome without owning the product requires a very specific kind of influence — one built on trust and shared interest rather than authority.
The lesson I carry from this project is about where collaboration actually starts. It doesn't start when two people agree on a plan. It starts when they're willing to be honest about what's difficult. The moment I stopped performing confidence and started sharing my actual problems, the collaboration became real.
I also learned that a good GTM is really a good discovery. Most launch failures happen because someone assumed they understood the operational requirements of a new market. The investment in understanding the as-is — the existing customers, the pricing history, the legacy platforms — is never wasted. It surfaces the problems before they become launch failures.
“The calls changed. They became conversations between two people trying to solve the same problem from different angles, rather than a group PM and a local PM managing their boundary. That informal knowledge made the formal work significantly better.”