Welcome to this webinar. Thank you so much for joining us. And for the next hour, we'll talk about something that we care a lot about, we're passionate about, that's digital products. In fact, we'll specifically focus on how products are being created. We have almost 500 people joining us for this event today. So thank you to all of you for taking the time and tuning into this. Hopefully you'll find the content interesting and relevant. My name is Joacim Jeppesen. I'm the CEO of Framna. We're a digital product agency. For the past 15 years, we've been partnering with brands and companies across all industries on designing and building and continuously improving their digital products. The products that we have in market that we've created with our brand partners are reaching millions of people every single day. And so what happens when products can be created at the moment, that's the focus for today, the question. So in a situation where products can be built much faster or some of the processes, what makes a product win over another? With me today is Willis, commercial director and Oscar, who is our business designer and who works with companies across all industries on their product development lifecycle. During the webinar, please ask some questions in the chat or in the question section, and then we'll get to the answers at the end of the webinar. And you can also engage with the polling that's going to be running on your screen and then makes the webinar a little bit interactive. Without further ado, welcome to the webinar. I'm going to hand this off to Oscar and Villads. Thank you, Joacim. And I think we're going to start this actually by considering a little bit of like what is going on last year. Because I remember the first time I got my hands on Chap GPT. And it sparked something within me. It was a feeling that this is actually going to change things. And I felt the change at the tip of my fingers. And I think many of you who are listening here today had a similar experience when you first interacted with Chap GPT, when you saw the intelligence come to life. Well, throughout the last months within the product development industry, I would say that something similar has happened that can resemble this Chap GPT moment. And I think that many of you who are listening here today actually felt this as well. But if there are any people here who really hasn't experienced this or are not fully convinced that things are changing, let me provide you with some examples. So let's first start with Lovable. I think everybody has heard about this company. One of the fastest growing software as a service company of all times. But what we do not actually talk about that much are the numbers that are behind them. So Lovable released the numbers that they are actually starting. They're starting like it's starting 100,000 projects daily within Lovable. I mean, that's an astounding number. When you think of that, that means it's like a million new projects being started like every one and a half week. So the number of ideas that's been tested, prototyped, and built now is higher than ever. And we know that maybe not all of these ideas and prototypes is going to turn into actual products. But the accessibility to actually trying these new ideas is something different. I think we had some problems with the slides going. I think we need to go back a little bit longer. Sorry for this. A little bit of a preview from what is coming. So we also see change within larger companies. Like at Spotify's fourth quarter earnings call in February, they announced that their most senior developers hasn't written a single line of code since the release of the new coding models in December of 2025. But it's pretty interesting because they put the emphasis on the best and the most senior engineers using this. And we might come back to a little bit later where this is the case. We can also speak from our own experience. We at Fram now, we have teams already working with agent encoding with similar results that we write very, very little code in certain teams now. And we can also see like a new era of companies being launched. I think it's interesting to look at a company called Trust MRR. It was a developer that saw a tweet go viral about the issue with startups' monthly recurring revenues. And he had an idea how to solve this. So he took his own developer kit. He built the product in 24 hours, launched it, and launched it with a tweet. Within three days, he had made $20,000 solely on advertisement income from this idea. I think it's fair to say that we're actually entering a new era of product development. And at Fram now, we really, really value and cherish the product development community and the openness that we have to where the change is coming. So this is one of the reasons why we host this webinar today. Because, I mean, let us be clear, very, very few people know what the future will be about, how this is going to change, and what it's going to turn out. But for this webinar, we're sharing our thinking right now on this topic. We believe that if we're more open within the industry and talk more about these kind of things, that what we're learning and what we're struggling with, then our product will be better, and we will build better things for people who actually use them. So today, we're going to go through some of our own data about product development organization. We will go deeper into what makes a good product win, and also look a little bit between, like, the balance in between AI and human judgment. And with that said, I'm handing over to my colleague, Villads. 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 product on a day-to-day basis at the Future Product Day 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're very happy that we will be continuing this partnership again in 2026. So with several thousand product peoples 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 and 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 in 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 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 the data, from the 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. And 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 spend 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 delivery-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 like self-reflection, right? And it makes sense. Because if decisions are made outside of the team, or the solution has already been decided up front, 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. Feature-shaped, 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 and 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, they test assumptions. They discover new opportunities. And sometimes, sorry, 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. I mean, this is what they're 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% said that the organization is already using AI for whatever tasks. So, 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. Yeah. So, I mean, let's dive a little bit deeper into what makes good product wins. Because we actually believe that some of these key data points that we talked about earlier is actually going to determine your success within this upcoming product development era. But let's just start with acknowledging this. Faster coding does not mean better product. Of course, faster coding can mean better products. But there is no, like, straight connection between you building faster and the product becoming better. And we have some data to support this. Pendo, which is a product analytics platform, looked at actual users across thousands of applications. And found that only 6% of features drive 80% of all engagement. 6 % of all features. It's such a small number compared to how much we focus on building new features. CB Insights studied companies who succeed and fail, analyzed startup failures, and found that 35% failed because they could not have the right market fit. It was not because they couldn't build it. It was because they built something that nobody needed. Looking at Microsoft, I mean, one of the tech giants, they actually set up data teams to focus on their experimentation to see how many of their ideas that they test actually improve the metrics they were designed to move. Two out of three ideas failed to move this metric. And, I mean, these are not stats that come out, like, after AI. They have been here all along. So, I think most of you who listen to this intuitively know this. But still, we see so many organizations that focus on the output rather than the outcomes. You focus on the number of features that's being shipped. And this is still a dominant trait that we see. But the organizations who are better at focusing on outcomes rather than the outputs, they usually think a little bit different. They are very good at sitting with this question. Should we build this? But thinking back a little bit, I think, actually, before AI, teams were forced to ask this question. Resources were scarce. So, we had to choose what to build. We could not build all the things that we wanted to. So, this created a form of, like, discipline that made teams to think before they actually committed on what to build. We really, really wanted to find the things that pushed the needle. But, as well as I've been talking about before, AI will change this. When building becomes faster, the old constraint that created this discipline actually decreases. So, there's actually a little bit of a risk here that many product teams can lose this discipline. I'm sitting with this question of, like, should we actually build this? Is this a good idea? Since we can build more. But, again, the teams that succeed are the ones that will continuously sit with the question. Should we? So, how do they do that? How do good product teams sit with the question and decide if they should build something or not? Well, the answer is that better products come from doing good product discovery work. Putting on the focus on the three pillars that I think most of you know here. Desirability, viability, and feasibility. But, Willis was talking about this as well a little bit before. I think many organizations tend to think that this is something that we do at the start of every project. So, when we're going to try to do something new, while we go through these different checkboxes, we see if there is a user need. We see if it's viable. And we see if we can build it. And then we just build it. But, the good product organizations are the ones that does this frequently. At Framla, we have teams that does this exercise almost every week to try to find the real features to build and how to build them in a good way. So, when we are looking at this model of, like, desirability, viability, and feasibility. I mean, the first one, the desirability, for those of you who's not that, like, familiar with the model. It is about understanding the users and the user context to actually know that we're building something that people will actually appreciate to use. The viability aspect is, like, understanding the business need and what opportunity that we can unlock by building these kind of things. But then, the feasibility question. I mean, the feasibility question has always been, like, can we build this? And, of course, should we build this? When AI is helping with code generation now, we think, actually, that this question will maybe shrink or turn into something else. It will change, at least. We're not there yet. We do not have the answer, like, what is the right way to ask the feasibility question. We're in the midst of this as well and working on these kind of things. But we still believe that understanding, like, how a feature is implemented, how it will fit the existing system, how it scales, et cetera. These things will still matter. And this will still be valuable questions to sit with before actually deciding what we're going to build. So, AI can help us build faster. But we still need to understand how we can build and sustain it as a whole. I think another big argument why we need to focus even more on doing good discovery work is that we're actually also going through some sort of a platform shift now, we can say. Because we see that our user behaviors are changing now. With the launch of the foundational models, this Chattapiti, Claude, Gemini, et cetera, we see actually changing user behaviors now. When we go out and do research now, we see users being more comfortable sharing data that we would never think that they would share to anything else. Like, we see them think in different ways of solving their problems. So, for many product companies now, I think it is actually about, like, expanding the research, doing research broader, not only focusing on, like, how does your product solve this problem? But go back to the question, how do the users nowadays solve this problem? Because this might actually be changing now. And again, we will see more products come out in the markets. We will see more product launch because of that is simpler to take an idea to actually, like, launch something. So, we have to work with this. And we have to continuously do this discovery work again and again and again to make sure that our solution or our product is catering to our user needs. But then I think when we start talking about this thing, talking about deepening in discovery, I think, well, can AI do this for us? Can we use generative AI to do the research? And here, we want to take a little bit of a stance, actually. Good discovery research is about creating new knowledge that doesn't exist. If you go out and do research and make findings that already existed before and that you already know before, then you're not doing discovery research in the right way. AI is actually very good at recycling and transforming, like, existing knowledge into patterns that you can read and then you can, like, use. But, again, good discovery work is about creating new knowledge. So, we believe that AI can really help you when doing discovery work. And we will come to that a little bit later in the presentation. But we would be skeptical to outsource a lot of discovery work to AI. And one of the persons that we at Franl listen to a lot when it comes to discovery work is Teresa Torres. She's a famous product coach and she's, like, speaker on the topic of the future of product development. And I think she's sort of put the nail to the head with this one. That she said that we're going to go through a period where companies think that they should build every idea they have. And then we're very quickly going to realize that leads to terrible products. So, coming back a little bit to the numbers that Davila shared, we see that some of the companies that do not spend enough time with problems, do not spend enough time investigating, like, new solutions. We think that this is a place where they might be heading. But to not end up in this prediction, we believe there's one key thing that we continuously need to work with and to strengthen. And this is relationship between human judgment and AI. At Framna, we've really, really been trying to focus a lot on, like, HI plus AI, human intelligence plus AI, and how does this work together. And we think that this is the core and one of the, like, key things in the future of good product teams. So, let's start here with addressing a bit, like, the elephant in the room. AI writes a code and the engineers prompt it. What is the future of engineering? Well, for us, I mean, this question, it doesn't sit well with us. Engineering has always, like, had a bigger purpose than just writing codes. And there are still many tasks that AI can't do, or at least that we shouldn't actually rely on AI to do. And one of them is system design and architecture. Knowing, like, the system, like, how to build it, why it was built in a way, why certain trade-offs exist, and what's the best way forward. But it just remains as a task for engineers to focus on and to sit with. Code reviewing. I think there are very few people who's listening to this webinar that actually will be comfortable with an AI having full control over the code base. So, code reviewing is something that we still need to focus on. It is both to make sure there's no issue with the generated code, but also to keep control and keep that sort of, like, that human judgment of, like, are we building the right thing that sits within doing good code reviewing? Then there is less 20%. I mean, this could be edge cases. It could be something like scale the product. But it can also be the things that actually make your product stand out from the competition. If you're only using LLMs to prompt the code, etc., you're not going to get there to the last 20% to make you stand out from the crowd, to make you, like, something special. And maybe the last and most important is actually what not to build. AI is made to respond to you and, like, you give AI the command of what it builds and it will find a way to build it. But engineers often sit with the question, what are the things that we shouldn't build? What are the sort of, like, features and what is sort of, like, the technical, like, from a technical aspect, how should we not build this? Like, thinking the question in, like, what sort of solution you can use and what sort of, like, tech that you can use to solve this problem, that is where engineers have a key role to play. So, we see that, like, yes, we're going to go to a future where more prompting is done by engineers and more code is produced by AI. But engineering, good engineering work still matters a lot. And what is happening, actually, when we change this context is pretty interesting. We have a few teams here at Framna where we see this shift is already going on. And some of the things that we see is actually that we need to shift a bit how we work. One of the things that is interesting when it comes to this is that actually now in meetings, when we're so much faster to prototype, then we're also so much better at aligning on what we're actually, like, the ideas we're coming up with. Before, we maybe used to sit with, like, having idea session, doing lo-fi, like, mock-ups, then a designer had to go back, actually wireframe them, get back to the team, talk about, like, what was this what we thought of? Like, how do we think of this? Now we can come to that alignment within a single meeting because we can prototype in a much faster way. We can also actually move from having more discussion into, like, looking for more evidence. One of the things that we see is that we're right now trying to prototype more in the source code to actually see how does the solutions and ideas that we have fit in with the entirety of our product. But we can also, of course, ideate and test more and more solutions, A, B, C, D testing, and, like, going further in, like, what we can gather data on now, or what is the right way of solving a problem. And the final thing and the final shift that we see and that we think is kind of important is actually that we now have a little bit more time for everyone in the team to participate in research, to actually be out there, to talk to the users, to understand them better. Because if we do this, we believe that we are building the entire, like, judgment of the team together. When things are going faster, we need, like, to be better aligned on the problems that we're solving for our users and to actually have the entire team with us more within the research context really helps us to speed up things actually when we're building as well. But we did also talk a little bit about that, like, product discovery and AI. Like, even if we wouldn't say that we would outsource product discovery to AI, we still believe that AI can transform how we do product discovery. We think that actually looking at the research and, like, our research plans, that might have blind spots that we can look through with AI. It can be that we test what methodology we, like, we're using. Is this the right methodology? AI has a tremendous knowledge of, like, how you do research in a good way. That's something that is really interesting. It could simulate users. You can use your personas to simulate how do we do user research. So we can go through, basically, like, if we have some, like, a questionnaire that we're going to bring out to interviews, we stress test those with users before we actually go out and do the interviews. Because then we can know better that we're aligned on the question, that we get better results in, like, when we're actually doing, like, asking the questions. Another issue that we sometimes struggle with, with, like, doing good discovery work is, like, are we researching things that we already know? Well, I mean, now AI can get access to more and more things, like, backlog, like, customer tickets. We can have, like, of course, surveys and previous transcripts that it can look through. So we can actually start, like, matching and see, are we asking for new things here? Or, like, does this already exist in our data? Which is already then making the discovery that we're going to do even more valuable, because we make sure that we look for new things. Another place where we can see it work is to work together with a team to formulate and to gather the insight when you've been out and doing the product discovery. This is a place where AI can have a big role as well. And the final thing where we see that AI actually can transform how we do product discovery is sharing knowledge. I mean, before, like, it used to be a meeting where we presented, like, insight to different stakeholders, etc. But now we can see that we can create much more engaging content than we can send out to much broader audiences within the organization. So the organization can easier understand why the product team decides to prioritize in the way they do. And this is something that is really changing. But we would caution a little bit for this again. Because everything we said now comes under the condition that it is starting from a human perspective. The human is doing the groundwork. And then you leverage the AI. For example, if you do a good discovery round, you talk to your users and learn from them. Then you put in, like, all the transcripts into the AI. And the AI gives you the analysis. I mean, the insights would probably look reasonable. They think it's very, very good at framing things in a way that looks very reasonable. But if you do this enough times, pretty sure that you will start losing your own understanding of why you made the decision that you made. I think we need to flip the script here and say that, like, research needs to do, that we need to do the research and we need to sit with the raw material first. That is hard work. But it's actually the work that builds our own view of the problems first. And then we can help, like, leverage AI and let AI challenge this. Because what AI now does is deepens the knowledge instead of replacing it. It's the same tools. It's the same data. But the difference is the order, the sequence that we do this. One sequence helps us build human judgment. The other quietly erodes it. And we believe that this is one thing that every team should sit and think of. In what order do we leverage AI in our work? Because in the end, we do not believe that AI will be the moat. Most teams will use and access the same models. So, and we do not believe that, like, prompting is going to be some sort of, like, competitive edge. They're going to be best practices. People are going to learn. And you're going to be able to copy what you do pretty easily. The moat will be the team and the human judgment that they've built together, iteration by iteration, learning by learning. To gather those insights, test the ideas, and together answer the question of, like, should we build this? Fabulous. What does this mean for the future? So, I think that's a great question, right? And it's one that's difficult to understand. And it might depend on what type of product organization you're in, right? So, you remember these two different groups? Delivery-centric and product-centric? We believe that these groups will both see productivity gains due to new coding models. But that isn't the takeaway from this webinar. The main takeaway is the importance of doing something more and better. And that is discovery work. Building human judgment while leveraging AI. And the question is then, is it really that simple, though? And it never is, right? And as you remember from the survey, the delivery-centric teams spent too little time today exploring problems and testing solutions. Because stakeholders feed them what to build. So, what we need is for managers, sales, and stakeholders to change this approach. Instead of bringing solutions to the team, they need to bring problems. And if you still hand over solutions and expect the team to build them, then doing more discovery is due to theory. And it has no meaning for anyone, right? So, many organizations, they need to rethink how they operate to leverage AI. A bold statement would be half. A good way to illustrate this change in framing problems can be instead of stakeholders asking for a dashboard, which is just the output, ask the team to solve why we're losing 10% at a certain step in the onboarding process. There you will have the outcome, right? And give the team the freedom to do the discovery work, even if you think you know what to build. So, if you're sitting here, identifying your organization as the lyric-centric one, here's three important shifts that we would advocate that you consider. First, move decisions to the product team. If stakeholders own the decision-making, then decisions will be slower and will not take the advantage of the speed of the new models or the shared context that is built up in the team. Secondly, focus even more on measuring outcomes. If we focus on output, the result will most definitely go up, but we risk cluttering the product and making it worse for our users because we're just adding features and features and features and features without knowing whether they make any difference at all. Thirdly, spend more time contemplating the question that Oscar also mentioned. Should we build this? When building gets faster, the urge and the temptation is to skip that question and just ship it. Works well for prototypes. Works well for ideation, exploration. But as we've said, and we say it again, and as Oscar said, these are not new numbers. Most features doesn't move the needle, not the needle desired by the organization. So the teams that will win will be the ones that slow down at the decision point. And even as everything around them speeds up, they will still take the time and slow down. But we do not only have delivery-centric teams here in this webinar, and of course, all of you are product-centric teams. So what can any organizations do already starting tomorrow, or let's call it the weekend, and let's say Monday? You can start planning for your next discovery cycle before you commit to your next product bid. Even if you do still not own the proposition, start working this muscle, gathering the arguments for why and why not you're building something. And then use AI to stress test your research plans and to make sure that you are making the most out of your discovery work. And then let the team form their views first. And then challenge it. Use this massive wealth of knowledge and best practices and have that challenge it. But remember, the sequence matters. Right? It really matters. Because in the end, it is human judgment that will make good products stand out and win. We can feel it. Humans can feel that thing, that indescribable thing. When building becomes easier, it is the humans, their understanding, their taste, that makes differentiating factors. All right. If you thought this was interesting, this is not the last thing that we will be doing. And you're more than welcome to scan the QR code now on your screen if you want to have access to the mobile app trend report where we're describing how different apps perform on parameters, giving insights to more on this. This is a big written material, but there will also be some events describing this. And then now we've set aside some time for some Q&A and some questions. So I think, Oscar, perhaps, if you will read them out loud and then we can discuss the questions. Yeah, sure. We've got some good questions from the audience here. And the first question that we got actually was, could you resonate about the product-centric versus delivery-centric organization using AI and the risk of losing your edge when everyone uses the same agents, lovable, et cetera, when everyone uses the same models trained on historical data? Yeah. Yeah. And I think the question really ties deep into this talk, right? Because it is about, when you're using the same models, you will have sort of like the foundational work. So the discussion is then, what sets your product apart? Where is it that you create that delight that the users can feel? Because that won't come from those generic models. Because when everything's the same, nothing really stands out, right? And I think that ties into having that human intelligence, looking at it, ensuring that you're doing the right things, you're not missing out, that everything is squared off, and then not doing all that heavy lifting will create that mental freedom and mind space for you to really come up with those brilliant ideas that really does make a difference, right? Yeah. And I think, elaborate a little bit more on like the difference between like product-centric and delivery-centric teams. I think, I mean, a little bit of our talk has been to highlight the differences from the beginning that we see and that we actually think that there is a risk, especially for delivery-centric organizations now to derail the product a bit. Making, if you let more of the stakeholders, they make more decisions. Before, they have sort of been held back a little bit by scarcity. Now, when, again, we're doing like development faster, well, that scarcity is not holding back anymore. So more and more ideas can be pushed through the product team. And I think that is where a lot of product leaders now need to sit and think and like consider what and how this like this new dynamics need to be shaped. Because I think that that is fundamental to where we're heading like in the industry to consider these aspects. I think also a bit when it comes to then the aspect of building human judgment around the products, then we also need to trust the human judgment that we have built around the products. I feel that sometimes it's like that somebody else can know the issue better outside in the organization and they feel that I know this issue by heart so therefore you need to build this. But there we need to start establishing trust between the product team who's building and the rest of the stakeholders. So I'm not entirely sure that this is the answer to the question because I felt there was a lot of things in here. But I mean we're pretty confident that like only leveraging these like lovables and etc. It will not make your product to be distinguished. It will not make your product stand out. It is understanding your user solving trying to solve it in a unique way because then I think that is where you find more like out to it or you have like find a place where you stand out of it. Yeah. We had another question here that maybe we can get into. So I'm at a software as a service company that is quite deliver centric. Could you resonate about how to handle both customer and sales staff using lovable to express needs? I see a risk having to spend time on commenting sketches and over promises of what is being built out of the hands of the actual product team. Yeah. I think this is a very common thing to see, right? And I think often when we start new dialogues with new partners and asking them hey, why why did you reach out to us? What is it that we can help you with? One of the main comments and answers to this question is our product is just a patchwork of features. There's no coherent strategy. There's no coherent workflow through it. There's too many features and the same feature exists in several places and you can access it from all kinds of iterations and it's very hard to navigate and we're not getting the business value out of what we need. And when we then start diving into those discussions and why does this happen? The answer is with nuances and in different phrasing, but it's always the same. Powerful stakeholders opinionated, promised something, wanted something, and we just had to build it. We couldn't resist, we didn't have a mandate to resist, and here's the situation. So really having the product team have that ownership of the roadmap, having the strong arguments why that is, and perhaps also having some sort of product strategy that helps you fend off these incoming intruders. So I say, hey, this is the direction we're going. Can we all agree to this? Can you give us the mandate that we are agreeing to this? And then within this field, we will make the decisions and we will navigate because we have all of the context and we have all the understanding that those external stakeholders not necessarily have. What I like with this question is actually, it highlights one of the issues that we will see more and more in the industry. I think what is happening now with this model is that we boost the stakeholders that they can actually feel that they are building the products and stuff. They can actually shame things and do things themselves. And I think this is a question that many organizations are going to sit with and try to figure out. I really like what you say with having a good product strategy. strategy. I think if you have a product strategy, that is the first thing that you should focus on to actually have that sort of like, this is what we're doing and this is why we're doing it. Because if you can have that, that's the argument that you can pose to the people that you opt them with, with different prototypes, etc. I think then you will sort of have a better way to manage it. But, yeah. Yeah, I also feel like I think with access to these tools, and they are great tools, we also have a risk of like seeing the same tendency that we see elsewhere, right? We see it with how to raise your child, COVID, public parking, all of a sudden, everyone's an expert on that domain, right? Yeah. And I think we see a bit of risk of this happening now. All of a sudden, everybody's an expert on product development. And that is, I think, again, where the importance of leveraging human judgment and human intelligence. Because what we want to sit with, what we want to create, is sort of the authority within the product team to actually say that, like, we've done these iterations, we've talked to the customers, our users, like, this many times. These are the things that keep popping up. These are the things that we keep hearing. So that is why we're building in this direction. So again, like, going back to actually use your insights from good product discovery work might also help to push back a little bit on a lot of these prototypes. I think a lot of product teams will be exposed to that stakeholders are going to come in with and say, like, why don't we just build this and this is super easy? And, well, why don't we just do that? It's, again, bringing it back to organization and understanding that the biggest question we're going to answer right now is should we build this? Because we risk derailing our product and we risk not providing our users with the best experience that we can give them. All right. I see time is ticking. Yes. Do we have one last final question that we can wrap up in a minute with the respect of people's time? Yeah. So, I mean, I think really short. We have a question about, like, so if you are a delivery center organization, like, and, like, we know that we're, like, if they're part of it as a team, they know that they cannot change the entire organization. But, like, what are small steps that you can do? And one of the things that I tend to, like, when I come into different teams and coach them, is to also focus on experimentation. We focus on experimentation in our products, but our way of working should also be something that we tend to focus on experimentation and try to make safe to do experiments. I think that is one of the most important that we can do for the future. So try to experiment with it and try to create new ways of working. But I think with that said, our time is up, and we want to thank everyone here for listening, and we hope you have a great Thursday. So, goodbye. Bye. Bye. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.