Scaling a Nordic marketplace platform is less about architecture and more about making deliberate trade-offs while protecting team clarity through change.
Talk transcript of Pernille Trolle Brøgaard – recorded on 21 Jan 2026 Product Strategy
It’s a real pleasure to share this story, because it’s one of those transformations that looks clean on a slide and feels very different when you’re inside it.
Pernille Trolle Brøgaard leads product and UX in Vend Marketplaces (the marketplaces part of the group formerly known as Schibsted). Vend operate marketplaces across the Nordics in four verticals: mobility, real estate, jobs, and e-commerce. Their brands are deeply embedded in their local markets—Finn in Norway, Blocket in Sweden, Tori (Finland), and DBA plus Bilbasen in Denmark—each with its own history, user expectations, and technical reality.
In early 2023, Vend stood in front of investors and said: We’re going to merge four separate companies into one Nordic organization, build a shared platform serving all brands, and do it in three years—while keeping the brands intact.
That is an ambitious statement.
This post is the version of the story Penille wishes someone had written for her before they started: what hurt, what worked, and what Pernille would do differently – especially from the perspective of protecting teams while everything around them is moving.
It’s tempting to frame a multi-market transformation as an architecture project: unify platforms, reduce duplication, ship faster.
But the actual goal was user value.
Historically, the core service we offered was simple: a user could post an ad on a marketplace. That worked across categories and countries, but it placed most of the “problem solving” on the user.
If someone wants to sell a car, posting an ad is not the end of the job. The job is done when:
We can help with all of that. But that kind of end-to-end experience is fundamentally different from “publish an ad.” And it requires much deeper vertical expertise.
Helping someone sell a car is not the same as helping someone sell Pokémon cards. The workflows, trust requirements, pricing dynamics, and service integrations differ.
So we made a strategic shift: move from a mostly horizontal classifieds model to being true vertical experts—and reorganize the company so vertical teams can build independently, without being blocked by country-specific stacks and duplicated infrastructure.
Looking back, a big reason this didn’t feel linear is that we were changing three things simultaneously:
We moved from a country-led setup to a vertical-led setup. The company needed to optimize for mobility, real estate, jobs, and e-commerce as distinct value streams.
To enable vertical independence, we needed a target architecture that reduces cross-country dependencies and supports shared capabilities without forcing identical products everywhere.
And then we had to align the organization with those value streams, with a long-term focus on removing obstacles and dependencies.
That last one matters more than we often admit: everyone got a new goal and a new manager.
The one thing we tried very deliberately to keep stable was the product team unit itself. We kept product teams intact, as an anchor, because if everything changes at once you risk losing the social fabric that makes delivery possible at all.
This surprises people when they hear “merge four companies into one.”
The outcome wasn’t a single product organization. It became:
Each product organization has its own leadership, and the platform organization focuses on shared services—things like infrastructure, shared tooling, and horizontal experience layers (including design system work) that ensure consistency where consistency is valuable.
This is worth pausing on:
Scaling across markets is not automatically a centralization story. If you centralize everything, you often create new bottlenecks. The more scalable pattern for us was: enable vertical independence and provide shared foundations that remove duplication.
That balance—vertical autonomy with platform leverage—is where most of the tension lives.
Aurora as a platform was a clear ambition: consistency across markets over time, faster product development, less duplication, better products and services for users.
But “having a clear ambition” does not remove the practical reality of sequencing, trade-offs, and local consequences.
We rolled out Aurora in stages:
It still feels surreal to write this: we said “three years,” and it is actually happening in three years.
But here’s the part I want to be honest about:
When multiple brands move onto a shared platform, one market’s transition affects others. Shared teams—search, moderation, trust & safety, identity, payments—suddenly have multiple major “events” to support. Teams sit at different maturity stages. The future-state target is still evolving while you are already migrating. And the bigger picture is, in many moments, simply “in flight.”
One of our product managers described it perfectly:
It feels like changing the engine of a plane while flying at high speed.
That’s what it felt like.
DBA is a core Danish brand. Many Danes have known it since it began in 1981 (originally as a newspaper). It also carried the weight of a legacy stack and a legacy business model—classic listings, heavy display advertising, and a user experience that increasingly lagged behind what buyers and sellers expect today.
Before the transition, we saw a soft decline across key metrics. From where I stood, it became a choice:
We chose the second path, knowing it would cost us in the short term.
The uncomfortable truth about platform migrations is that you rarely “move everything.” You make deliberate decisions about scope, and every “out of scope” decision has real user impact.
For DBA, we made several explicit trade-offs:
We modeled traffic loss. We aligned leadership on trade-offs. We communicated clearly.
And still: it created ripples. With stakeholders. With teams. And with users.
Because scaling sometimes means letting go of short-term stability for long-term leverage—and you have to be clear-eyed about the cost.
DBA’s Aurora transition was a technical success.
But the market response was tough.
Traffic dropped in the period after launch. Feedback was loud. Much of it was classic change aversion—“I hate it” without a clear explanation. But there was also valid critique, especially around search and discoverability, where our taxonomy limitations made the experience feel worse than before for some users.
This is one of the hardest moments in a transformation:
Even highly motivated teams start to show strain.
So the question becomes: how do you sustain high-performing teams when the work is high-stakes, the feedback is rough, and the organization keeps changing?
There isn’t one silver bullet. What helped was a set of intentional choices—small interventions, repeated consistently.
In transformations like this, decisions need repeating. People forget in the day-to-day, especially after reorganizations.
We spent time making sure teams could answer:
One practical tool I recommend is a decision log that’s visible to everyone. It reduces speculation, prevents re-litigating old debates, and gives people context when they join midstream.
Some teams needed a short period where the expectation wasn’t “push forward at maximum speed,” but “stabilize, learn, and recover.”
That can feel counterintuitive in a program with deadlines. But exhaustion creates invisible costs: slower execution, lower quality, weaker collaboration, more attrition risk.
The goal is not to remove pressure. The goal is to manage pressure so teams can keep delivering over time.
We saw developers proactively jump into other teams’ tasks for a period—sharing expertise and reducing local bottlenecks.
In large transformations, you often discover that the constraint isn’t “number of people,” it’s “where the knowledge sits.” Temporary support across teams can unlock flow far better than formal reorgs.
During transition phases, you don’t only measure “features shipped.” You also measure:
When learning becomes an explicit outcome, teams feel less like they’re failing when the reality is simply complex.
During the most intense periods, we deliberately shifted from pushing plans harder to listening more:
High performance isn’t just execution. It’s psychological safety, clarity, and the ability to focus.
A question I often get is: How did you get buy-in across four platforms and four countries?
There were many reasons, but two stood out:
A culture that is motivated by hard problems Many people at Vend want to work on challenges that are not easy. That’s not universal, but it mattered here.
Leadership that truly understands product and tech Our CEO has deep product and technology background, and has been in the company for a long time. That changes the quality of conversations at the top. It reduces the translation layer between strategy and execution, and it makes long-term platform investment easier to defend during difficult moments.
That said, buy-in is not a one-time event. It’s something you earn repeatedly—especially after launches that users don’t immediately love.
Another important aspect of the DBA story is user demographics.
DBA’s user base had skewed older (50+). Many younger users had left years earlier for alternatives—social marketplaces, niche category platforms, more modern shopping-like experiences.
We accepted that the transition might lose some existing users who didn’t want change. But part of the long-term bet was also:
Over time, we saw traffic normalize. And user satisfaction rose above pre-transition levels. That doesn’t erase the hard launch period—but it matters as proof that the bet can pay off.
AI came up in the discussion because it’s impossible to ignore: it changes product experience, development workflows, and eventually roles.
Two ways AI showed up for us:
A concrete example is improving the “sell” flow. Instead of asking users to do all the work, we can use images and inputs to help with:
The aim is simple: less manual work for the user, more confidence, and higher completion.
Product managers, designers, and developers already use AI tools in daily work. That affects speed, quality, and how work is shaped.
At an organizational level, the bigger question is: how do you scale that impact responsibly and consistently—so it becomes a capability, not a scattered set of individual habits?
My belief is that most companies will need to treat AI as a top strategic “must-win,” not as a side initiative. And they’ll need to invest in shared enablement (tools, guidelines, training, governance) in the same way they invest in platform foundations.
Transformations can easily become internally focused. You can spend months optimizing plans and dependencies and forget that the only judge is the user.
We increased user research and interviews prior to launch to understand:
In my current area (focused on professional sellers), we have a simple ritual: a blocked session every Friday for customer interviews. It works because you can plan with business customers.
For consumer-facing teams, it’s more ad hoc—but the principle stays: keep contact with users frequent enough that you don’t need a “research campaign” to understand reality.
If I could compress the biggest learning into one sentence, it’s this:
Scaling well isn’t about doing more. It’s about protecting the humans doing the work.
You will always face tension: delivery vs. development, local needs vs. platform consistency, speed vs. stability, autonomy vs. alignment.
The difference is whether you navigate those tensions with clarity and care.
What I do differently now compared to earlier in my career:
Because clarity is a form of care. And when clarity is protected, many other things become easier.
Are we done? No.
Do we know with certainty that every aspect of this transition will work long-term? Also no.
But we believe strongly in the direction. And we’re investing in learning as we go.
One thing I’m genuinely excited about is that we’ve received support to run a multi-year research program together with industry peers, focused on how this kind of transformation works in practice—so the learning isn’t just internal.
If we’re going to put teams through change at this scale, we owe it to them (and to the wider community) to extract insights that others can use.
If you’re leading product teams through a major platform or organizational shift, I’ll leave you with a practical checklist that helped me keep the right focus:
And most importantly: don’t treat “team clarity” as a soft topic. In transformations like these, it’s a core delivery capability.
If you want to scale without breaking teams, protect clarity first.
Find mentors who can help you with Product Strategy