Unifying a fragmented
CPaaS into a single
product surface.

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, about ownership and priorities.

At some point, my manager and the Head of Commercial were stuck. A long silence. I asked one question:

The room changed. That distinction — between selling into an existing plan and moving a client to a new one — had been invisible in the conversation, but it 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 prepared to show — a wireframe, a prototype, a framework — and with a set of questions ready for moments when showing something wasn't the right move. I listened first, always. Then I taught. Then I asked.

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 — a document that defined what the portal was and was not, which legacy products would be migrated and which would be sunset, what the value proposition was for customers and for LINK internally, and how success would be measured.

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 solutions that diverged from the strategy, 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.

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 the UX team and the Macedonia tech team together. Not to review deliverables, but to surface the friction in their daily work and systematically reduce it. The frequency of retros tells its own story: we needed them every two weeks at the beginning. We now meet monthly. The problems didn't disappear — they shrank.

I then built a complete UX process from scratch: documented in Confluence, with Figma templates for every project type, with clear definitions of what research meant, how prototypes connected to engineering specs, how feedback loops worked. I invited the more resistant team members to contribute to the process rather than receive it. People defend what they help build.

I also requested that HR run a team dynamics workshop — a structured process to surface how we worked together. Some people left after that. The team that remained has been stable ever since. No one has left. That's a metric too.

Before a single wireframe was drawn, we ran an exhaustive discovery process. We interviewed internal support teams across multiple markets. We analysed existing products, mapped customer personas, spoke directly with clients, and ran a full competitive analysis. We mapped the entire portal architecture — coordinating with every product team to understand their use cases and integration requirements.

From that research, we defined the core problems the portal needed to solve, built and iterated through multiple versions of the concept, and used rapid prototyping to test ideas with management before committing to development. 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.

The prevailing assumption was that migrating clients between products caused churn — and that this was unavoidable. 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.