Thanks, Oscar. As a product development agency, we're always curious how other companies work with products. And to get a better sense of this, this is very important to us to understand what's happening and to be on the forefront of this. So in doing so, we asked more than 350 product professionals what is happening inside their organizations. And we did that because we wanted to understand how they work with product development today, what challenges they are facing, and also whether we see any clear patterns starting to emerge across these teams. So in this next part, I will take you through some of the key findings from this survey and also disclose what they might tell us about how product teams can set themselves up for success in this new era that Oscar just described. A bit of background. To run this survey, we took the chance to ask the people who work with digital products on a day-to-day basis at the Future Product Days last September. So also bear in mind that these numbers are from that period of time. For those who don't know Future Product Days, this is the largest product development conference in Northern Europe. And we were one of the main sponsors last year and we were very happy that we will be continuing this partnership again in 2026. So with several thousand product people in one place, it just felt right to start asking these questions and ask the people who are closest to the work how they actually work, how they collaborate, and where they see the struggles in there, where they struggle on a day-to-day basis. So we put together a survey and asked just that and asked all the attendees to contribute to this. So, we heard from people across different industries, tech, finance, retail, transportation, and so forth, including the public sector. However, it wasn't surprising to us that a fairly big overweight comes from technology and software. This makes sense because a lot of people working with digital products, this is where they're located, this is where they sit. But we also heard from companies from different sizes, from startups all the way to large established organizations, all working in quite different ways, you could say. But in reality, and let's be fair here, looking at industry or company size, that doesn't really give us a lot. At least it's not enough to explain the different dynamics that we see in product development. So we needed to look at something different. And what did seem to matter though, was the organizations and their underlying product culture. On one side, we saw organizations that were more feature driven, reactive, and sales-led than their approach, meaning they wanted to create features fast and drive sales through that. On the other side, we saw organizations that seemed to gravitate around product. We called those product-centric. These were the teams who identified as being customer-centric, data-driven in their approach, and also experimentation. That's a core thing for these teams. So, instead of looking at product culture as a long list of separate traits, we started to look into this. And we started to see two much clearer archetypes emerge. The delivery-centric team versus the product-centric teams. And these two archetypes, they work in fundamentally different ways we found. On the one hand, the delivery-centric teams, they seem to focus more on the output rather than the outcome, get something through at a high pace. So meaning that for these teams, it's often a priority to ship features. In the delivery-centric teams, the roadmap is also more likely to be shaped by stakeholders around the team rather than by the product team itself. They are just the delivery engine. On the other hand, you have the product-centric teams. They're different. Here the focus is more on outcome rather than output. What is the actual effect of the things that we're doing? How are we supporting the business in the work that we're doing today? The product teams, they have more ownership. They're trusted to make decisions, and they help shape the direction of the products based on what they learn from their data, from their users, and working with this closely. Okay. So together, these groups, they turned out to be really useful for interpreting the results from our survey. And you can see that they're fairly equal sized. So, 43% could be described as delivery-centric, while 39% could be described as product-centric. An even divide. So, now we could start looking at the underlying behaviors of what that archetype will do in shaping the product development. One interesting finding I would like to start with is that when we asked if the teams spent enough time exploring problems, nearly half of the delivery-centric teams disagreed that they were spending enough time exploring problems first. On the product-centric side, only 14% said the same. In other words, many of the theory-centric teams already know that they are moving too quickly into solution mode. I think this is a good thing to be aware of this, having that sort of self-reflection, right? And it makes sense. Because if decisions are made outside of the team, or if the solution has already been decided upfront, then spending the time understanding the problem, generally that's not perceived as time being well spent or invested. Therefore, teams move straight into delivery mode. And the consequences of this is pretty obvious. They risk building solutions before they have fully understood the problem. Okay. Next finding. This is about goals. And the question is, do teams have clearer goals and KPIs that actually help them guide their decisions? And again, we see a pretty striking difference in the answers. 60% of product teams say yes. For delivery-centric teams, it is just 29%. This is not really about whether goals exist at all. I mean, most organizations, they have goals somewhere. The real issue is whether these goals are close enough to the work to actually help shape the decision-making in the team. And in delivery-centric organizations, strategy often stays at the PowerPoint level, but it never really becomes part of the team's work. And when this happens, teams tend to optimize for what is easiest to measure. Features shipped, velocity, closing tickets in JIRA or whatever. Not whether any of it actually created value to the end user and supported the business goals that you, as an organization, wanted to achieve by having this digital product. Because that is, first and foremost, the most important thing to do. The third finding was about exploration. We asked whether teams create space to explore and also test new ideas, even outside the core roadmap. So, 56% of product teams say they do just that. Among delivery-centric teams, this is just 28%. And this matters. This really matters. Because exploration is often where the next wave of great product ideas comes from. So, this is not only something that is done at the start at the early birth of a product. This is a continuous thing that you continuously need to do to have that involvement of your product. This is where the teams test assumptions. They discover new opportunities. And sometimes realize that they've been looking at the wrong problem altogether. But when the daily delivery pressure dominates, that space is usually the first thing to go. And I think that some of you will recognize this in your organizations. And this is a problem. Because while it's easy to cut into short-term, it's also one of the most expensive things to lose in the long-term. So, in other words, what we see is that product-centric teams tend to work differently in some pretty important areas. They are more likely to spend time understanding the problem before building. They are more likely to have clear goals to the team and they are close to the team. And they are more likely to make space for exploration, testing, coming up with new ideas before they are committing to a solution. Okay. These are just numbers, right? And we see a difference. But I think the real question here is, does this difference even matter for delivery? Or is it just an inherent difference? Because if product-centric teams spend more time exploring and understanding problems rather than focusing on features or speed, do they give up something in return? And this is where it gets especially interesting. Because product teams are actually more likely to say that they ship frequently and reliably without major friction. And this is, to us, counterintuitive. Because you might expect delivery-centric teams to come out strongest on that question. And this is, I mean, this is what they are based around, right? And if execution is the top priority, you would assume they would be the ones shipping faster, more consistently, and with less friction. However, the data points the other way. So, the interesting takeaway here is that spending more time understanding problems, testing ideas, and creating space for learning does not seem to slow down the teams. If anything, it may actually help them ship more consistently. And with fewer blockers. Let that sink in. In other words, product-centric teams do not just seem stronger on discovery. They also seem to have a healthier and more reliable delivery setup. Okay. So, what we see here is a bit of a delivery gap between the teams. And what that brings us to is then the next real question. Now, we've been teasing, showing some data, a bit of findings. But the question is, how will AI actually change the way we build products? Could it help the delivery-centric teams to catch up in some areas? First of all, we see from the survey that 97% say that the organization's already using AI for whatever tasks. At this point, we are really past this adaptation question. These tools are here and almost everyone has access to them. They are democratized. You can just pay and get a subscription. You're good to go. But remember, we ran this survey in September last year. More than half of the participants said that their companies were already using AI for code generation in that time. I think many of you might know this, but in December 25, the release of new coding models, that really pushed the boundaries of what we thought was possible with AI-generated coding. And as Oscar said, with the Spotify example, we see the same at Framna. This changed things. And we see companies building faster than ever before. So in this survey, we saw that 51% were using AI code for generation. But we would be surprised, at least Oscar and I, if the numbers of organizations that are leveraging AI for code generation hasn't significantly increased after this. So again, could it help delivery-centric teams with delivery? Maybe. It may help teams move faster and make delivery easier. But does that make for a better product that will better support the business goals and that will be loved more by the users taking it into higher adaptation rates and so forth? Oscar will make an argument now that it doesn't.