MyLINK Portal

The Copenhagen moment — and what came before it

My first major test came early: a strategy workshop in Copenhagen with the company's senior managers. I was 30, the only PM in the room, surrounded by men in their 40s who had been debating these problems for years.

The conversation was going in circles — arguments about what constituted a product versus a feature. At some point a long silence. I asked one question: "Would this be upsell or upgrade?" The room changed. That distinction unlocked an entirely different way of thinking about the product offering. We spent the next hour restructuring the map.

That workshop taught me something I've used ever since: in politically charged rooms, a well-placed question does more than any argument. I came to every subsequent meeting with something to show — a wireframe, a prototype, a framework — and with questions ready for when showing something wasn't the right move.

Build the north star before anything else

Before touching any feature or sprint, I worked with the Head of Product to translate executive strategy into something the organisation could actually execute. The output was a product Blueprint — defining what the portal was and was not, which legacy products would migrate and which would sunset, what the value proposition was for customers and for LINK internally.

This Blueprint became the north star for every subsequent decision. When stakeholders pushed for out-of-scope features, I pointed to the Blueprint. When engineering proposed diverging solutions, the Blueprint anchored the conversation. It is still the reference document today.

I also ran a naming and principles workshop early on — a deliberate move to give the project a codename and a shared identity. It sounds small. It wasn't. Teams defend what they helped name.

Build the team before building the product

I was given a UX and frontend team assembled from a recently acquired company in Macedonia. They were talented but disconnected — from each other, from the product, from the broader organisation. Before we could design anything meaningful, we needed a shared way of working.

I started with fortnightly retrospectives — joint sessions with UX and tech together. Not to review deliverables, but to surface the friction in their daily work and systematically reduce it. We now meet monthly. The problems didn't disappear — they shrank.

I built a complete UX process from scratch: documented in Confluence, with Figma templates for every project type, clear definitions of what research meant, how prototypes connected to engineering specs. I invited the most resistant team members to contribute to the process rather than receive it.

I also requested that HR run a team dynamics workshop. Some people left after that. The team that remained has been stable ever since. No one has left in four years. That's a metric too.

The research foundation

Before a single wireframe was drawn, we ran an exhaustive discovery process. We interviewed internal support teams across multiple markets, analysed existing products, mapped customer personas, spoke directly with clients, and ran a full competitive analysis.

I introduced tools to record and analyse client feedback from meetings systematically, and fought to add product analytics tracking from day one — something that required sustained advocacy inside a company that historically measured very little at the product level.

Solve the migration problem differently

The prevailing assumption was that migrating clients between products caused churn. I disagreed with the diagnosis. The problem wasn't migration — it was forced migration.

I proposed a soft migration strategy: first connect client data to the new portal so they could see their existing information there. Once they were logging in regularly and seeing value, introduce the new product capabilities alongside. The migration became a natural next step, not a disruption. Clients began requesting it themselves.

We also established a strict rule: no product could enter the portal without following the unified provisioning process and invoice structure. This was a political battle — several product teams pushed back hard — but it was non-negotiable.

Earn trust on every front, differently

With local market managers who resisted the portal, I always left conversations with a solution and a concrete action plan — never just a diagnosis. Patience was the strategy. Speed of response built credibility that arguments couldn't.

With the engineering team, I showed them — incrementally, specifically — how structure in the roadmap made their work easier rather than more constrained. I found allies inside that team and made those people visible.

With C-level stakeholders, I experimented constantly with format: presentations, wireframes, metaphors, videos, user journey flows narrated in the client's voice. I presented at every all-hands event, every quarterly review, every annual market gathering — with honesty about what wasn't working yet, because credibility under pressure is built by telling the truth when it's uncomfortable.